Importlib for me is a prime example of a project that lost all direction. It's driven by one or two people and they are developing it without any real world experience with it. I pretty much gave up supporting any of that stuff because with every Python 3 version it changed in new ways and at this point it has lost all portability for me as I need to support from 2.x to 3.4.
Another good example is the general stream interface. While you could argue that the streams are byte/unicode problems they in themselves are an API problem more than a unicode problem. I waste enormous amounts of time trying to make streams work well but the new API is just inherently more complex than before for very little benefit. For the user the new streams are definitely more complicated than the old ones.
While not Python 3 related, but there is a whole new packaging infrastructure project going on in distlib which is used by nobody (with the exception of pip which uses the semantic version parsing of it) besides the original creator and maybe a handful of other people.
asyncio thankfully had Glyph overseeing it, but even with asyncio there are not enough users for the library to go into the interpreter. We're already at the point where there is going to be an updated version uploaded to PyPI which raises the question why it's built-in in 3.4 in the first place, if it's going to change in 3.5 again.
This iterative development worked in Python 2 because of two reasons: a) stdlib packages came from outside the stdlib and were iterated there and b) they were developed out of a specific need and people used it. I don't see this happening for anything in Python 3.
Everybody does work across an IO boundary. Python 3 had the idea to hide the boundary from you but that trick did not work, now they added escape hatches in through surrogate escapes and other things and made everything worse in the process.
Most people just produce broken code in Python 3 now because if you don't touch it too much, it seems to work.
Just getting command line arguments is boundary code.
It's an OS issue. CLI arguments and file names are always UTF-16 text on Windows and some unregulated binary stuff on UNIX that may or may not be some text in a system-wide locale that may have been changed by another application through setlocale. Naturally, choosing one approach somewhat breaks the other.
No. That's because POSIX demands that the locale is set to C and that implies ASCII. However the locale only controls messages, it should not define anything about filesystem encodings. I wrote about this recently: http://lucumr.pocoo.org/2014/5/12/everything-about-unicode/
How is that related to Python at all? I mean, you're opening a text file without explicitly specifying an encoding. The only reason you think it "works" on 2 is because it doesn't actually open files in text mode. (In fact, is that even possible without using the backported io module or writing a custom wrapper?)
I assume you have no idea what you are talking about.
I mean, you're opening a text file without explicitly specifying an encoding. The only reason you think it "works" on 2 is because it doesn't actually open files in text mode. (In fact, is that even possible without using the backported io module or writing a custom wrapper?)
If you open a file in text mode in Python 2 you open it to return bytes. If you open a file in text mode in Python 3 the interpreter will ask the environment what the encoding is. Which it turns out, is a pretty terrible idea. You should be explicit. Unfortunately there are cases now in Python 3 where you cannot be explicit because the interpreter already "solved" the problem for you. Incorrectly.
If you open a file in text mode in Python 2 you open it to return bytes.
That makes no sense. If it returns bytes, then it's in binary mode. If it were in text mode, it'd return unicode objects. (And please don't say that the difference between "text" and "binary" is solely whether the CRLF-to-LF conversion is enabled or not.)
Unfortunately there are cases now in Python 3 where you cannot be explicit
open has a keyword argument encoding. You can always be explicit.
That does not change that this is how the default API in Python 2 works. It's by far not the only API to open files in 2.x. That however was not the point.
open has a keyword argument encoding. You can always be explicit.
a) people are not. b) not every api supports that. Case in point: filenames, environment variables and argv.
What's exactly wrong with importlib and what do you mean support any of that stuff ? It's a py3 carrot - what else do you expect ?
Also, it's kinda weird that you complain about the lack of real world experience. There's a community process and you can get involved in the creation and review of PEPs if you think the PEPs could/should be better.
What's exactly wrong with importlib and what do you mean support any of that stuff ? It's a py3 carrot - what else do you expect ?
How good is a carrot nobody supports? 3.4 changed the importlib interfaces again and deprecated a whole bunch when introducing the module specs of stuff but did not provide replacement functionality.
Also, it's kinda weird that you complain about the lack of real world experience. There's a community process and you can get involved in the creation and review of PEPs if you think the PEPs could/should be better.
I am not using Python 3. All my Python 3 experience is coming from porting libraries for a barely existing user base.
I have zero interest in investing more time into Python 3. I do not believe Python 3 is something that can be repaired in a way to surpass Python 2 in enjoyability for me.
I'm surprised you bother with Python 3 at all. It's basically dead at the moment and so many other important contributors have simply moved on to other languages.
17
u/mitsuhiko Flask Creator May 26 '14
Importlib for me is a prime example of a project that lost all direction. It's driven by one or two people and they are developing it without any real world experience with it. I pretty much gave up supporting any of that stuff because with every Python 3 version it changed in new ways and at this point it has lost all portability for me as I need to support from 2.x to 3.4.
Another good example is the general stream interface. While you could argue that the streams are byte/unicode problems they in themselves are an API problem more than a unicode problem. I waste enormous amounts of time trying to make streams work well but the new API is just inherently more complex than before for very little benefit. For the user the new streams are definitely more complicated than the old ones.
While not Python 3 related, but there is a whole new packaging infrastructure project going on in distlib which is used by nobody (with the exception of pip which uses the semantic version parsing of it) besides the original creator and maybe a handful of other people.
asyncio thankfully had Glyph overseeing it, but even with asyncio there are not enough users for the library to go into the interpreter. We're already at the point where there is going to be an updated version uploaded to PyPI which raises the question why it's built-in in 3.4 in the first place, if it's going to change in 3.5 again.
This iterative development worked in Python 2 because of two reasons: a) stdlib packages came from outside the stdlib and were iterated there and b) they were developed out of a specific need and people used it. I don't see this happening for anything in Python 3.