Time we switched to unicode? (was Explanation of this Python language feature?)

Rustom Mody rustompmody at gmail.com
Tue Mar 25 09:07:33 EDT 2014


On Tuesday, March 25, 2014 6:15:16 PM UTC+5:30, Chris Angelico wrote:
> On Tue, Mar 25, 2014 at 11:07 PM, Antoon Pardon
> > On 25-03-14 12:12, Chris Angelico wrote:
> >> On Tue, Mar 25, 2014 at 9:24 PM, Antoon Pardon
> >>> No they didn't have to. With the transition to python3, the developers
> >>> could have opted for empty braces to mean an empty set. And if they
> >>> wanted a literal for an empty dictionary, they might have chosen {:}.
> >>> Backward-compatibility was already broken so that wasn't an argument.
> >> Python 3.0 didn't just say "to Hades with backward compatibility". The
> >> breakage was only in places where it was deemed worthwhile. Changing
> >> the meaning of {} would have only small benefit and would potentially
> >> break a LOT of programs, so the devs were right to not do it.
> > More programs than those who broke because print was now a function?
> > Do you think it would have been so problamatic that it couldn't have
> > been handled by '2to3'?

> It makes the same notation mean different things, in ways that are
> hard to render clearly. You can write a Py3 program and put this at
> the top for Py2:

> try:
>     input = raw_input
>     range = xrange
> except NameError:
>     # We're running on Python 3
>     pass

> But you can't do the same for braces. You'd have to eschew *both*
> literal-ish notations and use explicit constructors everywhere. Not
> clean.

What you are answering (2) is somewhat different from what Anton is asking (1).

1. Use a tool (2to3 inspired) to help move programs to the the new lexicon
2. Use 2to3 to (help) write code that is backward-compatible 

It is an invariable given that when heavily compatible code is desired, the 
programmer gets the worst of all worlds



More information about the Python-list mailing list