>From this interesting blog entry by Lawrence Oluyede: http://www.oluyede.org/blog/2006/07/05/europython-day-2/ and the Py3.0 PEPs, I think the people working on Py3.0 are doing a good job, I am not expert enough (so I don't post this on the Py3.0 mailing list), but I agree with most of the things they are agreeing to. Few notes:
- input() vanishes and raw_input() becomes sys.stdin.readline(). I think a child that is learning to program with Python can enjoy something simpler: input() meaning what raw_input() means today. - dict.keys() and items() returns a set view This is being discussed here too a lot, I agree that they will just become equivalent to iterkeys() and iteritems(). - dict.values() a bag (multiset) view I think this isn't a good idea, I think bags can be useful but in this situation they make things too much complex. http://www.python.org/dev/peps/pep-3100/#core-language : - Set literals and comprehensions: {x} means set([x]); {x, y} means set([x, y]). {F(x) for x in S if P(x)} means set(F(x) for x in S if P(x)). NB. {range(x)} means set([range(x)]), NOT set(range(x)). There's no literal for an empty set; use set() (or {1}&{2} :-). There's no frozenset literal; they are too rarely needed. I like the idea of set literals, but using {1:2} for dicts and {1, 2} for sets may look a bit confusing. And using {} for the empty dict is confusing even more, newbies will use it a lot for empty sets. Maybe the {:} for the empty dict and {} for the empty set are a bit better. Maybe a better syntax can be use a different denotator, to distinguis the two structures better. Some possibilities are nice looking but not easy to type: «1, 2» Other may be confused with bitwise operators: |1, 2| Others are bad looking and not easy to type (some nationalized keyboards don't have the `): §1, 2§ `1, 2` Some of them are too much long: <<<1, ,2>>> Maybe using two nested like this is better (you can't put a dict or set in a set, so there are no ambiguities): {{1, 2}} I don't have a definitive good solution, but I think that adopting a bad solution is worse than using set(...). Set literals are cute but not necessary. Choosing things that increase the probability of bugs isn't good. --------------------- In the past I have suggested other possibilities for Py3.0, nothing really important, but few things can be interesting. - cmp() (or comp(), comp4(), etc) returns 4 values (<, ==, >, not comparable). - do - while. - NOT OR AND XOR as bitwise operators syntax. - Better syntax for octals and hex numbers. - obj.copy() and obj.deepcopy() methods for all objects. - Simplification and unification of string formatting (I have seen they are working on this already). - Intersection and subtraction among dicts. Less important things: - More human syntax for REs - Optional auto stripping of newlines during an iteration on a file. - String split that accepts a sequence of separators too. - a function in the math library to test for approximate FP equality. - something in cmath to do a better conversion of polar<->cartesian complex number conversion - xpermutations and xcombinations generators in the standard library. Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
