Neal Norwitz wrote:
On 1/10/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
We'd also have to make sure that old extensions don't
just import with a warning, since the change will introduce
buffer overflows and seg faults in extensions that are not
aware of the change.
I agree that on 64-bit
Neal Norwitz wrote:
Other ideas?
We could rename essential function symbols, like PyInitModule4
(to, say, PyInitModule4b).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
On 1/10/06, M.-A. Lemburg [EMAIL PROTECTED] wrote:
We'd also have to make sure that old extensions don't
just import with a warning, since the change will introduce
buffer overflows and seg faults in extensions that are not
aware of the change.
I agree that on 64-bit platforms we should
M.-A. Lemburg wrote:
Sure. However, most users will compile it on 32-bit
systems. If they find they cannot get it to work on
a 64-bit system, they should ask the author for help,
or just use it in 32-bit mode (as 64-bit mode won't
gain them anything, anyway).
I wonder how you are going to
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
If it were this easy, I wouldn't have objections. But it's
not.
It is so easy. Can you should me an example where it isn't?
The variables you use with these APIs tend to propagate
through the extension, you use them in other calls,
make
Tim Peters wrote:
This reminded me that I still owe you a reply about s# and t# format
codes. It occurred to me that I've never used them, and probably
never will, so I really don't care how they work: I'm only really
worried about widespread ugliness, meaning wide enough that it touches
me
Martin v. Löwis wrote:
Armin Rigo wrote:
This would do the right thing for = 2.4, using ints everywhere; and the
Python.h version 2.5 would detect the #define and assume it's a
2.5-compatible module, so it would override the #define with the real
thing *and* turn on the ssize_t interpretation
M.-A. Lemburg wrote:
I don't see a good solution for these other than introducing
a set of new APIs (and maybe doing some macro magic as Martin
did for PyArg_ParseTuple()). Due to the fact that changes in
the types of output parameters require changes in the
extension variable type layout
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
I don't see a good solution for these other than introducing
a set of new APIs (and maybe doing some macro magic as Martin
did for PyArg_ParseTuple()). Due to the fact that changes in
the types of output parameters require changes in the
extension
M.-A. Lemburg wrote:
If it were this easy, I wouldn't have objections. But it's
not.
It is so easy. Can you should me an example where it isn't?
The variables you use with these APIs tend to propagate
through the extension, you use them in other calls,
make assignments, etc.
They only
[Martin v. Löwis]
...
I am talking about the entirety of these functions,
and claim that they are rarely used (including the
Unicode and buffer APIs).
This reminded me that I still owe you a reply about s# and t# format
codes. It occurred to me that I've never used them, and probably
never
[I just noticed that I sent this mail to just Martin when I meant it
for the list. Sorry Martin!]
On 1/5/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
More precisely, the printf style of function calling, and varargs
functions. ISO C is pretty type safe, but with varargs functions,
you lose
On 1/6/06, Michael Urman [EMAIL PROTECTED] wrote:
I put together a non-parsing checker last month to help me feel more
secure after http://python.org/sf/1365916. It's awful code, but the
simple things are easy to change or extend. Fixing the false positives
and other misinterpretations is
Hi Martin,
On Fri, Dec 30, 2005 at 11:26:44AM +0100, Martin v. L?wis wrote:
Hum. It would be much cleaner to introduce a new format character to
replace '#' and deprecate '#'...
That would certainly be clearer. What character would you suggest?
I see two drawbacks with that approach:
Armin Rigo wrote:
This would do the right thing for = 2.4, using ints everywhere; and the
Python.h version 2.5 would detect the #define and assume it's a
2.5-compatible module, so it would override the #define with the real
thing *and* turn on the ssize_t interpretation of the '#' format
Martin v. Löwis wrote:
Please let me know what you think.
Regards,
Martin
PEP: XXX
Title: Using ssize_t as the index type
Version: $Revision$
Last-Modified: $Date$
Author: Martin v. Löwis [EMAIL PROTECTED]
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created:
Fredrik Lundh wrote:
well, one thing seems to missing from your PEP: in several modules, you've
changed the cast used in the type table. e.g.
...
is this change backwards compatible ?
See the section Conversion guidelines. I prefer the approach taken in
the patch below, i.e. remove the casts
Travis E. Oliphant wrote:
Sounds wonderful. Would love to see this in Python 2.5. This will fix
important 64-bit issues. Perhaps someone could explain to me what the
difference between Py_ssize_t and Py_intptr_t would be? Is this not a
satisfactory Py_ssize_t already?
Practically, yes.
Tim Peters wrote:
Better to use a new gibberish character and deprecate the old one?
Otherwise I'm afraid we'll be stuck supporting PY_SIZE_T_CLEAN
forever, and it's not good to have the meaning of a format string
depend on the presence or absence of a #define far away in the file.
See my
Please let me know what you think.
Regards,
Martin
PEP: XXX
Title: Using ssize_t as the index type
Version: $Revision$
Last-Modified: $Date$
Author: Martin v. Löwis [EMAIL PROTECTED]
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 18-Dec-2005
Post-History:
Abstract
+1. I think this is long overdue. While I can't judge the amount of
code breakage, 2.5 is as good an opportunity as any.
--Guido
On 12/29/05, Martin v. Löwis [EMAIL PROTECTED] wrote:
Please let me know what you think.
Regards,
Martin
PEP: XXX
Title: Using ssize_t as the index type
Not sure what I think of the proposal (though I guess I'm overall +0 --
needs to be done sometime and no time like the present).
However, I think this PEP should be held up as an example of how to write
a good PEP. Aside from my inability to follow some of the arcane points
due to lack of C
Aahz wrote:
However, I think this PEP should be held up as an example of how to write
a good PEP. Aside from my inability to follow some of the arcane points
due to lack of C programming skill, this PEP was extremely readable and
well-organized. Nice job!
Thanks! Part of it probably stems
Hi Martin,
On Thu, Dec 29, 2005 at 03:04:30PM +0100, Martin v. L?wis wrote:
New conversion functions PyInt_FromSsize_t, PyInt_AsSsize_t,
PyLong_AsSsize_t are introduced. PyInt_FromSsize_t will transparently
return a long int object if the value exceeds the MAX_INT.
I guess you mean LONG_MAX
[Martin v. Löwis]
...
PEP: XXX
Title: Using ssize_t as the index type
+1, and for Python 2.5, and the sooner done the less painful for all.
Same concerns as Armin, where this is especially unattractive:
The conversion codes 's#' and 't#' will output Py_ssize_t
if the macro PY_SIZE_T_CLEAN
On 12/29/05, Martin v. Löwis [EMAIL PROTECTED] wrote:
Please let me know what you think.
Regards,
Martin
PEP: XXX
Title: Using ssize_t as the index type
[SNIP]
+1 from me. As everyone else is saying, this has to happen at some
point and 2.5 is as good as any.
-Brett
Martin v. Löwis wrote:
Please let me know what you think.
+1. in honor of the Bike Shed Effect, I'm going to assume that you've
thought of everything.
:::
well, one thing seems to missing from your PEP: in several modules, you've
changed the cast used in the type table. e.g.
---
27 matches
Mail list logo
