«

>From this interesting blog entry by Lawrence Oluyede:
http://www.oluyede.org/blog/2006/07/...opython-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

enlightened us with:
> I like the idea of set literals, but using {1:2} for dicts and {1,
> 2} for sets may look a bit confusing.

I agree with you. Curly brackets are used for dicts, and using them
for sets too is confusing. I know I will get confused every now and
then, and I've got a Bachelor degree in Computer Science...

> 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.

Still too much confusion IMO.

> 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»

I guess « and » are difficult to type on many systems. I just press
Compose, <, < to get «, but on other systems it'll be difficult.

> 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}}

But you can put a set in a dict...

> 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.

I fully agree with you.

> - Better syntax for octals and hex numbers.

Would be nice to have binary numbers to! Something like 0b111000 for
instance.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

Sybren Stuvel:
> But you can put a set in a dict...

Only as values, not as keys, because sets are mutable.

Bye,
bearophile

wrote:
> >From this interesting blog entry by Lawrence Oluyede:
> http://www.oluyede.org/blog/2006/07/...opython-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.

No one expected them to do a bad job, but there is nothing really new
or interesting or challenging. Micro-optimizations and shape lifting.
Even a small discussion about the frictions of pattern matching and OO
with Martin Odersky, one of the creators of the Scala language, is more
inspiring than reading the whole Py3K stuff. I decided not to attend to
EuroPython this year...

Kay Schluehr:
> there is nothing really new or interesting or challenging.
> Micro-optimizations and shape lifting.

I see. Maybe Python is becoming a commodity used by more than 10e6
persons, so changellenges aren't much fit anymore.
Guido has tried to avoid the problems of Perl6, making Py3.0 a
improvement and not a revolution. The good thing is that we'll probably
see a beta version in 14-18 months. Py3.0 from being like fantasy is
become something close, this is a good thing.
I may ask you what you would like to see in Py3.0, but remember that
your answer may become ignored by the developers.

Bye,
bearophile

wrote:
> Kay Schluehr:
>
>>there is nothing really new or interesting or challenging.
>>Micro-optimizations and shape lifting.
>
>
> I see. Maybe Python is becoming a commodity used by more than 10e6
> persons, so changellenges aren't much fit anymore.
> Guido has tried to avoid the problems of Perl6, making Py3.0 a
> improvement and not a revolution. The good thing is that we'll probably
> see a beta version in 14-18 months. Py3.0 from being like fantasy is
> become something close, this is a good thing.
> I may ask you what you would like to see in Py3.0, but remember that
> your answer may become ignored by the developers.
>
The real problems with the Py3k list seem to be associated with a number
of people who, despite having had little apparent connection to the
language until now, have joined the list and started making
inappropriate suggestions, which then have to be (patiently) rejected.

regards
Steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://holdenweb.blogspot.com
Recent Ramblings http://del.icio.us/steve.holden

On 2006-07-05, <> wrote:
> Kay Schluehr:
>> there is nothing really new or interesting or challenging.
>> Micro-optimizations and shape lifting.
>
> I see. Maybe Python is becoming a commodity used by more than 10e6
> persons, so changellenges aren't much fit anymore.
> Guido has tried to avoid the problems of Perl6, making Py3.0 a
> improvement and not a revolution. The good thing is that we'll probably
> see a beta version in 14-18 months. Py3.0 from being like fantasy is
> become something close, this is a good thing.
> I may ask you what you would like to see in Py3.0, but remember that
> your answer may become ignored by the developers.

These are just some ideas. Whether they fit into python or not I will
leave to the developers.

1) Literal slices, in a sense we already have these, but they are
limited to indexing. You can't do something like fun(:. May
be this means the notation used now has to be adapted.


2) Iterable slices. Allow (provided the slice notation stays

for i in (1:10):
...

to do the same as:

for i in xrange(1,10):

This will allow to get rid of both range and xrange. Xrange
is totally unnecessary and range(a,b) becomes list(a:b).


4) Introduce Top and Bottom objects, which will allways
compare greater/smaller to other objects. Make them
the default values for the start and stop values of
slices.


5) Give slices a "&" and "|" operator.


7) Give slices the possibility to include the stop value.

My first idea here was that the notation of slices
was adapted, so that what is a:b now would become
ab. A slice to include the b would then be a::b.
You could even have a slice that didn't include the
a but included the b like: a|:b

Now I expect a lot of resitance here, so it this
seems not feasable, just drop it.


6) Is this is all asked too much, make slice at least
subclassable.


--
Antoon Pardon

Antoon Pardon <> wrote:

> These are just some ideas. Whether they fit into python or not I will
> leave to the developers.

I'm not a Python pro. but:

> 1) Literal slices, in a sense we already have these, but they are
> limited to indexing. You can't do something like fun(:. May
> be this means the notation used now has to be adapted.

I don't see the use case for this.

> 2) Iterable slices. Allow (provided the slice notation stays
>
> for i in (1:10):
> ...
>
> to do the same as:
>
> for i in xrange(1,10):
>
> This will allow to get rid of both range and xrange. Xrange
> is totally unnecessary and range(a,b) becomes list(a:b).

-1. First: you have to introduce new syntax for an old thing. Second:
you overload the meaning of slicing and the slice operator and so on.
range is perfectly integrated and the right tool for the job. There's no
need to introduce new syntax to iterate over a range of integers.

> 4) Introduce Top and Bottom objects, which will allways
> compare greater/smaller to other objects. Make them
> the default values for the start and stop values of
> slices.
> 5) Give slices a "&" and "|" operator.
>
>
> 7) Give slices the possibility to include the stop value.
>
> My first idea here was that the notation of slices
> was adapted, so that what is a:b now would become
> ab. A slice to include the b would then be a::b.
> You could even have a slice that didn't include the
> a but included the b like: a|:b
>
> Now I expect a lot of resitance here, so it this
> seems not feasable, just drop it.
>
>
> 6) Is this is all asked too much, make slice at least
> subclassable.

Why do you need power slices?

--
Lawrence - http://www.oluyede.org/blog
"Nothing is more dangerous than an idea
if it's the only one you have" - E. A. Chartier

Steve Holden:
> The real problems with the Py3k list seem to be associated with a number
> of people who, despite having had little apparent connection to the
> language until now, have joined the list and started making
> inappropriate suggestions, which then have to be (patiently) rejected.

This attitude may have some downsides. The Python developers don't know
everything, other people can have some experience of computer languages
too. So people coming from different languages, like Erlang, Ruby,
Dylan, Io, CommonLisp, C#, Haskell, and Lua can give useful suggestions
to update and 'improve' Python. Often their suggestions can be unfit
for Python, but if you don't waste a little of time evaluating their
ideas, you lose some possibilities. Python 3.0 isn't just an occasion
to remove some rust and obsolete things from Python, but a way to
invent and adopt different ideas too. So I think wasting some time in
that way is positive for Py 3.0 devs.

Bye,
bearophile

I really like the set notation idea. Now that sets are first class
"citizens" along with dicts, lists and tuples I think they should be
used when it makes sense to use them A keyset of a dictionary should be
viewed as a set not a list because it is a key_set_ after all. Also
sets should get back their traditional notation of '{' and '}', which
dictionaries have been in 'borrowing' for all this time in Python.

When defining a non-empty set it could be unambiguous to share the
notation. So :
{1,2,3} is set([1,2,3])
while
{1:'a', 2:'b', 3:'c'} could still be the a dictionary. Of course then
{1, 2, 3:'b'} would be undefined and would raise an exception or
alternatively be equivalent to {1:None, 2:None, 3:'b'} - a dictionary.

As far as the set and dictionary notation being "confusing" it seems
that a common notation is actually a _benefit_, after all sets and
dictionaries are not that different! A dictionary is a mapping
(surgective explicit function?) from a _set_ of keys to a set
(actually a bad or multiset in Python) of values. At the same time a
set can also be regarded as a degenerate dictionary as in {1:None,
2:None, 3:None}. A similarity of notation does make sense to me.

Of course the empty set is the problem since {} could be interpreted
ambiguously as both a set or a dictionary. I think it makes sense to
give the '{}' notation to the empty _set_ as this will make more sense
as far as common sense goes. If the proposal is to have {x} be the a
set([x]) then it only makes sense for {} be a set([]). This will break
compatibility with old code and that is why it should be in Python 3000
not in 2.x.x The empty dictionary is probably best represented as {:},
it is actually more clear this way as it shows that there is a key and
a value separated by ':' and in this case they are both missing so it
is an empty dictionary.

Also the frozenset, although not used as often, could still probably
get its own notation too.
For example:
1. ({1,2,3}) - a symmetry with tuples, which are also immutable.
The problem of a one element tuple i.e. (10,) not (10) will also be
present here. So just as there is a need to use a comma to make
(10,)=tuple([10]) one would have to use a comma to specify that a tuple
is needed and not a a frozenset() but at the same time the ({1,2,3})
could then never be reduced to {1,2,3}.
In other words:
({1,2,3},) is tuple({1,2,3})
({1,2,3}) is a frozenset([1,2,3]) and never just {1,2,3}.
This notation would make the parser go 'nuts'. I think the next idea
might be better:

2. _{1,2,3}_ - the underscores '_' intuitively could mean that the
braces are fixed blocks and will not "move" to accomodate addition or
removal of elements i.e. the fact that the frozenset is immutable. Or
perhaps a more verbose _{_1,2,3_}_ would be better, not sure...

3. {|1,2,3|} or maybe |{1,2,3}| - same aesthetic rationale as above,
'|'s look like 'fences' that will not allow the braces to 'move', but
this would look to much like Ruby's blocks so 1 and 2 might be better.

In general a 'set' are a fundamental data structure. It has always been
secondary in traditional programming languages. For simplicity in
implementation arrays and lists have been used to mimic a set. Now
that Python has a built in set it only makes sense to give it its own
notation and maybe Python 3000 is just the right time for it.

- Nick Vatamaniuc

wrote:
> >From this interesting blog entry by Lawrence Oluyede:
> http://www.oluyede.org/blog/2006/07/...opython-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