Python 1.6 alpha 1 released

[Fredrik Lundh]

Tres Seaver wrote:
> >not true.  the documented interface explicitly says that
> >there is one single argument.  it does not mention optional
> >arguments.
>
> Your insistence that the "documented interface" consists only of the
> description in the module reference, and not of the example on the next
> page or of the way the API is actually used in the standard libraries
> baffles me.

I thought I explained that in the next sentence:

> >(the example was broken, but so were other examples in earlier
> >releases of the documentation.  see other messages in this
> >thread for details)

> >> No Python module in the standard library uses the single-argument
> >> connect, period.
> >
> >*all* python modules in the 1.6 standard library use
> >single-argument socket connect.
>
> Invalid argument -- nobody depends on the 1.6 library yet.

umm.  if you plan to use the 1.5.2 standard library with 1.6,
you're in for some *serious* surprises...

> Here is a check from my (unfiddled) Python distro -- its the same on
Windows,
> too:

[only of few of the examples are socket.connect calls...]

> So don't tell me that the 1.5.2 library used one-argument connect().

didn't think I did.  I thought you told me that *all* connect
calls in the standard library used two arguments, but maybe
you didn't.  in either case, as you just noticed yourself, it
wasn't true.

> The append() change is hard to find, but fixes something that shouldn't
work.

why shouldn't that work?  after all, lots of sample code use that
form.  library code use that form (popular libraries like PIL, Medusa,
Zope, just to name a few).  books use that form.

and as I've said a million times, code using "append" is much harder
to fix, since "append" is 1) far more likely to be used in contexts
where a TypeError is expected, but for other reasons, and 2) often
used as a bound method in performance critical code.  the former
makes it hard to find this by running the code, the second makes
it hard to find it by grepping through the sources.

I suggest you dig up my list of "change cost" criterias, and apply
them to all non-compatible changes (possibly starting with 1.5.2's
class object change, which broke *lots* of code in really naughty
ways [1]).  I've done that, and I still think that "connect" is the
*least* critical of all code-breaking changes in the python core,
since 1.3 or so.

I still don't understand why others seem to think that this is the
most critical of them all, and nobody seem to be capable of ex-
plaining that to me.

(I guess some people will change their minds when other changes
in 1.6 causes their code to explode.  are you sure your code doesn't
use multi-argument appends, or expect str(1L) to include the L, or
expect certain operations to raise exceptions if given longs instead
of integers, etc.  and if you think you are, are you sure all non-std
libraries you depend on doesn't do that?  thought so ;-)

> In fact, I think one could make a reasonable case that the real bug here
> is in the API doc:  single-argument connect() is unintuitive for AF_INET
> sockets, and exists primarily to shoehorn orthagonality with AF_UNIX ones
> (where a default port argument would do just as well.)

if you look at the socket API a bit more carefully, you'll notice that
there are a number of functions in there which can *only* deal with
(host, port) tuples.  so in other words, it's internal API consistency
we're talking about here:  if someone returns an address, it's reason-
able to be able to pass it on to anyone expecting an address, no
matter what format the address structure happens to have.  heck,
the C socket API handles that, so why shouldn't Python do that too?

...

but who cares?  as just announced, 1.6 will support connect(host, port)
as a special case -- and it won't surprise me if it's gone again in 1.7.

until then, over and out.

</F>

1) stumbled upon one today: it turned out that by changing from 1.3
to 1.5.2, large data transfers from a high-performance server to clients
on an 10 Mbit Ethernet were unexpectedly terminated.  the same trans-
fers worked just fine with high-performance workstations, on an FDDI
network.  ten guru points to anyone who can explain why.