The Buildbot has detected a new failure of x86 gentoo trunk.
Full details are available at:
http://www.python.org/dev/buildbot/all/x86%20gentoo%20trunk/builds/109
Buildbot URL: http://www.python.org/dev/buildbot/all/
Build Reason:
Build Source Stamp: [branch trunk] HEAD
Blamelist: neal.norwitz
The Buildbot has detected a new failure of amd64 gentoo trunk.
Full details are available at:
http://www.python.org/dev/buildbot/all/amd64%20gentoo%20trunk/builds/108
Buildbot URL: http://www.python.org/dev/buildbot/all/
Build Reason:
Build Source Stamp: [branch trunk] HEAD
Blamelist: tim.peter
[Me]
> There is a semantic difference between
> code like s+=t and s.update(t). The former only works when t is a set
> and the latter works for any iterable. When the C code corresponds to
> the Python code, that knowledge is kept intact and there is no confusion
> between
> PyNumber_InPlaceAd
[Barry]
> Is it your intent to push for more use of the abstract API instead of
> the concrete APIs for all of Python's C data structures? Current API
> aside, are you advocating this approach for all new built-in types?
> Would you argue that Python 3.0's C API be stripped of everything but
> the
Is it your intent to push for more use of the abstract API instead of
the concrete APIs for all of Python's C data structures? Current API
aside, are you advocating this approach for all new built-in types?
Would you argue that Python 3.0's C API be stripped of everything but
the abstract API and
The Buildbot has detected a new failure of amd64 gentoo trunk.
Full details are available at:
http://www.python.org/dev/buildbot/all/amd64%20gentoo%20trunk/builds/105
Buildbot URL: http://www.python.org/dev/buildbot/all/
Build Reason:
Build Source Stamp: [branch trunk] HEAD
Blamelist: barry.war
I believe I've figured out the magic to split checkin messages so that
python/branches/p3yk goes to python-3000-checkins and everything else
goes to python-checkins. Let me know if you notice any problems, and
feel free to subscribe to whichever list(s) you're interested in.
-Barry
signature.a
Andrew MacIntyre wrote:
> Jim Jewett wrote:
>
>> Is OS2 still actively supported?
>
> If you mean, is Python still actively supported on OS/2, then the answer
> is yes.
Just to clarify, I haven't been actively monitoring other changes for
impact on the OS/2 port for the last few months (too much
Jim Jewett wrote:
> Is OS2 still actively supported?
If you mean, is Python still actively supported on OS/2, then the answer
is yes.
-
Andrew I MacIntyre "These thoughts are mine alone..."
E-mail: [EMAIL
Fredrik Lundh wrote:
>> - Usage of the "old" function pointer type name (e.g. intobjargproc)
>>likely also indicates an error, since many of these pointers have
>>changed there types. I believe the only exception for this is inquiry,
>>which still has legit uses, in nb_nonzero, tp_clear
The Buildbot has detected a new failure of g4 osx.4 trunk.
Full details are available at:
http://www.python.org/dev/buildbot/all/g4%20osx.4%20trunk/builds/94
Buildbot URL: http://www.python.org/dev/buildbot/all/
Build Reason:
Build Source Stamp: [branch trunk] HEAD
Blamelist: georg.brandl
Buil
Jeremy Hylton wrote:
> It sounds more like the PEP should list these three categories and
> tell developers that they need to inspect their code for instances of
> them and fix them in the appropriate way. Perhaps with an example of
> each.
+1; I will do that.
Regards,
Martin
___
The Buildbot has detected a new failure of x86 XP-2 trunk.
Full details are available at:
http://www.python.org/dev/buildbot/all/x86%20XP-2%20trunk/builds/84
Buildbot URL: http://www.python.org/dev/buildbot/all/
Build Reason: The web-page 'force build' button was pressed by 'Tim': lost
connecti
The Buildbot has detected a new failure of x86 XP-2 trunk.
Full details are available at:
http://www.python.org/dev/buildbot/all/x86%20XP-2%20trunk/builds/83
Buildbot URL: http://www.python.org/dev/buildbot/all/
Build Reason:
Build Source Stamp: [branch trunk] HEAD
Blamelist: barry.warsaw
Buil
Tim Peters wrote:
> [Guido]
>>> 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.
>
> [Georg Brandl]
>> Does that mean to change it to attributes?
>> (s
On 3/21/06, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
> Don't you think developers are capable enough to judge for
> themselves ?
>
> They might also want to change their extensions to make use
> of the new possibilities, so a list of APIs taking Py_ssize_t
> parameters on input would be handy to ch
Martin v. Löwis wrote:
> There are two improvements you could make:
> - Some of the functions in the first list return Py_ssize_t; calling
>them can cause truncation if the result value is larger than INT_MAX
>(and it is assigned to an int). To find those functions, do
>grep 'PyAPI_FUN
[attribution lost]
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.
[attribution lost]
>>> If you think that should be changed to attributes, we should
>>> do that.
M.-A. Lemburg wrote:
> Perhaps we should have three lists:
>
> 1. Py_ssize_t output parameters (these need changes)
> 2. Py_ssize_t return values (these need overflow checks)
> 3. Py_ssize_t input parameters (these can be used to enhance
>the extension)
>
> Here's the list for 2 (I already pro
"M.-A. Lemburg" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>Perhaps we should have three lists:
>1. Py_ssize_t output parameters (these need changes)
>2. Py_ssize_t return values (these need overflow checks)
>3. Py_ssize_t input parameters (these can be used to enhance
the ex
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>> Interesting: A few mails ago you suggested that developers
>> do exactly what I did to get the list of changes. Now you
>> gripe about the output format of the grep.
>
> Developers which use grep can read the output of grep. Developers
> which use o
Fredrik Lundh wrote:
> M.-A. Lemburg wrote:
>
>> Here's a grep of all the changed/new APIs, please include it
>> in the PEP.
>
> I've posted a simple-minded source scanner here:
>
> http://svn.effbot.python-hosting.com/stuff/sandbox/python/ssizecheck.py
Very nice. Thanks !
--
Marc-Andre Lembu
M.-A. Lemburg wrote:
> Interesting: A few mails ago you suggested that developers
> do exactly what I did to get the list of changes. Now you
> gripe about the output format of the grep.
Developers which use grep can read the output of grep. Developers
which use other methods of searching (e.g. Vi
Fredrik Lundh wrote:
> I've posted a simple-minded source scanner here:
>
> http://svn.effbot.python-hosting.com/stuff/sandbox/python/ssizecheck.py
Great job! I've added a link to that to the PEP.
There are two improvements you could make:
- Some of the functions in the first list return Py_ssiz
Martin v. Löwis wrote:
> M.-A. Lemburg wrote:
>> Here's a grep of all the changed/new APIs, please include it
>> in the PEP.
>
> You want me to include that *literally*? Are you serious?
Feel free to format it in a different way.
> Please go ahead and commit that change yourself: I consider
> it
The Buildbot has detected a new failure of amd64 gentoo trunk.
Full details are available at:
http://www.python.org/dev/buildbot/all/amd64%20gentoo%20trunk/builds/100
Buildbot URL: http://www.python.org/dev/buildbot/all/
Build Reason:
Build Source Stamp: [branch trunk] HEAD
Blamelist: martin.v.
On Mon, 2006-03-20 at 20:06 -0800, Guido van Rossum wrote:
> There's also a list for Python-3000-related checkins. Don't subscribe
> to that one yet, it's very boring and uninteresting. Also, Barry
> hasn't done the svn magic yet. :-)
We're having a small problem on the svn box which requires Tho
M.-A. Lemburg wrote:
> Here's a grep of all the changed/new APIs, please include it
> in the PEP.
You want me to include that *literally*? Are you serious?
Please go ahead and commit that change yourself: I consider
it completely unreadable and entirely worthless.
Regards,
Martin
M.-A. Lemburg wrote:
> Here's a grep of all the changed/new APIs, please include it
> in the PEP.
I've posted a simple-minded source scanner here:
http://svn.effbot.python-hosting.com/stuff/sandbox/python/ssizecheck.py
___
Python-Dev mailing list
Martin v. Löwis wrote:
> 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.
With due respect for other developers, yes.
> I don't b
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> Michael Hudson wrote:
>
>> > The ssize_t patch is the single most disruptive patch in
>> > Python 2.5, so it deserves special attention.
>>
>> From your POV, maybe: from mine, it's definitely the new compiler.
>
> in what way does the new compiler affe
Michael Hudson wrote:
> > The ssize_t patch is the single most disruptive patch in
> > Python 2.5, so it deserves special attention.
>
> From your POV, maybe: from mine, it's definitely the new compiler.
in what way does the new compiler affect third-party developers ?
__
"M.-A. Lemburg" <[EMAIL PROTECTED]> writes:
> The ssize_t patch is the single most disruptive patch in
> Python 2.5, so it deserves special attention.
>From your POV, maybe: from mine, it's definitely the new compiler.
Cheers,
mwh
--
I reject that approach. It has a suspicious lack
The Buildbot has detected a new failure of x86 gentoo trunk.
Full details are available at:
http://www.python.org/dev/buildbot/all/x86%20gentoo%20trunk/builds/97
Buildbot URL: http://www.python.org/dev/buildbot/all/
Build Reason:
Build Source Stamp: [branch trunk] HEAD
Blamelist: georg.brandl
Michael Chermside <[EMAIL PROTECTED]> wrote:
>
> 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
> pro
35 matches
Mail list logo
