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
proposing
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
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
--
PenguinOfDoom I reject that approach. It has a suspicious lack
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 ?
/F
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 affect third-party
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 believe
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
/F
___
Python-Dev mailing list
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
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
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
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
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.
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 other
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
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 provided
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
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 check
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?
(since I'm no
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
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
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 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
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, and
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
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
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
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:
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
[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
[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
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
31 matches
Mail list logo
