Earlier quoted context omitted.
ElementTree has always been in 3.x. I believe NumPy and SciPy are finally making the leap just about now.
Numpy supports Python 3 since version 1.5, released in August 2010. Ubuntu 12.04 and the current Debian stable carry this version. Scipy supports Python 3 since version 0.9, apparently released in 2010 as well with releases in the current Debian stable and Ubuntu 12.04. ‘Just now’ is hence a bit too late, but it is correct that many users have only been able to use Python 3 some four to five years after 2008.
About Python 3
181–190 of 358 posts
Re: About Python 3
#182Here's my idea. Make a new "Python 5" (2+3=5, or call it whatever you want), based on Python 3. Put back everything that was deprecated or removed along the way, including the `print` statement. Provide `from python2 import xx` or `from python3 import xx` if there are incompatible module changes. To deal with the string changes, introduce an idiom like:
bytes, str, unicode = python2_strings
bytes, str, unicode = python3_strings
or: from python2 import bytes, str, unicode
from python3 import bytes, str, unicode
which always maps "bytes" to the byte array (py2 "str", py3 "bytes"), unicode to the unicode char array (py2 "unicode", py3 "str"), and "str" to whatever the legacy code needs.The goal would be to have 95% of legacy code run without modifications, or with a minimal addition of 2 lines to the top, or a command line switch.
Re: About Python 3
#183I feel frustrated too, but I think Ubuntu 14.04 will tip the scales (it ships with Python 3 by default). Also, the core devs got at least some things right with Python 3.3 by making it a lot easier to write code that targets 2.7 and 3.3 at the same time. In retrospect, that should have been the focus much sooner.
As a Linux user, I'd like to believe that Linux distros enjoy this kind of influence, but I honestly can't see how. How many people are still on Windows? How many are on OSX? How many are comfortable in 2.x and couldn't care less about new features? Python 3.x may be better in some ways, but it just doesn't look better enough. I wonder how long it will be before the 2.x community goes its own way like Perl 5.
Re: About Python 3
#184Something that might help is OS vendors shipping with 3.x installed, rather than 2.x most seem to. OS X ships with 2.7.5. For a casual python user, sticking with what is there and working is safe, especially when the benefits of 3.x are unclear.
Canonical has been working on making 3.x default for Ubuntu for a while. From https://wiki.ubuntu.com/Python/3 > It is a release goal for Ubuntu 14.04 LTS to have only Python 3 on the desktop CD images. Also, we won't be allowing Python 2 on the Ubuntu touch images.
Possibly typing "python" should be deprecated, should issue a deprecation warning before starting Python2. It's also a pity Python2 and Python3 source files aren't easily distinguished and will generally produce obscure errors if run using the wrong interpreter.
Re: About Python 3
#185I'm going to go against the grain here and say that moving slowly is one of my absolute favorite features about python and its libraries. Rails and django were released about the same time, rails is on version 4, django is on 1.6. Moving slowly means I can spend more of my time writing code and less of my time upgrading old code. More importantly, every release requires a perusal: did the API change, what's new, are…
i like fast movement, i like communities that dare to break things every now and then (see semver.org for the widely accepted versioning rules and should be honoured). much do i prefer an increasingly better solution to a stable one. i'm not agueing "perfect" over "good enough"; i'm argueing "awesome" over "good enough" :)
Use this API, no this one, nope now this one, you almost caught up, so we released a newer, more better one! Please buy Awesome Studio and RDMS 2015 or you are a loser. Here's a free version that can't do shit, the Pro version is only $2000, plus lots of your time adjusting to a newer mono/flat chrome development environment. Hot keys only for touch screen users!
Re: About Python 3
#186I understand there are backwards incompatible changes in python 3. But how hard is it to write code that works under both python 2 and python 3? Is this easy, or are the number and nature of changes so hard that this is a pain? How often do people write code that will work under both? During the ruby 1.8 to 1.9 switch, it was common for people to write code that worked under both. How hard this was depended on the co…
The official way to do it was to write in Python 2, and then use a converter to generate the Python 3 code (which was backwards IMHO). If the Python maintainers encouraged writing code that worked on both versions, they could have done a lot to help so (like providing compatibility modules, or backports).
But more important than new libraries that work with both versions (or even with just Python 3) is all the legacy code that doesn't run without heavy modifications on Python 3. If they had refrained from needless breaking changes (like removing the `print` statement), and made the braking improvements opt-out (like renaming str->bytes and unicode->str), it would be much easier to transition to the newer versions.
Re: About Python 3
#187My last few Python projects have started out as Python 3, but ended up as 2 due to missing library support. Would it be at all feasible to enable Python 3 to import Python 2 code? I imagine this could be done without making Python 3 fully backwards compatible, but I might be wrong.
That'll be the crux. When you can run most/all existing python 2 code under python 3 we'll see the transition. Until then most of us have no plans to even look at python 3.
Re: About Python 3
#188Earlier quoted context omitted.
Had a discussion at work a few weeks ago about this. Roughly, it came down to this - if you need any backwards compatibility whatsoever (Do you ever expect your code to ever run on machines with operating system releases younger than 2013ish OR do you ever plan to interop with code older than 2013ish), Python 2 is the way to go. Otherwise, feel free to use Python 3. This effectively means that only for purely greenfi…
> Had a discussion at work a few weeks ago about this. Roughly, it came down to this - if you need any backwards compatibility whatsoever (Do you ever expect your code to ever run on machines with operating system releases younger than 2013ish OR do you ever plan to interop with code older than 2013ish) Python 3 runs on operating systems older than 2013 and, while it might not be the OS default, there is no reason a…
You are absolutely right, but the overall cost of deployment skyrockets at that point. Not to mention pernicious bugs from grabbing the wrong library & whatever other weirdness happens. Unless the project is reasonably significant (deployment cost is insignificant to development cost), it's much easier just to work from the system python.
Re: About Python 3
#189I like Python 3. I prefer it. It is better to program in than 2.x. Iterators everywhere, no more unicode/encoding vagueness, sub-generators and more. It is a much better language and it's hard to see how it could have evolved without a clean break from its roots. However it has been interesting to follow over the last five years. It has been a sort of, "what if p5 broke the CPAN," scenario played out in real-life. Br…
I don't like Python 3. Iterators everywhere are incredibly annoying, especially with my development workflow, where I don't put a line of code into a file before I run it manually in the interpreter. When I run a map over a list, I just want to see the freaking results. Default unicode strings are obscenely annoying to me. Almost all of my code deals with binary data, parsing complex data structures, etc. The only "h…
> Iterators everywhere are incredibly annoying, especially with my development workflow, where I don't put a line of code into a file before I run it manually in the interpreter. When I run a map over a list, I just want to see the freaking results.
That's what list() is for:
>>> list(map(lambda x: x * x, xs))
> Default unicode strings are obscenely annoying to me. Almost all of my code deals with binary data, parsing complex data structures, etc. The only "human readable" strings in my code are logs. Why the hell should I worry about text encoding before sending a string into a TCP socket...> The fact that the combination of words "encode" and "UTF8" appear in my code, and str.encode('hex') is no longer available, is a very good representation of why I hate Python 3.
I'm afraid I don't understand your complaint. If you're parsing binary data then Python 3 is clearly superior than Python 2:
>>> "Hello, Gådel".encode("utf-8")
b'Hello, G\xc3\xa5del'
Seems much more reasonable than: >>> "Hello, Gådel".encode("utf-8")
Traceback (most recent call last):
File "", line 1, in
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 8: ordinal not in range(128)
Because they're not the same thing. Python 2 would implicitly "promote" a bytestring (the default literal) to a unicode object so long as it contained ASCII bytes. Of course this gets really tiresome and leads to Python 2's, "unicode dance." Armin seems to prefer it to the extra leg-work for correct unicode handling in Python 3 [0] however I think the trade-off is worth it and that pain will fade when the wider world catches up.> In Python 2, the rule of thumb was "If it makes sense, it's going to work". In Python 3, this isn't true. Not often, but often enough to annoy. This makes Python "feel" like Java to me.
Perhaps this is because you're a used to Python 2 and anything else is going to challenge your perceptions of the way it should work?
I don't understand the Java comparison.
> And worst of all, Python 3 has so many excellent features, like sub-generators, a better performing GIL, etc. These sometimes force me into coding with Python 3. I hate it every freaking time.
> I said to myself that with Python 3.4, due to great stuff like the new asyncio module, I'll have to make the switch. It's really sad that this is because I "have to" do it, and not because I "want to".
Well you can always attempt to backport these things into your own modules and keep Python 2 alive.
I think going whole-hog and embracing Python 3 is probably easier in the long run. I'm not sure how long the world is going to tolerate ASCII as the default text encoding given that its prevalence has largely been an artifact of opportunity. Unicode will eventually supplant it I have no doubt. It's good to be ahead of the curve.
[0] http://lucumr.pocoo.org/2013/7/2/the-updated-guide-to-unicod...