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 -- https://mail.python.org/mailman/listinfo/python-list