Python 1.6 alpha 1 released

[Fredrik Lundh]

Bjorn Pettersen <bpetterson at uswest.net> wrote:
> > in earlier releases of the library reference, some examples
> > didn't even work.  you still think they're formally binding?
>
> Are you saying none of the examples are binding, formally or otherwise?

I have no idea -- I'm just pointing out that the library reference
has contained broken examples.  the problems I've reported have
all been fixed, but I haven't looked at all example...

> (Even in the C++ standard where examples are _explicitly_ not normative,
> they're usually fixed if conflicting with normative text.)

oh, I'm sure this will be fixed in the 1.6 documentation, in one way
or another.  currently, the example do conflict with the "normative"
text -- the method description talks about one argument:

    connect(address)

the address field is defined (in an earlier section) as either a string
or a (host, port) pair, depending on the protocol.

now, "pair" isn't formally defined ("tuple" would have been clearer),
but if you look at methods that are designed to take optional args,
you'll find that the library reference always spells that out.  as an
example, look at getsockopt a bit further down the page:

    getsockopt(level, optname[, buflen])

so in other words, either this change remains, and the example
should be fixed.  or someone adds backwards compatibility to the
socket module, in which case the method description should be
fixed:

    connect(address[, port])

/.../ If a port number is present, the first argument should be a
string containing the host name.  This is equivalent... /.../

> Your other arguments for a patch are good, but seems to reinforce the
feeling
> that changing this behavior was ill though out in the first place.

does it?  I didn't come to that conclusion for "connect" (still not
sure about "append", but that's another story).

and more importantly, I'm pretty sure the powers that be went
through the same list, decided that this is a real bug, and that
it would be far cheaper to fix this now, than at a time when
Python has twice as many users (and implementations...).

so what did we miss?

> (and remember that not all companies have enough Python expertise that a
> traceback leads to a fix ten minutes later)

well, if this is a mission critical system, you should use a staging
server, right?

if breaking the scripts would just cause a minor annoyance, most
organizations I've worked with can deal with a release note con-
taining something like:

    "if you stumble upon problems, let us know, and we'll
    fix it as soon as possible.  if you really need the old
    version, just type 'python1.5' instead of 'python'"

or you can do it the other way around:

    "we've installed a new version of the core environment.
    you can help us test this out by typing 'python1.6' instead
    of 'python'.  if we don't hear anything by the end of next
    week, we'll change the default environment"

if you don't expose the interpreter to the users, you can
rename the scripts ("just append -old"), provide an alternate
setup file, or whatever.  nothing new here.

</F>