On 3/19/06, Christian Tismer [EMAIL PROTECTED] wrote:
Guido van Rossum wrote:
...
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
[Raymond]
What are you proposing to add to the PySet API?
[Barry]
PySet_Clear(), PySet_Next(), PySet_Update(), and PySet_AsList().
PySet_Clear()
-
Use PyObject_CallMethod(s, clear, NULL).
Or if you need to save a millisecond on an O(n) operation, use
PyNumber_InPlaceSubtract(s,s)
[Guido]
Sigh. Enough already. PEP 352 was chosen to minimize incompatibilities
and maximize gain with minimal changes in the tree. Also note that
Warnings can sometimes be raised and should then treated as errors, so
Warning would have to inherit from Error.
I vote for the status quo in
Raymond Hettinger wrote:
While Guido is thinking, could one of the proponents please enumerate the
reasons for treating GeneratorExit like KeyboardInterrupt and SystemExit.
To me, they obviously should be under Exception, and not treated like
KeyboardInterrupt or SystemExit, so that
I'd like to freeze the release24-maint branch for 2.4.3c1 this
Thursday 23rd March from UTC. I'll post a note once that's done,
but as usual, please please only check in critical fixes in the week
between 2.4.3c1 and 2.4.3 (which will follow next week).
Please let me know if you have
Guido van Rossum wrote:
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
Neal Norwitz wrote:
On 3/19/06, Tim Peters [EMAIL PROTECTED] wrote:
If anyone sees spurious failures with the buildbot (one time failures,
crashes, etc), please report the problems to python-dev. It would be
great to see if you can reproduce the results with the same tests that
failed. We
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.
On 20/03/06, Nick Coghlan [EMAIL PROTECTED] wrote:
+1 on the separate mailing list (and PEP numbers).If Barry (or another mailing list admin) is feeling energetic, somebranch-specific topics on python-checkins would be nice, too. While I'minterested in tracking trunk checkins, I'm not so concerned
Skip There seem to be other places where Python is beginning to require
Skip parens even though they aren't strictly necessary to resolve
Skip syntactic ambiguity.
Guido In the style guide only, I hope.
Alex Technically, I believe the first place where this did not apply
On 3/20/06, Guido van Rossum [EMAIL PROTECTED] wrote:
Please don't respond with answers to these questions -- each of themis worth several threads. Instead, ponder them, and respond with a +1or -1 on the creation of the python-3000 mailing list. We'll startdiscussing the issues there -- or here,
Hello,
it's time for the 7th Python Bug Day. The aim of the bug day is to close
as many bugs, patches and feature requests as possible, this time with a
special focus on new features that can still go into the upcoming 2.5 alpha
release.
When?
^
The bug day will take place on Friday, March
On Mon, 2006-03-20 at 19:27 +1000, Nick Coghlan wrote:
+1 on the separate mailing list (and PEP numbers).
I'm neutral on whether a new mailing list should be added, but +1 on
separate PEP numbers.
If Barry (or another mailing list admin) is feeling energetic, some
branch-specific topics on
On Sun, 2006-03-19 at 20:40 -0800, Guido van Rossum wrote:
I'm -0 for changing this in 3.0; a larger-scale reorganization could
be undertaken but it's not a big priority.
Before you spend more energy on this, I'd like to address the process
for Python 3000, which is too chaotic right now.
On Sat, 2006-03-18 at 15:37 -0800, Brett Cannon wrote:
Actually, this prompts me to write about an issue I have with PEP 352.
I actually don't think it's necessary (yes, I know it's already in the
tree).
Much to personal pain and sprint time. Are you trying to make me shed
a manly
On Sun, 2006-03-19 at 13:49 +1200, Greg Ewing wrote:
Barry Warsaw wrote:
Exception
+- KeyboardInterrupt
+- GeneratorExit
+- SystemExit
+- StopIteration
+- Error
| +- ImportError
| +- (etc.)
|
+- Warning
+- UserWarning
+- (etc.)
+42! This is beautifully clear
On 3/20/06, BJörn Lindqvist [EMAIL PROTECTED] wrote:
-0 on separate mailing list and PEP numbers.
You seem to be the minority so far...
Because to much separation between python 2.x and python 3.x makes 3.x
seem more like vaporware that will never happen (Perl 6).
I'm actually trying to
On Sun, 2006-03-19 at 17:31 +1000, Nick Coghlan wrote:
With PEP 352 (tweaked to move GeneratorExit out from under Exception):
- except: continues to mean catch everything
- except Exception: now does the right thing
- inheriting from Exception continues to be correct for user
On Sun, 2006-03-19 at 19:18 -0800, Guido van Rossum wrote:
I have a problem with using Error as the focal point since so many
exceptions (user-defined or otherwise) aren't errors.
I'm not sure that's totally true in practice. I think most user-defined
exceptions are actually errors.
On Sun, Mar 19, 2006, Greg Ewing wrote:
Barry Warsaw wrote:
One possible approach is to revert BaseException out of Py2.5,
re-position KeyboardInterrupt, and add Error as an alias for
StandardError. Then we can encourage people to start using Error as the
base classes for their own errors.
On Mon, 2006-03-20 at 08:18 -0800, Aahz wrote:
-1 -- I occasionally use exceptions as a multi-loop break. That's a
perfectly valid Python practice, those exceptions should inherit from
Exception, and there should not be any warnings raised.
Exactly! But they're not errors, so except
The Buildbot has detected a new failure of x86 W2k trunk.
Full details are available at:
http://www.python.org:9010/x86%20W2k%20trunk/builds/83
Buildbot URL: http://www.python.org:9010/
Build Reason:
Build Source Stamp: [branch trunk] HEAD
Blamelist: anthony.baxter
BUILD FAILED: failed
The Buildbot has detected a new failure of x86 XP-2 trunk.
Full details are available at:
http://www.python.org:9010/x86%20XP-2%20trunk/builds/69
Buildbot URL: http://www.python.org:9010/
Build Reason:
Build Source Stamp: [branch trunk] HEAD
Blamelist: anthony.baxter
BUILD FAILED: failed
The Buildbot has detected a new failure of x86 XP-2 trunk.
Full details are available at:
http://www.python.org:9010/x86%20XP-2%20trunk/builds/71
Buildbot URL: http://www.python.org:9010/
Build Reason:
Build Source Stamp: [branch trunk] HEAD
Blamelist: anthony.baxter,neal.norwitz
BUILD
The Buildbot has detected a new failure of x86 W2k trunk.
Full details are available at:
http://www.python.org:9010/x86%20W2k%20trunk/builds/85
Buildbot URL: http://www.python.org:9010/
Build Reason:
Build Source Stamp: [branch trunk] HEAD
Blamelist: anthony.baxter,neal.norwitz
BUILD FAILED:
The Buildbot has detected a new failure of x86 XP 2.4.
Full details are available at:
http://www.python.org:9010/x86%20XP%202.4/builds/20
Buildbot URL: http://www.python.org:9010/
Build Reason:
Build Source Stamp: [branch branches/release24-maint] HEAD
Blamelist: vinay.sajip
BUILD FAILED:
[EMAIL PROTECTED] wrote:
Skip There seem to be other places where Python is beginning to require
Skip parens even though they aren't strictly necessary to resolve
Skip syntactic ambiguity.
Guido In the style guide only, I hope.
Alex Technically, I believe the first
Martin v. Löwis wrote:
Fernando Perez wrote:
So I think M.A. is right on the money here with his statement. Unless you
consider the Linux/64bit camp insignificant. But if that is the case, it
might be worth putting a big statement in the 2.5 release notes indicating
there is a good chance,
Barry writes:
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
proposing this:
Exception
+- KeyboardInterrupt
+-
On Mon, 2006-03-20 at 11:43 -0800, Michael Chermside wrote:
When you do, I'd like you to consider one change to the names. You are
proposing this:
I'll keep this in mind, but won't comment further here for two reasons.
I want to think about it some more (you throw, er raise some good
points ;)
On Mon, 2006-03-20 at 13:30 -0500, Terry Reedy wrote:
Guido van Rossum [EMAIL PROTECTED] wrote in message
Barry, if you could create that mailing list, please?
And please mirror it on gmane the same way as this list is.
Subscription requests have been made.
-Barry
signature.asc
On 3/20/06, Barry Warsaw [EMAIL PROTECTED] wrote:
On Mon, 2006-03-20 at 13:30 -0500, Terry Reedy wrote:
Guido van Rossum [EMAIL PROTECTED] wrote in message
Barry, if you could create that mailing list, please?
And please mirror it on gmane the same way as this list is.
Subscription
M.-A. Lemburg wrote:
I really don't understand why you put so much effort into
trying to argue that the ssize_t patch isn't going to break
extensions or that fixing compiler warnings is good enough.
Well, in *this* thread, my main point is that I don't want
to provide the list that you demand,
Is there a list of currently supported platforms?
Is OS2 still actively supported?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Jim Jewett wrote:
Is there a list of currently supported platforms?
No, only a negative list: PEP 11.
Is OS2 still actively supported?
It's not listed as unsupported. Whether it actually works, nobody
knows.
Regards,
Martin
___
Python-Dev mailing
(Sorry about the early send)
Is there a list of currently supported platforms?
Is OS2 still actively supported?
The reason I ask is that PYOS_OS2
(in Modules/posixmodule.c and Include/pyport.h)
triggers enough ifdeffery that I'm certain it missed
out on some updates, and I'm not certain it is
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
I really don't understand why you put so much effort into
trying to argue that the ssize_t patch isn't going to break
extensions or that fixing compiler warnings is good enough.
Well, in *this* thread, my main point is that I don't want
to
(Regarding changes caused by ssize_t0
Martin v. Löwis wrote:
It is possible to look at the changed APIs, see
http://docs.python.org/dev/api/sequence.html
I think the problem is more with APIs that are not part of the
sequence page. For instance, in
M.-A. Lemburg wrote:
It's not a waste of time at all: you'd be helping lots and
lots of developers out there who want to fix their extensions.
This is free software, anybody is free to decide what they do.
I don't believe that developers would be helped a lot - they
can easily search for
The Buildbot has detected a new failure of sparc solaris10 gcc trunk.
Full details are available at:
http://www.python.org/dev/buildbot/sparc%20solaris10%20gcc%20trunk/builds/85
Buildbot URL: http://www.python.org/dev/buildbot/
Build Reason: The web-page 'rebuild' button was pressed by 'Martin
Jim Jewett wrote:
It is possible to look at the changed APIs, see
http://docs.python.org/dev/api/sequence.html
I think the problem is more with APIs that are not part of the
sequence page. For instance, in
http://mail.python.org/pipermail/python-dev/2006-March/062679.html
M.-A.
[Tim, last Friday]
... all 14 columns in
http://www.python.org/dev/buildbot/all/
are green. Yippee! Let's keep 'em that way. You can all take the
weekend off ;-)
But you didn't, and they haven't been all green again since then heh.
With the next 2.4 release candidate imminent,
The Buildbot has detected a new failure of x86 gentoo trunk.
Full details are available at:
http://www.python.org/dev/buildbot/x86%20gentoo%20trunk/builds/95
Buildbot URL: http://www.python.org/dev/buildbot/
Build Reason: The web-page 'force build' button was pressed by 'Tim': someone
forgot
Guido van Rossum wrote:
In the style guide only, I hope. The parens that are mandatory in a
few places *are* necessary to resolve ambiguity.
That's not entirely true. My original list comprehension
implementation didn't require parens around unpacked loop
variables -- Guido added them because
Guido van Rossum wrote:
respond with a +1
or -1 on the creation of the python-3000 mailing list.
+1
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridiam! |
Christchurch, New Zealand |
Gareth McCaughan wrote:
but wouldn't if be nice if you could say
def f((x0,y0) as p0, (x1,y1) as p1):
I'm not sure that it would. Currently you can look at
a function header and get a picture of its calling
signature, but this would clutter it up with
implementation details of the
Barry Warsaw wrote:
Ideally, StandardError would be called
Error ... Their non-error exceptions
would be derived from Exception.
Having something called StandardError suggests that
there are non-standard errors around somewhere.
Are we to have Error Police going around making
sure everyone's
Aahz wrote:
Also maybe start issuing warnings whenever you inherit directly from
Exception.
-1 -- I occasionally use exceptions as a multi-loop break. That's a
perfectly valid Python practice, those exceptions should inherit from
Exception, and there should not be any warnings raised.
[Nick Coghlan]
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
Barry Warsaw wrote:
On Mon, 2006-03-20 at 13:30 -0500, Terry Reedy wrote:
Guido van Rossum [EMAIL PROTECTED] wrote in message
Barry, if you could create that mailing list, please?
And please mirror it on gmane the same way as this list is.
Subscription requests have been made.
-Barry
The Python 3000 mailing list has been created. From now on let's have
all discussions related to Python 3000 on that list. Please subscribe
here:
http://mail.python.org/mailman/listinfo/python-3000
Let's start by attempting to answer the process questions: timeline;
upgrade path; library
On 3/20/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Jim Jewett wrote:
To do things correctly, you really have to change
your call to the new version (and add the #ifdef)
#if PY_VERSION_HEX 0x0205
typedef int Py_ssize_t;
#endif
You can downcast if you aren't ready to
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
53 matches
Mail list logo
