> 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
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 ar
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 reform
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 be
[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
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 ra
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 everyo
Barry Warsaw wrote:
> One quibble. Since the term used for the general concept of something
> that is raised and caught is "exception" and since all the raise-able
> objects live in a module called "exceptions", it is confusing that
> "except Exception" will not catch all exceptions.
My thoughts
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 func
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 |
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
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 to
[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 .
With the next 2.4 release candidate imminent, rem
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
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 v
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 Py_ss
(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
http://mail.python.org/pipermail/pyth
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
>
(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
ev
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
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:
http://mail.python.org/mailman/options/python-dev/archiv
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 deman
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.
>
>
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
De
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 ;
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
> +- Generat
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
[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 th
"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.
Terry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org
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: fail
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: f
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 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 compi
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 compile
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 Exce
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 o
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. Ideall
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 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 13:49 +1200, Greg Ewing wrote:
> Barry Warsaw wrote:
>
> > Exception
> > +- KeyboardInterrupt
> > +- GeneratorExit
> > +- SystemExit
> > +- StopIteration
> > +- Error
> > | +- ImportError
> > | +- (etc.)
> > |
> > +- Warning
> >+- UserWarning
> >+- (etc.)
>
> +42!
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
>
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 no
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 o
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 3
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,
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 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 concerne
> 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 li
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
>>>
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
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 any
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 pr
[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]
>> 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(
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'
55 matches
Mail list logo
