Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Python 3 new features say:

we’re mostly fixing well-known annoyances and warts, and removing a lot of old cruft

It mentions what is different (the fix) but not why (the problems). I have have not found what were the problems. What were the problems the fixes solve?

share|improve this question
    
One wart however, they didn't remove, is the reason to have to pass 'self' to a class method. Fail train. –  Rig Oct 1 '12 at 14:32
    
See also programmers.stackexchange.com/questions/220479/… –  User Dec 9 '13 at 15:44
add comment

1 Answer 1

I'll just name the ones that come to mind immediately.

  • Keyword-only arguments: Described in the rationale of the PEP.
  • nonlocal: Without this, closures can't overwrite variables closed over. This need arises from time to time with decorators and other higher-order functions. The only reasonable workaround (without switching the external API), storing whatever mutable state you want in a mutable object, is excessively ugly.
  • Dictionary and set comprehensions: Creating dictionaries and sets in a manner similar to list comprehensions is less pretty and slightly slower when done via generator comprehensions. It enables us to use these types where they are appropriate, without extra cost. Ditto for set literals, especially for in tests (as of Python 3.2, these are also optimized by the peephole optimizer).
  • Octal literals existed in Python 2, but the 0777 notation is a pitfall for those not used to it (in other contexts, adding a leading zero changes neither value nor base).
  • Binary literals are useful for bit fiddling, even moreso than hexadecimal literals.
  • Byte literals are a symptom of the enforced distinction between unicode strings and byte strings, and string literals being unicode. These changes force you to think about the difference between text and uninterpreted binary data and about encodings. This matters because otherwise you need extensive testing (with inputs us English-speaking, Europe/America-centric fools rarely ever think about) to find encoding-related errors.
  • except ex, var -> except ex as var fixes the common error except ValueError, IndexError (ought to catch both, but only catches the first and overwrites the name IndexError with the caught exception).
  • List comprehension scoping: Avoid polluting namespaces, and allow thinking of them in terms of generator expressions.
  • Removed syntax and modules: Bring us closer to "There should be one-- and preferably only one --obvious way to do it." and avoids people with poor tutorials sticking to the old & busted way of fixing things.
share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.