>>>> Looking into the library, I see many accessor
>>>> functions starting with either get_ or get; however, I don't
>>>> recall why that could have been relevant for socket objects.
>>> If you think that should be changed to attributes, we should
>>> do that.
>> Accessor functions are typical for APIs translated too literally from
>> Java. (threading.py being an example :-( )
>> I'd like to change this as long as we're doing greenfield API design.
> Does that mean to change it to attributes?
> (since I'm no professional BDFL channeler I could have misread your
> sentence ;)
Yup, that's what it means. In addition, the "greenfield" part meant
specifically they should be changed to read-only attributes.
One trick to professional channeling is to do the Pythonic thing, and
then just pretend you read Guido's mind. Of course I'm _way_ beyond
I see increased activity related to Python 3000. This is great, but
there is some danger involved. Some of the dangers are: overloading
developers; setting unrealistic expectations for what can be
accomplished; scaring the more conservative user community; paralyzing
developers who can't decide whether to wait for Python 3000 or not.
I'd like to address all these issues, but it may be better to first
spend some time on creating a more streamlined process. Perhaps it's
finally time to introduce a separate mailing list? If people agree,
let's call it python-3000(a)python.org. For many developers this won't
make much of a difference (since they'll subscribe to both lists), but
it will give people who are only concerned with Python 2.x a way to
opt-out, and perhaps more importantly, it will make it clear whether
any particular proposal is intended for Python 3000 or for Python 2.x.
I don't want to encourage people who are only interested in Python
3000 to opt-out from the 2.5 python-dev list, since Python 3000 is not
being developed in a vacuum. It must be "a better Python" and that
means it is informed to a large extent by recurring issues on
python-dev (and c.l.py!).
The mailing list is only a small part of the new strategy. We need to
start deciding on important meta-issues like:
- What's the timeline? I don't expect to be setting a schedule now and
sticking to it for the next five years. But we owe everybody out there
who is watching some clarity about when Python 3000 can be expected,
and how we plan to get there; there are widely differing estimates of
how long it will take, and I don't want to scare users away or cause
developers to hold their breath waiting for it (some of which I
imagine is happening with Perl 6).
- What's the upgrade path? Do we provide a conversion tool, or a
compatibility mode, or both, or what? Will it be at all possible to
write code that runs in Python 2.x (for large enough values of x) as
well as in 3.0? This also touches upon the issue of parallel releases
of Python 2.x and 3.x. My personal expectation (contrary to what MvL
said recently) is that there will be several 2.x releases issued even
after 3.0 is out; possibly 3.0 and 2.6 may coexist, and 2.7-2.9 may
continue to evolve 2.x while 3.x is maturing. I've seen this used
successfully in Perl (with 4->5) and Apache, and closer to home in
Zope. Again, this is important in the light of how the transition is
perceived in the world outside python-dev.
- Will we do a grand library reform at the same time? Personally I see
that as quite a separate issue; apart from some specific things like
the stdio redesign, we could start the library reform in 2.6, or
post-3.0, depending on how much energy there it.
- What's the implementation strategy? I've started a branch where I
plan to do some weeding out; but I've already found that the large
amount of legacy code makes the weeding difficult. I may yet decide to
switch to a sandbox model where only new code or carefully modernized
old code is added (this is how Zope 3 was developed).
- What's the procedure for proposing and new features? It may be time
to start a new series of PEPs that focus exclusively on Python 3000.
I'd like to reserve the numbers 3000-3099 for meta-PEPs (e.g.
addressing the above questions) and 3100-3999 for feature PEPs.
Please don't respond with answers to these questions -- each of them
is worth several threads. Instead, ponder them, and respond with a +1
or -1 on the creation of the python-3000 mailing list. We'll start
discussing the issues there -- or here, if the general sense is not to
split the list.
--Guido van Rossum (home page: http://www.python.org/~guido/)
> I still believe in this, and I'm thankful for the support I've seen. It
> won't happen for Python 2.x, but I do plan on addressing this for Py3K.
When you do, I'd like you to consider one change to the names. You are
> +- KeyboardInterrupt
> +- GeneratorExit
> +- SystemExit
> +- StopIteration
> +- Error
> | +- ImportError
> | +- (etc.)
If we use that structure, I still strongly feel that what you call "Error"
ought to be named "Exception" (and what you call "Exception" should be
named "BaseException" or perhaps "Raisable"). The reason is this:
Most people coming to Python today are coming from languages more modern
than Fortran and C, and (if they have any programming background at all)
they are familiar with the idea of an exception. When chatting around the
water cooler, they probably call it "an exception", rather than "a dingus",
"one of those thingys that unwinds the stack until reaching a handler",
or even "an error". (The term "an error" is usually used around the
water cooler for any kind of mistake, whether human or programatic.) This
is encouraged in Python by the fact that the keyword for handling
exceptions in Python is "except".
But we don't want people using the dingus at the top of the hierarchy --
only a few experts who know what they're doing should care about that
one. We want them using the one that you call "Error". So by naming
that one "Exception", we take advantage of the meaning of the word, the
experience from other languages, and the keywords of the language to
encourage correct usage. Naming the top level dingus something slightly
odd is a small price to pay (although both "BaseException" and "Raisable"
seem instantly comprehensible to me).
I present Java as an example. Given it's position as the new Cobol, there
are literally hundreds of thousands of not-very-skillful Java programmers
out there. Yet it is rare to see them write "catch Throwable" when they
should use "catch Exception". That mistake is far more common among
beginning Python users. Surely we can do at least as well as Java!
-- Michael Chermside
PS: I've intentionally ignored the question Guido raised about whether
Warning belongs under your "Error" or your "Exception".
> x86_64 is multiarch. That means, we allow both
> i386 and x86_64 binaries to coexits. Is the proposal
> that python should not support this? That would
> be unfortunate.
The problem is that at the moment, a package
has to live all in one place. This doesn't mean
you can't have both types of binaries for python
as a whole. (Though whether you can run them
in the same process is another issue.) It does
mean that you can't have them in the same
This is already awkward for packages split
between python and extension modules.
As a workaround, you can add a .pth file;
eggs and namespace packages may improve
the situation some more.
(Regarding changes caused by ssize_t0
Martin v. Löwis wrote:
> It is possible to look at the changed APIs, see
I think the problem is more with APIs that are not part of the
sequence page. For instance, in
M.-A. Lemburg mentioned
PyObject *mp, Py_ssize_t *pos, PyObject **key, PyObject **value);
PyDict_Next isn't on the sequence page, but if you call it, it could
write a Py_ssize_t into pos, even though your pointer is only
large enough for an int.
To do things correctly, you really have to change your call to the
new version (and add the #ifdef)
#if PY_VERSION_HEX < 0x02050000
typedef int Py_ssize_t;
You can downcast if you aren't ready to support 64-bits, but ... setting
up a possible buffer overflow is a bit worse than simply not supporting.
> Hrrm, test_thread_state hands an object pointer off to a different thread
> without INCREF'ing it first. Could there be a race condition with the
> deallocation of arguments at the end of test_thread_state?
> Specifically, that trace looks to me like the spawned thread is trying to call
> the function passed in while the main thread is trying to delete the argument
> tuple passed to test_thread_state.
Good eye! I haven't been able to _provoke_ that failure on Windows
yet, but it sure looks promising. Compounding the problem is that the
thread tests in test_capi.py are set up incorrectly: due to "hidden"
fighting over Python's import lock, the second TestThreadState here
(the one run in the new thread) can't really start before test_capi.py
(when run via regrtest.py) finishes:
t=threading.Thread(target=TestThreadState) THIS ONE
The dramatic <wink> way to show that is to add "t.join()".
test_capi.py deadlocks then (not a problem with t.join(), the problem
is that TestThreadState is hung trying to do its imports, which it
can't do before regrtest.py's import of test_capi.py completes,
because of the hidden import lock; so the thread never makes progress,
and t.join() waits forever). I can fix that easily (and will), but I
want to provoke "a problem" on my box first.
The consequence is that the instance of TestThreadState run in the
thread ends up running in parallel with later tests run by
regrtest.py. Therefore it's not surprising to see a segfault due to
test_thread_state occur a few tests after regrtest.py believes
test_capi has completed.
Later: by adding strategic little counters and conditional sleeps all
over the place in the C code, I was able to reproduce a segfault on
Windows. I'm not yet sure how to fix it (repairing the structure of
test_capi.py would make it more likely that the segfault would occur
closer to the time test_capi runs, but the segfault actually occurs in
a non-threading.py thread spawned by the _C_ test code, and there's
nothing we can do in test_capi.py to wait for that thread to finish).