python-dev summary, July 16-31
Carel Fellinger
have my posting sent of to some moderator. So let me retry in case the
other doesn't make it into c.l.py.
Andrew Kuchling <akuc...@mems-exchange.org> wrote:
...
> As usual I'm writing up an explanation of the changes in 2.2:
> http://www.amk.ca/python/2.2/
Thanks for making such nice overviews, I always check them out to see
how beatifull the next Python is going to be.
But on this explanatory page I was a bit surprised in your treatment of
the iter protocol regarding dictionaries. It lumbed together both uses
of in, the __contains__() version and the next() one. The fact that
"key in dict" is now equivalent to "dict.has_key(key)" has nothing to
do with the iterability of dicts, at least that's what I've understood
sofar.
--
groetjes, carel
Andrew Kuchling
> Thanks for making such nice overviews, I always check them out to see
You're welcome.
> of in, the __contains__() version and the next() one. The fact that
> "key in dict" is now equivalent to "dict.has_key(key)" has nothing to
> do with the iterability of dicts, at least that's what I've understood
> sofar.
You're quite correct that they're not really related; either change
could have been made independently of the other. It just seemed
clearest to cheat a bit and mention the 'X in dict' change at that
point. Otherwise the only reasonable place to describe it would have
been down in the "Other Changes and Fixes" section, and I'm not sure
many people actually bother to read that far, as most of the items in
that section are pretty esoteric.
--amk
Just van Rossum
But there has always been a nice symmetry between "if x in y" and
"for x in y", so it is much nicer to have "if key in dict" if you
*also* have "for key in dict". While the implementations have indeed
little in common, I think it's a little unfair to say they have
nothing to do with each other.
Just
Carel Fellinger
> You're quite correct that they're not really related; either change
> could have been made independently of the other. It just seemed
> clearest to cheat a bit and mention the 'X in dict' change at that
> point. Otherwise the only reasonable place to describe it would have
Ah, I see. But as written now it's a little confusing, atleast to me.
Maybe adding some words might help, like:
Iterator support has been added to some of Python's basic types. The
in operator now works on dictionaries; as an aside, fortunately the
related key in dict also works and is now equivalent to dict.has_key(key).
Calling iter() on a dictionary will return an iterator which loops over
its keys:
--
groetjes, carel
François Pinard
> But there has always been a nice symmetry between "if x in y" and
> "for x in y",
About that one, it always saddened me a little bit that I may not write:
if x in 1, 2, 3:
pass
while I can write:
for x in 1, 2, 3:
pass
In the first, I write the parentheses so it gets accepted, but I would
prefer not using them. It breaks some of the symmetry, in my opinion :-).
--
François Pinard http://www.iro.umontreal.ca/~pinard
Peter Hansen
>
> [Just van Rossum]
>
> > But there has always been a nice symmetry between "if x in y" and
> > "for x in y",
>
> About that one, it always saddened me a little bit that I may not write:
>
> if x in 1, 2, 3:
> pass
>
> while I can write:
>
> for x in 1, 2, 3:
> pass
I would never have thought to write either of these. On the other
hand, if I did write things the second way, I would _expect_ that
the first one would work as well.
> In the first, I write the parentheses so it gets accepted, but I would
> prefer not using them. It breaks some of the symmetry, in my opinion :-).
It's not so much that symmetry is missing -- it just doesn't follow
the "rule of least surprise", does it?
--
----------------------
Peter Hansen, P.Eng.
pe...@engcorp.com
Alex Martelli
news:3B7085F9...@engcorp.com...
> François Pinard wrote:
...
> > About that one, it always saddened me a little bit that I may not write:
> >
> > if x in 1, 2, 3:
> > pass
> >
> > while I can write:
> >
> > for x in 1, 2, 3:
> > pass
>
> I would never have thought to write either of these. On the other
> hand, if I did write things the second way, I would _expect_ that
> the first one would work as well.
>
> > In the first, I write the parentheses so it gets accepted, but I would
> > prefer not using them. It breaks some of the symmetry, in my opinion
:-).
>
> It's not so much that symmetry is missing -- it just doesn't follow
> the "rule of least surprise", does it?
I fully agree, so I just submitted a feature request to sourceforge --
hopefully one doesn't have to write a PEP for _this_ sort of stuff?-)
Alex
François Pinard
> > > About that one, it always saddened me a little bit that I may not write:
> > >
> > > if x in 1, 2, 3:
> > > pass
> > >
> > > while I can write:
> > >
> > > for x in 1, 2, 3:
> > > pass
> "Peter Hansen" <pe...@engcorp.com> wrote:
> > I would never have thought to write either of these.
Really? You write parentheses all the time?
Whenever language I use, I try to avoid abusing parentheses, as using them
often leaves me with the bad feeling I do not know the language enough,
and that I write it fuzzily, adding parentheses "just in case"... :-)
Of course, for many languages, parentheses could be effectively used to
increase legibility. But for marking tuples, Python does not need them
in most cases, it may be more noisy than useful having them to mark tuples
when it is not required to do so. Python sources are cleaner without such
spurious parentheses, and it is a good habit learning to avoid them.
There is one case, however, where using parentheses with tuples is worth
doing, and this is for long lists of tuple elements spanning more than one
line. Parentheses combined with proper indenting help the eye at catching
the overall structure. For short tuples that fit on a line, parentheses are
overkill to me.
[Alex Martelli]
> I fully agree, so I just submitted a feature request to sourceforge --
> hopefully one doesn't have to write a PEP for _this_ sort of stuff?-)
Thanks a lot for the attempt. I'm not sure how it will go. In:
for x in 1, 2, 3:
pass
the `in' is nothing more than a mandated keyword. But with:
if x in 1, 2, 3:
pass
the `in' is an operator, and as such, has its priority relative to a comma.
It might not be easy adjusting this without breaking anything.
Peter Hansen
>
> > > François Pinard wrote:
>
> > > > About that one, it always saddened me a little bit that I may not write:
> > > >
> > > > if x in 1, 2, 3:
> > > > pass
> > > >
> > > > while I can write:
> > > >
> > > > for x in 1, 2, 3:
> > > > pass
>
> > "Peter Hansen" <pe...@engcorp.com> wrote:
>
> > > I would never have thought to write either of these.
>
> Really? You write parentheses all the time?
No, just when I write tuples! <wink>
Yes, I *definitely* use parentheses around tuples all the time.
(a) One obvious way to do things.
(b) I never knew there was another way at first, and the habit stuck.
(c) Fits my brain better, since I see parentheses and think "tuple".
(My brain has to pause, perhaps, when a function with arguments
is called. I don't notice the pause, apparently. :-)
> Whichever language I use, I try to avoid abusing parentheses, as using them
> often leaves me with the bad feeling I do not know the language enough,
> and that I write it fuzzily, adding parentheses "just in case"... :-)
(d) I heavily abuse parentheses for complex expressions, since I'm
a programmer of very little brain (ref. Winnie the Pooh).
I almost never rely on my recollection of operator precedence.
Since this has nothing to do with tuples, I wouldn't consider
using parentheses for tuples to be "abusive" in any way, just
a syntax which, for me, might as well be required.
> Of course, for many languages, parentheses could be effectively used to
> increase legibility. But for marking tuples, Python does not need them
> in most cases, it may be more noisy than useful having them to mark tuples
> when it is not required to do so. Python sources are cleaner without such
> spurious parentheses, and it is a good habit learning to avoid them.
You haven't convinced me yet, other than the "slightly less noise"
argument. Other than that one debatable advantage (which may not
outweigh the associated disadvantages, to me), do you have any
other reasons you think it's a good habit to avoid this?
> There is one case, however, where using parentheses with tuples is worth
> doing, and this is for long lists of tuple elements spanning more than one
> line. Parentheses combined with proper indenting help the eye at catching
> the overall structure. For short tuples that fit on a line, parentheses are
> overkill to me.
For me, this paragraph leads me conclusively back to my current view:
use parentheses for all tuples.
To do otherwise would be inconsistent, and to me
(inconsistency == unmaintainability) .
Thomas Bellman
> There is one case, however, where using parentheses with tuples is worth
> doing, and this is for long lists of tuple elements spanning more than one
> line. Parentheses combined with proper indenting help the eye at catching
> the overall structure. For short tuples that fit on a line, parentheses are
> overkill to me.
There are a couple of other occasions where you *should* use
parentheses, or you won't get what you want:
* When the tuple is an argument to a function call.
foo(1,2,3) and foo((1,2,3)) are very different things.
* When the tuple is an element in a list or another tuple.
[1,2,3,4,5,6] and [1,(2,3),(4,5),6] are very different.
* When the tuple is a key or a value in a dictionary:
{ (1,2):"one and two", "three and four":(3,4) } works, while
{ 1,2:"one and two", "three and four":3,4 } doesn't.
> for x in 1, 2, 3:
> pass
I would always write this as
for x in [ 1, 2, 3 ]:
pass
Hmm, actually, on closer consideration, I think I would write
it as
x = 3
:-)
--
Thomas Bellman, Lysator Computer Club, Linköping University, Sweden
"God is real, but Jesus is an integer." ! bellman @ lysator.liu.se
! Make Love -- Nicht Wahr!
Thomas Bellman
> I would always write this as
> for x in [ 1, 2, 3 ]:
> pass
I should probably explain this some more.
To me, a tuple isn't something that you iterate over. A tuple is
a lightweight record. The equivalent of a struct i C, but with
unnamed members. The difference between lists and tuples isn't
really that tuples are read-only, but in how they are used.
A list typically holds a number of homogeneous elements. All
elements are to be treated more or less the same. The length
of the list is often not fixed. The elements of the list might
be of different Python types or classes,
The elements of a tuple, on the other hand, are heterogeneous.
They might be of the same Python type, but they don't mean the
same thing. An example is the return value from time.gmtime():
the elements are all integers, but they have vastly different
meanings. Coordinates is another example: the X, Y and Z
coordinates in a three-dimensional room have distinct meanings,
and it is seldom meaningful to iterate over the three values in a
single coordinate triple and doing a certain operation on each of
them. In C you would implement a coordinate as
struct coord_3d {
double x,y,z;
};
not as
typedef double coord_3d[3];
Sure, there are examples when you want to iterate over the
elements in the struct/tuple, like when implementing matrix
multiplication, but those are special cases, not the norm for
how a tuple *should* be used.
--
Thomas Bellman, Lysator Computer Club, Linköping University, Sweden
"I don't think [that word] means what you ! bellman @ lysator.liu.se
think it means." -- The Princess Bride ! Make Love -- Nicht Wahr!
François Pinard
> There are a couple of other occasions where you *should* use parentheses,
> or you won't get what you want [... good examples deleted ...]
Of course. *Then*, it is very worth writing them.
> > for x in 1, 2, 3:
> > pass
> Hmm, actually, on closer consideration, I think I would write
> it as
> x = 3
> :-)
Yes. I was not sure it was a good idea to write `pass' in my examples! :-)
François Pinard
> François Pinard wrote:
> > Really? You write parentheses all the time?
> No, just when I write tuples! <wink> Yes, I *definitely* use parentheses
> around tuples all the time.
> (a) One obvious way to do things.
> (b) I never knew there was another way at first, and the habit stuck.
> (c) Fits my brain better, since I see parentheses and think "tuple".
> (My brain has to pause, perhaps, when a function with arguments
> is called. I don't notice the pause, apparently. :-)
But in fact, your brain comes to just accept the magic of writing without
parentheses, not having to resort all the time to explicit tuple packing and
unpacking. Not that you forget how things work, of course, but both your
writings and mind get a bit less encumbered. Let's take a small example.
It is so simple to write:
dictionary[index1, index2] = value
everywhere, in those applications where "dictionary" is to be indexed
with a 2-tuple. Just think as an associative array with two indexes,
it's easier. We do know that there is only one index deep down, and that
tuple packing occurs. But this is all part of the Python built-in mechanics,
which you would underline by writing:
dictionary[(index1, index2)] = value
Do we really need to stress the inner workings everywhere? It is more
relaxing to avoid doing so. And Python looks even more powerful! :-)
> > Of course, for many languages, parentheses could be effectively used to
> > increase legibility. But for marking tuples, Python does not need them
> > in most cases, it may be more noisy than useful having them to mark tuples
> > when it is not required to do so.
> You haven't convinced me yet, other than the "slightly less noise"
> argument.
I'm not really trying to convince you, as stylistic issues are often prone to
religious feelings. On the other hand, it is often good to compare styles.
My own style improved faster, when I started to look at what others do.
We pick and absorb little things that we like, here and there.
> To do otherwise would be inconsistent, and to me
> (inconsistency == unmaintainability) .
Quite agreed. I'm very sensitive to inconsistent style when I read code,
it hurts the pleasure I have to read, and I'm torn between the the desire to
report these things, and the feeling people would badly receive my comments.
François Pinard
> I wrote:
> > I would always write this as
> > for x in [ 1, 2, 3 ]:
> > pass
> I should probably explain this some more. To me, a tuple isn't something
> that you iterate over. [...] The difference between lists and tuples
> isn't really that tuples are read-only, but in how they are used. [...]
I understand all the nuances you make, and give you reason on them, as I
felt the same not long after I started to write Python code.
On the other hand, tuples are slightly more efficient than lists. I think
(but am not fully sure) they are a bit more efficiently accessed, in that
there is no indirection from the tuple structure to the sequence of values,
and also, there is no overshoot allocation meant for possible growing.
So, even if we "think" lists, it is better to "write" tuples, despite they
do look more awkward given the context. This has been a good incentive,
for me, at writing:
for x in 1, 2, 3:
pass
Because you do not commit yourself towards tuples or lists, your writing
stays clear, and Python merely does the most efficient choice internally.
Guido van Rossum
Exactly.
Thanks for an excellent explanation of the difference between tuples
and lists!
--Guido van Rossum (home page: http://www.python.org/~guido/)
Thomas Bellman
> bel...@lysator.liu.se (Thomas Bellman) writes:
[...]
> Exactly.
> Thanks for an excellent explanation of the difference between tuples
> and lists!
No problem. If you or anyone want to use it in any documentation
or otherwise, please feel free to do so.
--
Thomas Bellman, Lysator Computer Club, Linköping University, Sweden
"God is real, but Jesus is an integer." ! bellman @ lysator.liu.se
Cliff Crawford
|
| "God is real, but Jesus is an integer."
Satan is surely a float.
((10.0/3.0)*2)<>((2.0/3.0)*10)-ly y'rs, Cliff
--
Cliff Crawford http://www.sowrong.org/
"If only you could see what I have seen through your eyes..."