7 ms·

there is this discussion (flame war?) about python3 not bringing too many benefits. i haven't made my mind yet. could you elaborate what you saw in 3.4 that was

there is this discussion (flame war?) about python3 not bringing too many benefits. i haven't made my mind yet. could you elaborate what you saw in 3.4 that was nice?

gamesbrainiac 12y ago
I'd like to know too. Are there any LLVM specific enhancements that python 3.4 brings to the table?
- exDM69 12y ago
  No. AFAIK, there's nothing related to LLVM in core Python. And not in 3.4 changes either.
exDM69 12y ago
Simply put: it's a better language. The whole "discussion" is whether it makes sense to migrate since many parts of the ecosystem (many important libraries and frameworks) have not made the transition. And many distros ship Python 2 by default, Python 3 is optional. Python 3 only is not feasible. To me, the killer feature is better lazy evaluation (generators). In particular, important builtins like map, filter, zip, enumerate, etc are generators, instead of returning lists. This makes it feasible to write things like (process(line) for line in map(str.upper, open('giantfile.txt')) if line.lstrip()[0] != '#') Some of the above can also be done with itertools package in Python 2, but not everything. Python 3.4 changelog is here, it contains e.g. asynchronous io facilities (asyncio module): https://www.python.org/downloads/release/python-342/ https://www.python.org/downloads/release/python-342/ edit: added enumerate() in the example above, for line in open(filename) returns a generator in Python 2.x too. edit2: enumerate is lazy in python2, I replaced it with map(str.upper)
- halflings 12y ago
  The example you gave works perfectly in Python 2.7 (would also be a generator, and you're not using map filter or else); but I agree: those should've been generators from day 1, especially zip and enumerate since they make more elegant code but often come with a performance overhead in Python 2.7
  - exDM69 12y ago
    Ah, you're absolutely right. for line in open(filename) returns a generator. I added map(str.upper, xxx) there to make it more it make sense. But the point should be obvious, without generators that would potentially consume a lot of memory.
  - danohuiginn 12y ago
    Turning them into generators would have broken a lot of existing code, though, so it's reasonable to leave them until a major version change. Rather, these are the kind of small, obviously-useful changes that should have come immediately in 3.0, giving people some encouragement to switch.
    - exDM69 12y ago
      Most of the breaking changes (including making map, zip, filter, etc lazy) were done in Python 3.0.
  - maxerickson 12y ago
    Python 2 enumerate returns an 'enumerate' object that is more or less a light weight wrapper of the sequence that was passed in. Generators provide a convenient syntax to implement that sort of object.
    - exDM69 12y ago
      D'oh. I put in a map(), that returns a list.
- danohuiginn 12y ago
  (process(line) for line in open('giantfile.txt') if line.lstrip()[0] != '#') Is that line really using any new features in Python 3? The lazy evaluation there is in the file object and the generator expression, both of which have long been present in python2.
  - exDM69 12y ago
    No, it wasn't. I added map(str.upper, xxx), now it does.
    - masklinn 12y ago
      Then again a lazy map is just an import away in P2. It removes pitfalls from Python but the improvement is… very limited (as opposed to e.g. `yield from` which is a big convenience, or for much more specialised uses the ellipsis literal being universal)
    - dalke 12y ago
      (process(line.upper()) for line in open('giantfile.txt') if line.lstrip()[0] != '#')
      - exDM69 12y ago
        That's besides the point. It's trivial to write that as a for loop or in a million different ways to avoid the issue. It's a contrived example written to demonstrate a difference. Here's another one you can't change that easily: tests_pass = all(process(input) == output for (input, output) in zip(open('inputs.txt'), open('outputs.txt'))
        andreasvc 12y ago
        You can change that easily, with izip from itertools. The fact that a bunch of builtins and the values/items methods of dictionaries have become iterators is not very siginificant IMHO. Python 2 code could already be written to use iterators or generator expressions, so in the parts where it was crucial it was already done. In this regard Python 3 has not added new functionality but only changed defaults. The unicode change is the big one.
- chrisheller 12y ago
  You'll get an IndexError exception on that if there are any blank lines in the file. Changing that to line.lstrip().startswith('#') would be an alternate approach.
  - exDM69 12y ago
    You're right but that is irrelevant, it's a somewhat contrived example anyway. It's not like I spent a lot of time trying it out.
- smazga 12y ago
  We went to Python 3 for the multiprocessing module. At the time it was 3.3, but now 3.4 has all that async magic. I wish I still worked on that project.
mkesper 12y ago
Saner handling of Unicode, for example.
- chc 12y ago
  This alone is pretty wonderful. I've only been working in Python a few months and the number of issues I've had to debug in 2.7 that came down to Unicode handling is kind of nuts.
baq 12y ago
much better exceptions and sane unicode are the biggest improvements.
ak217 12y ago
Without listing any of the modules or improvements that are in the standard library in 3 but backported as PyPI modules to 2 (of which there are many), here are the features that I actually use in Python 3: unicode handling that isn't insane, function annotations, async improvements, exception chaining, enums, single-dispatch generics, better SSL support, generator delegation, better int-bytes conversion support, unittest module improvements. The key point is that 2.7 is a language frozen in time, while 3.4+ is continuing to develop and improve. And most of the hand-wringing was before the critical mass of third-party modules was ported to 3.x. https://docs.python.org/3/whatsnew/3.4.html https://docs.python.org/3/whatsnew/3.4.html https://docs.python.org/3/whatsnew/3.3.html https://docs.python.org/3/whatsnew/3.3.html https://docs.python.org/3/whatsnew/3.2.html https://docs.python.org/3/whatsnew/3.2.html https://docs.python.org/3/whatsnew/3.1.html https://docs.python.org/3/whatsnew/3.1.html https://docs.python.org/3/whatsnew/3.0.html https://docs.python.org/3/whatsnew/3.0.html
ngoldbaum 12y ago
My favorite new feature is PEP-442 [0]. Basically, it's now safe to add a __del__ method to a class without worrying about memory leaks caused by reference cycles. [0] https://www.python.org/dev/peps/pep-0442/ https://www.python.org/dev/peps/pep-0442/
- pekk 12y ago
  Most people should not be writing __del__ methods at all, especially if what they are trying to do is deterministic cleanup.
bkeroack 12y ago
Add to the list: - function annotations (allows runtime type checking via third party modules) - asyncio (not as easy to use as Go's goroutines but still vastly superior to the multiprocessing module)
andreasvc 12y ago
I can't say I disagree with such sentiments, but over time I've ran into a few issues (features and performance improvements) which where only addressed in Python 3. This is reason enough to try working with Python 3.

there is this discussion (flame war?) about python3 not bringing too many benefits. i haven't made my mind yet. could you elaborate what you saw in 3.4 that was nice?

gamesbrainiac 12y ago

I'd like to know too. Are there any LLVM specific enhancements that python 3.4 brings to the table?

exDM69 12y ago
No. AFAIK, there's nothing related to LLVM in core Python. And not in 3.4 changes either.

exDM69 12y ago

Simply put: it's a better language. The whole "discussion" is whether it makes sense to migrate since many parts of the ecosystem (many important libraries and frameworks) have not made the transition. And many distros ship Python 2 by default, Python 3 is optional. Python 3 only is not feasible. To me, the killer feature is better lazy evaluation (generators). In particular, important builtins like map, filter, zip, enumerate, etc are generators, instead of returning lists. This makes it feasible to write things like (process(line) for line in map(str.upper, open('giantfile.txt')) if line.lstrip()[0] != '#') Some of the above can also be done with itertools package in Python 2, but not everything. Python 3.4 changelog is here, it contains e.g. asynchronous io facilities (asyncio module): https://www.python.org/downloads/release/python-342/ https://www.python.org/downloads/release/python-342/ edit: added enumerate() in the example above, for line in open(filename) returns a generator in Python 2.x too. edit2: enumerate is lazy in python2, I replaced it with map(str.upper)

halflings 12y ago
The example you gave works perfectly in Python 2.7 (would also be a generator, and you're not using map filter or else); but I agree: those should've been generators from day 1, especially zip and enumerate since they make more elegant code but often come with a performance overhead in Python 2.7
- exDM69 12y ago
  Ah, you're absolutely right. for line in open(filename) returns a generator. I added map(str.upper, xxx) there to make it more it make sense. But the point should be obvious, without generators that would potentially consume a lot of memory.
- danohuiginn 12y ago
  Turning them into generators would have broken a lot of existing code, though, so it's reasonable to leave them until a major version change. Rather, these are the kind of small, obviously-useful changes that should have come immediately in 3.0, giving people some encouragement to switch.
  - exDM69 12y ago
    Most of the breaking changes (including making map, zip, filter, etc lazy) were done in Python 3.0.
- maxerickson 12y ago
  Python 2 enumerate returns an 'enumerate' object that is more or less a light weight wrapper of the sequence that was passed in. Generators provide a convenient syntax to implement that sort of object.
  - exDM69 12y ago
    D'oh. I put in a map(), that returns a list.
danohuiginn 12y ago
(process(line) for line in open('giantfile.txt') if line.lstrip()[0] != '#') Is that line really using any new features in Python 3? The lazy evaluation there is in the file object and the generator expression, both of which have long been present in python2.
- exDM69 12y ago
  No, it wasn't. I added map(str.upper, xxx), now it does.
  - masklinn 12y ago
    Then again a lazy map is just an import away in P2. It removes pitfalls from Python but the improvement is… very limited (as opposed to e.g. `yield from` which is a big convenience, or for much more specialised uses the ellipsis literal being universal)
  - dalke 12y ago
    (process(line.upper()) for line in open('giantfile.txt') if line.lstrip()[0] != '#')
    - exDM69 12y ago
      That's besides the point. It's trivial to write that as a for loop or in a million different ways to avoid the issue. It's a contrived example written to demonstrate a difference. Here's another one you can't change that easily: tests_pass = all(process(input) == output for (input, output) in zip(open('inputs.txt'), open('outputs.txt'))
      - andreasvc 12y ago
        You can change that easily, with izip from itertools. The fact that a bunch of builtins and the values/items methods of dictionaries have become iterators is not very siginificant IMHO. Python 2 code could already be written to use iterators or generator expressions, so in the parts where it was crucial it was already done. In this regard Python 3 has not added new functionality but only changed defaults. The unicode change is the big one.
chrisheller 12y ago
You'll get an IndexError exception on that if there are any blank lines in the file. Changing that to line.lstrip().startswith('#') would be an alternate approach.
- exDM69 12y ago
  You're right but that is irrelevant, it's a somewhat contrived example anyway. It's not like I spent a lot of time trying it out.
smazga 12y ago
We went to Python 3 for the multiprocessing module. At the time it was 3.3, but now 3.4 has all that async magic. I wish I still worked on that project.

mkesper 12y ago

Saner handling of Unicode, for example.

chc 12y ago
This alone is pretty wonderful. I've only been working in Python a few months and the number of issues I've had to debug in 2.7 that came down to Unicode handling is kind of nuts.

baq 12y ago

much better exceptions and sane unicode are the biggest improvements.

ak217 12y ago

Without listing any of the modules or improvements that are in the standard library in 3 but backported as PyPI modules to 2 (of which there are many), here are the features that I actually use in Python 3: unicode handling that isn't insane, function annotations, async improvements, exception chaining, enums, single-dispatch generics, better SSL support, generator delegation, better int-bytes conversion support, unittest module improvements. The key point is that 2.7 is a language frozen in time, while 3.4+ is continuing to develop and improve. And most of the hand-wringing was before the critical mass of third-party modules was ported to 3.x. https://docs.python.org/3/whatsnew/3.4.html https://docs.python.org/3/whatsnew/3.4.html https://docs.python.org/3/whatsnew/3.3.html https://docs.python.org/3/whatsnew/3.3.html https://docs.python.org/3/whatsnew/3.2.html https://docs.python.org/3/whatsnew/3.2.html https://docs.python.org/3/whatsnew/3.1.html https://docs.python.org/3/whatsnew/3.1.html https://docs.python.org/3/whatsnew/3.0.html https://docs.python.org/3/whatsnew/3.0.html

ngoldbaum 12y ago

My favorite new feature is PEP-442 [0]. Basically, it's now safe to add a __del__ method to a class without worrying about memory leaks caused by reference cycles. [0] https://www.python.org/dev/peps/pep-0442/ https://www.python.org/dev/peps/pep-0442/

pekk 12y ago
Most people should not be writing __del__ methods at all, especially if what they are trying to do is deterministic cleanup.

bkeroack 12y ago

Add to the list: - function annotations (allows runtime type checking via third party modules) - asyncio (not as easy to use as Go's goroutines but still vastly superior to the multiprocessing module)

andreasvc 12y ago

I can't say I disagree with such sentiments, but over time I've ran into a few issues (features and performance improvements) which where only addressed in Python 3. This is reason enough to try working with Python 3.