PEP 276 (was Re: Status of PEP's?)

Carel Fellinger cfelling at iae.nl
Fri Mar 1 23:49:28 EST 2002


James_Althoff at i2.com wrote:

Jim, I think I finally solved the riddle.

>From your first post on this subject I had this voice in the back of
my head telling me: think objects.  The post I'm responding to now
reinforced that voice, so I finally gave in:)

[[ I've always found explainig things in writing difficult, I much
rather talk to a participating audience.  When I write, so many side
tracks pop up that my point easily gets blurred. I do my best to
constrain myself, though the posting doesn't show this, and I do think
I've a point to make here, so bear with me ]]


To me the world of objects in programs stops at the level of integers.
That used to be the case for python1.5.2 too:

    >>> dir(1)
    []
    >>> (1).__add__(2)
    Traceback (innermost last):
      File "<stdin>", line 1, in ?
    AttributeError: 'int' object has no attribute '__add__'

I know that under the hood integers can be objects too, but to me that
isn't fundamental.  I see it more as an implementation decission.

In 2.2 we happily see the type/class split healed.  And one of the
consequences of that is that we now *see* that integers have methods,
we can even call them:

    >>> (1).__add__(2)
    3

To you, comming from smalltalk, that's just how it's supposed to be,
but to me it looks a little awkward.  Probably because to me integers
are a mathematical abstraction, and I don't see how it could know how
to add.  Addition is something that's not inherent to integers but a
layer that's put on top of integers.  I guess this just goes to show
my ignorance on mathematical issues:(

And now you're stretching this object oriented view of integers even
further.  You ask an integer to iterate or, if you like, to count.


The funny thing however is that I don't have this reservation with
strings:) Strings to me have always been a programmers construct,
there are no character strings in the real world, but they sure come
in handy in a program.  When I made the switch to OO I saw that it was
practical and sound to put the actions and the data together.  So the
same for strings.  I ask a string whether it has uppercase chars, I
ask it to split itself, to count itself (len).  I'm even prepared to
ask it to translate itself. No problem.  I just never made that step
for numbers.

And I'm not alone in that.  I remember from the 80's that there were
heated discussions whether to go `all the way' and define integers to
be objects or stop at the level of some primitive types when defining
the object hierarchy.  There were implementation issues but also
filosofical and usability considerations.  Some language designers
choose to hide the object nature of integers from the programmers and
provided a bunch of syntactic sugar solely to make number manipulation
look more like ordinary math.


To conclude, you propose to go `all the way' with treating integers as
objects, and some of use haven't been exposed to such a thing long
enough to either be blind for its pecularity or to finally appreciate
its soundness.

I think given enough time and exposure I can get to appreciate it,
I don't know for the public in general.  And though we hardly hear
off it these days, Guido is aiming at `programming for everybody'.


...
> This has been suggested and is fine for one-dimensional,
> indexed-collections that are written in Python and obey the standard
> protocol for sequences -- specifically that they implement __len__.  But
> how is such a function going to work for a two-dimensional Java table
> (accessed via Jython)?  PEP 276 is more general.  And doesn't preclude such

Ah, I remember you making this point before.  I'm not familiar with Java
(I shun the C-family like the plague:) so I've to take your word for that.
When true (and I don't mean to imply I doubt your word on it) then it's
a valid argument in favour, I guess.


>> But I do think that dismissing our point as a matter of
>> preference misses our point.

> The PEP says this:

>     - Some feel that iterating over the sequence "0, 1, 2, ..., n-1"
>       for an integer n is not intuitive.  "for i in 5:" is considered
>       (by some) to be "non-obvious", for example.

> How does that miss your point?  What should it say?

You could mention that some view the `for x in y' construct to imply
that y is some kind of sequence and have problems seeing a number
turned into a sequence just because a sequence is expected there.
That's why we think it non-obvious and not intuitive.

[From the PEP]
      Response: This seems to be largely a matter of preference.
      Some like the proposed idiom and see it as simple and
      elegant.  Some are neutral on this issue.  Others, as noted,
      dislike it.
 
But it's what came after it, the `preference' thing that made me react
in the first place.  I don't perceive it being a mere prefence, but as
a fundamental different view of what integers are and what the for
construct is about.  And being over-sensitive, you ditching the
opposition as simply being a matter of taste and preference hurted.


Having rethought the whole thing, I'm not sure what my final verdict
is.  Integers are objects, and in concordance to objects in general,
know to do `integer' things.  They know how to add, multiply, divide
and ...  count.  The integer 10 knows how to count from 0 to 10.  Like
a `dict' knows to iterate over its keys.  And that's precisely what is
requested in the `for' construct.

On the other hand, people are not used to think of integers being
capable of doing their own adding and counting.  And when this was
prominently visible in a language it could alienated them from it.

I'm actually interested in studies from smalltalk usage telling
how easy or problematic it was for its users to come to terms
with sending messages to integers to create a loop.  Maybe it's
a non-problem in general, only felt by us programmers raised
prior to the OO flood.



Just in case I switch position:) let my propose an enhancement to your
proposal.  Why not be able to count down?  You specify that the
integer to iterate over should be possitive, why not allow for
negative values and do the sensible thing, like:

   >>> [i for i in -3]
   [-1, -2, -3]
   >>> s = "spam"
   >>> "".join([s[i] for i in -s.len()])
   'maps'

I feel this would enhance the usability of the idiom as it would cover
two frequent usages of iterating over a sequence: up and down.  And
especially for the down variant, the proper `range' incantation is bud
ugly.

   range(-1, s.len() - 1, -1)

yack.
-- 
groetjes, carel



More information about the Python-list mailing list