>From this interesting blog entry by Lawrence Oluyede:
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.readl ine(). 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
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.readl ine(). 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
Comment