Python 1.6 alpha 1 released

[Bjorn Pettersen]

Fredrik Lundh wrote:
> 
> Bjorn Pettersen <bjorn at roguewave.com> wrote:
> > Your definition of broken seems very peculiar.  Correct me if I'm wrong,
> > but it seems to go something like:
> 
> I've explained all this to you already.  lousy newsfeed? :-)

you keep repeating yourself, but you're certainly not explaining... not
having a good stance to argue from?

> >   - you don't know if examples are binding documentation

I take it this is still an unknown?  It's a pretty easy question.  When
example code in the documentation works as advertised, should people be
able to rely on it?  You can repeat that examples have been broken in
the past as much as you want, that's not what I'm asking about.

> >   - pair in the description of connect _must_ mean tuple
> >     and _not_ a pair of arguments because ???
> 
> I've explained that in another post -- the library reference use
> a special syntax for optional arguments.  the description of the
> connect method doesn't use that syntax.  other method
> descriptions do (this includes descriptions on the same page).
> 
> besides, "pair" is used quite extensively in the library reference,
> usually with exactly the same meaning as here: a 2-tuple.  see,
> for example, the description of "socket.error", "accept", and
> "recvfrom".

Apparently it is only used extensively enough that a large segment of
the Python community still thought the example was perfectly valid.

> >     (I would have thought it would have said tuple if it meant
> >     tuple -- tuples being Python concept as opposed to pairs)
> 
> I've explained that in another post -- it tells you that the
> address format is (host, port) -- which is perfectly valid tuple
> syntax.

...in context it can also be viewed as a perfectly valid parenthentical
note telling the reader what each of the two arguments to connect are --
especially since the "host, port" part is in italics and the parens
aren't.

> but alright, let's change "pair" to "2-tuple" everywhere.  will
> fixing this make you accept the change?

That would be clear, but it wouldn't change the fact that this change
involves changing a documented API. (And please argue why the example is
not documentation instead of repeating "the example is wrong, it
conflicts with the documentation", a perfectly reasonable reading of the
documentation, both description and example, gives you a two-argument
connect.

> >   - the example in question is broken because, even though
> >     it works, and seems to follow the description from the
> >     previous page, ...
> 
> I've explained that in another post -- it worked because the
> connect implementation didn't handle its argument properly,
> not because it was designed that way.  it stopped working
> when Guido fixed the argument handling bug.

that is purely an implementation detail. Any reasonable reader would
assume it worked because the implementation followed the documented
interface.

> and yes, this is exactly the same reason why append, insert,
> etc. did work in 1.5.2, and why they don't work in 1.6.
> yet, you think there is a difference.

That's also an implementation detail, but it's not documented. _That_ is
what the difference is.

> >   - ... other examples have been broken in the past...
> 
> I've explained that in another post -- broken examples are
> obviously not formally binding.  You replied that broken
> examples should be fixed.  Of course it should.  So should
> all broken demo code and the broken examples, just like
> all code that uses "append" etc must be fixed.

I haven't heard anyone argue that non-working examples should be
binding, but you seem to argue that working examples shouldn't be
binding either.  It's a perfectly valid opinion, and it is a stance that
other official programming language documentation has taken, I just
don't think it would be a good idea for Python -- and besides you, I
haven't heard anyone else argue that it would be.

[...]
> > The good news is that Guido realized how much code this would break, and
> > will fix the code.
> 
> yeah, and he'll probably break it again in 1.7.

I'm sorry you hold Guido in such low regard.  Waffling back and forth is
not a Guido characteristic as far as I can tell.

> just like he'll break append and a few other things in 1.6,
> and just like he broke stuff in 1.5.  and in 1.4.  etc.
> 
> you can keep on arguing until the end of c.l.py, but there's
> nothing special about "connect".  except, maybe, that you
> *know* that you're affected by this change, and you think
> you're not affected by any of the others.
> 
> if so, that's not only a very egocentric view, it's also rather
> naive.

So, I have to read your posts but not vice versa?  (I guess I'm in good
company with my egocentric views...)

> (no, don't reply.  just read my other posts in this thread. or
> if you think I don't have a clue, don't.  I don't really care)

You're sure arguing hard for a person who doesn't care. (and regressing
to schoolyard argumenting tactics certainly indicates that this thread
has lost any usefulness it may have had... not that I'm not expecting
you to come back with a 'last word' though <wink>)

> </F>

-b