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
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
___
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
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
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
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
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
>
19 matches
Mail list logo
