31–40 of 40 posts
Earlier quoted context omitted.
It's a surprisingly useful feature.
Hi, might you be able to give a short example? Thanks!
Now, with ordered dictionaries, that order is maintained for free.
Kwarg order in functions is also maintained as far as I know.
Earlier quoted context omitted.
CPython is not the only Python interpreter out there.
The documentation sometimes suggests otherwise, but since there is no Python language specification, declaring something "part of the language" seems to have no meaning if it's not "implemented in CPython". PyPy has had ordered dicts for longer than CPython, and Jython and IronPython don't look like they're ever going to support Python 3, so I'm not sure who this declaration is even even hypothetically relevant to.
Earlier quoted context omitted.
A major library I use doesn’t work on 3.7 yet, so still stuck on 3.6. It’s sure nice to get bug fixes and security while I wait for the PR of my library to get merged. Very rare everyone can jump versions especially when there are syntax changes. In my case it’s around imports.
Imports changed between 3.6 and 3.7?
Something I've been wondering for years: I understand the rift between 2.x and 3.x.. But what is the rationale for maintaining multiple 3.x branches? And how do I choose the right branch for a fresh project? From experience, it seems like it doesn't really matter.
For a new project you definitely want to use Python 3 as Python will be EOL in 2020. For new projects I tend to favor Python 3.7 over 3.6. But sometimes I have to fall back to 3.6 because some packages have not been updated yet and I don't want to install them from Git(Hub) (e.g. GeoPandas through pyproj).
Dicts now retain order now (in other words all dicts are ordered dicts). I support this, but I also guarantee this is going to bite me in the ass at least once sharing notebooks with someone on an older version of python as I expect to use this liberally. Ah well.
> Dicts now retain order now (in other words all dicts are ordered dicts). I think you can be more clear here: all dicts are ordered by insertion order (not by key).
Earlier quoted context omitted.
It's a surprisingly useful feature.
Hi, might you be able to give a short example? Thanks!
This is a handy way of making classification rules for a many stepped process, where certain rules have priority over others. The alternative would be a lengthy set of ifs and elifs which is both ugly and not fun to edit on the fly.
Earlier quoted context omitted.
CPython implementation detail vs. Python language feature remains a relatively meaningless distinction.
CPython is not the only Python interpreter out there.
Earlier quoted context omitted.
On the note of stability, it's interesting to see which Linux distributions ship with which versions. Debian Stretch for instance ships with 3.5.3-1 while Ubuntu 18.04 LTS runs 3.6.5-3. I know some who would argue that Debian is generally the more stable server and Ubuntu more bleeding edge.
Debian Stretch was released June 2017 and Ubuntu 18.04, well, in April 2018, so its not too surprising that they ship with different Python versions. I do find it surprising that Linux distributions don’t always choose upstream LTS versions for their releases, it just feels like a big waste of effort to backport fixes across many versions.
Actually, Debian Stretch was released in April 2015, and their general freeze was set at November 2016.
Debian spends about 4 years producing a stable release, which excels at stability at the expense of using software releases that are far from the bleeding edge.
A hefty list if improvements to asyncio. When I tried working with asyncio in Python 3.4 it seemed half-baked and unpythonic. I look forward to trying out the more mature implementation.
Earlier quoted context omitted.
The documentation sometimes suggests otherwise, but since there is no Python language specification, declaring something "part of the language" seems to have no meaning if it's not "implemented in CPython". PyPy has had ordered dicts for longer than CPython, and Jython and IronPython don't look like they're ever going to support Python 3, so I'm not sure who this declaration is even even hypothetically relevant to.
It's relevant in the fact that you shouldn't rely on it as a programmer prior to this release. Changing it would have been considered a none breaking change.