281–290 of 390 posts
I am a python outsider, but like many others dealt with a lot of pain due to the simultaneous 2 and 3 versions. Looking at the history, I see python1 ended at 1.6, and python2 ended at 2.7. Based on this the current python 3.6 seems to be nearing end of life. https://en.wikipedia.org/wiki/History_of_Python So what will happen when python 4 comes out?
Larry is surely working on it.
Earlier quoted context omitted.
The Python developers plan to never break syntax or stdlib compatibility again. Core developer Nick Coghlan wants to see 4.0 within the decade but he wants it to be "uneventful". [1] In that way, it would be a lot like Python 2.0, which only broke compatibility in obscure ways, but added new ways to do things. Here are some of my wild guesses at what features Python would want to commemorate with a 4.0 release: - An…
> UTF-8 as the guaranteed default encoding, instead of trying to infer anything from stupid locale shit. This is already the case for source code, right? And I don't see where else it could apply. If you mean stdin/out, then those have to use locale to be compatible with other text-processing software (so that you can pipe things etc).
This is the number one thing I'd change if I were in charge of Python. ;-)
Earlier quoted context omitted.
Perl6 is incompatible with Perl5, so they're also going through a similarly painful transition. Everyone waxes lyrical about how Python 2.x was "good enough and why would you change it", but there were several things in Python 2.x that were objectively awful (unicode was broken, iterator variables can leak to the outer scope, division of integers producing integers, xrange, raw_input, mixed indentation "working", etc…
Perl 6 is a different language. Last time I checked there was no plan to discontinue Perl 5.
Earlier quoted context omitted.
> Isn't that a bigger problem for Python 2.7 hold outs? Yes, but it seemed like libraries (such as NumPy here) were mainly switching because of the EOL of Python2 rather than for any actual benefit provided by Python3. I've considered that as more of "Python 3 is a bad thing" by splitting the ecosystem further, and creating additional churn and rework of existing projects. Thus my question of why people seem to think…
> what has changed in Python 3.6 that they're happy to do this now when they were pissed off about it a couple years ago? Most of mine have to do with developer productovity and I didn’t find until Python 3.5. – @, the matmul operator – fstrings (f”{foo}”) – parameter typing (foo: int = 0) which has exciting work with Cython – other async features. I forget what library it was (tensorflow?) but for Python 3 it had be…
* API-wise keyword-only parameters are absolutely fantastic, even (especially!) for non-default params.
* Extended unpacking, and the ability to unpack in collection literals, make the language much more "expressive" (in the sense there are more cases where you can make do with just expressions) which is very convenient.
Earlier quoted context omitted.
The Python developers plan to never break syntax or stdlib compatibility again. Core developer Nick Coghlan wants to see 4.0 within the decade but he wants it to be "uneventful". [1] In that way, it would be a lot like Python 2.0, which only broke compatibility in obscure ways, but added new ways to do things. Here are some of my wild guesses at what features Python would want to commemorate with a 4.0 release: - An…
> UTF-8 as the guaranteed default encoding, instead of trying to infer anything from stupid locale shit. This is already the case for source code, right? And I don't see where else it could apply. If you mean stdin/out, then those have to use locale to be compatible with other text-processing software (so that you can pipe things etc).
Here are some reasons not to try to get your locale to tell you about UTF-8:
- There is no standard for this.
- Locale suffixes ".utf8" and ".UTF-8" are hacks by specific Linux distributions, and people want their Python code to work even if their system has not implemented this hack.
- The locale "C" does not really mean you want your program to explode when it sees a non-ASCII byte. What Python does here does not promote compatibility in any way.
- BSD has no UTF-8 locales and has never pretended that locales work with Unicode.
- Windows' equivalent of locales is extremely deprecated and never actually supported UTF-8. The modern Windows APIs that deal with standard in and out correspond to Python's Unicode string type, not its bytes type; encoding the Unicode I/O into bytes is not Python's responsibility.
- Really every operating system but Linux has this figured out, and in practice, Linux users want UTF-8 regardless of what their locale says.
To be compatible with other text-processing software in 2017, you don't use locales, you use Unicode APIs and UTF-8.
Earlier quoted context omitted.
Perl 6 is a different language. Last time I checked there was no plan to discontinue Perl 5.
Wont they have a naming/versioning problem?
I'm not a particular fan of that - they should have changed the name entirely, IMO, eg. to Rby - but Perl 5 is not getting discontinued.
Good. The glacial migration from Python 2 to 3 is one of the worst things about an otherwise fantastic ecosystem. The tide is turning though, with Django having already dropped support for 2, and now with Numpy too hopefully Python 2 can be properly consigned to the history books. For people wondering why it's been like this for almost a decade(!) since Python 3.0 was released: Python 3.0 was actually terrible. It la…
When I use python as a scripting language for small tasks I want something concise and convenient that just works. Python 3 is a downgrade in all those areas. I want to just some input into a string, do some operations on it, and print the result. Now I have to make extra special sure to convert the string between binary or utf8 as appropriate, catch encoding exceptions, not try to print anything that might have bina…
Funny, I found the exact opposite, and despite $dayjob being LCD(2, 3) and the default Python on my system being 2, I've been writing all my small scripts in 3.6.
Earlier quoted context omitted.
When I use python as a scripting language for small tasks I want something concise and convenient that just works. Python 3 is a downgrade in all those areas. I want to just some input into a string, do some operations on it, and print the result. Now I have to make extra special sure to convert the string between binary or utf8 as appropriate, catch encoding exceptions, not try to print anything that might have bina…
> When I use python as a scripting language for small tasks I want something concise and convenient that just works. Python 3 is a downgrade in all those areas. Funny, I found the exact opposite, and despite $dayjob being LCD(2, 3) and the default Python on my system being 2, I've been writing all my small scripts in 3.6.
The real crime of Python 3, is not the changes, but the compatibility break. Hundreds of thousands of engineer-hours wasted on porting, worrying about compatibility, and supporting unsupported libraries or two environments at once. In the meantime, the language does not meaningfully advance, and thousands of projects are slowed down. It's such a huge effort for a gain that is not worth it.
Earlier quoted context omitted.
> what has changed in Python 3.6 that they're happy to do this now when they were pissed off about it a couple years ago? Most of mine have to do with developer productovity and I didn’t find until Python 3.5. – @, the matmul operator – fstrings (f”{foo}”) – parameter typing (foo: int = 0) which has exciting work with Cython – other async features. I forget what library it was (tensorflow?) but for Python 3 it had be…
* Not only is print better as a function (I can now call print in a lambda!) doing anything beyond just printing variables (e.g. printing to a stream/file or suppressing the final newline) is both more straightforward and more readable. Also print(xxx, end="", flush=True) is my bae. * API-wise keyword-only parameters are absolutely fantastic, even (especially!) for non-default params. * Extended unpacking, and the ab…
Even if you like "print" as a function, is it really so important to wipe out the huge inventory of working Python 2 code and stall Python development for a decade? Python 3 is a tragedy.