Here's the patch. Also 2 new source files: - pystrtod.h goes to Include/ - pystrtod.c goes to Python/ The next step is to ask glib authors for permission to relicense the code. Also, the locale module should be changed, to allow LC_NUMERIC to be changed, etc. Regards. -- Gustavo J. A. M. Carneiro <gjc@inescporto.pt> <gustavo@users.sourceforge.net>
Gustavo J A M Carneiro wrote:
Here's the patch. Also 2 new source files: - pystrtod.h goes to Include/ - pystrtod.c goes to Python/
The next step is to ask glib authors for permission to relicense the code. Also, the locale module should be changed, to allow LC_NUMERIC to be changed, etc.
Please don't post patches to python-dev; post them to sf.net/projects/python instead. However, a) it is unlikely that patches are accepted from anybody but the author of the code, and b) it is unlikely that patches are implemented that provide huge chunks of the C library. Regards, Martin
On Sat, Jul 19, 2003 at 04:31:25PM +0200, "Martin v. Löwis" wrote:
Gustavo J A M Carneiro wrote:
Here's the patch. Also 2 new source files:
Please don't post patches to python-dev; post them to sf.net/projects/python instead.
However, a) it is unlikely that patches are accepted from anybody but the author of the code, and b) it is unlikely that patches are implemented that provide huge chunks of the C library.
I'm afraid I didn't quite understand these two points: a) Do you mean to say that the patch should be sent *to* the original author of the locale code? The original author of the code that *calls* atof/strtod? Or *by* the original author of the g_ascii_* functions? If the latter I can try and get Alex Larsson to submit the code. Is written permission from the glib team, relicensing the code, not acceptable enough, though? b) I'm unsure as to how we should proceed without offering alternative versions of strtod/formatd (which is what the pystrtod.c file includes); AFAICS, the current situation is *caused* by the libc versions not being LC_NUMERIC-safe. Do you see an alternative? Take care, -- Christian Reis, Senior Engineer, Async Open Source, Brazil. http://async.com.br/~kiko/ | [+55 16] 261 2331 | NMFL
Christian Reis <kiko@async.com.br> writes:
a) it is unlikely that patches are accepted from anybody but the author of the code, and b) it is unlikely that patches are implemented that provide huge chunks of the C library.
I'm afraid I didn't quite understand these two points:
a) Do you mean to say that the patch should be sent *to* the original author of the locale code? The original author of the code that *calls* atof/strtod?
No. I said that the original author should send us the patches; we will only accept them from that author.
If the latter I can try and get Alex Larsson to submit the code. Is written permission from the glib team, relicensing the code, not acceptable enough, though?
We would have to discuss this in the PSF. In general, we want the PSF to be owner of all contributed code, see http://www.python.org/psf/psf-contributor-agreement.html We had bad experience with contributions by non-authors in the past, and had to back out changes that we later found we had no right to distribute.
b) I'm unsure as to how we should proceed without offering alternative versions of strtod/formatd (which is what the pystrtod.c file includes); AFAICS, the current situation is *caused* by the libc versions not being LC_NUMERIC-safe. Do you see an alternative?
It might well be unimplementable. However, if you can find platform-specific routines that you can wrap with a small wrapper, falling back to strtod if such routines are not available, that might be a way out. For example, on glibc, you could use __strtod_l. Regards, Martin
A Dom, 2003-07-20 às 10:50, Martin v. Löwis escreveu:
Christian Reis <kiko@async.com.br> writes:
a) it is unlikely that patches are accepted from anybody but the author of the code, and b) it is unlikely that patches are implemented that provide huge chunks of the C library.
I'm afraid I didn't quite understand these two points:
a) Do you mean to say that the patch should be sent *to* the original author of the locale code? The original author of the code that *calls* atof/strtod?
No. I said that the original author should send us the patches; we will only accept them from that author.
What if the original author isn't the least interested in Python? I am, but I'm not willing reinvent the wheel.
If the latter I can try and get Alex Larsson to submit the code. Is written permission from the glib team, relicensing the code, not acceptable enough, though?
We would have to discuss this in the PSF. In general, we want the PSF to be owner of all contributed code, see
http://www.python.org/psf/psf-contributor-agreement.html
We had bad experience with contributions by non-authors in the past, and had to back out changes that we later found we had no right to distribute.
b) I'm unsure as to how we should proceed without offering alternative versions of strtod/formatd (which is what the pystrtod.c file includes); AFAICS, the current situation is *caused* by the libc versions not being LC_NUMERIC-safe. Do you see an alternative?
It might well be unimplementable. However, if you can find platform-specific routines that you can wrap with a small wrapper, falling back to strtod if such routines are not available, that might be a way out. For example, on glibc, you could use __strtod_l.
Well, *my* glibc (2.3.1) has no such function. Even if it had, I would not use it because of the double underscore prefix. cd /usr/include/ find . -type f -print0 | xargs -0 -e grep -n -e __strtod_l grep exited abnormally with code 123 at Sun Jul 20 13:48:41 Anyway, the code is not that big, and it uses libc's strtod. Regards. -- Gustavo J. A. M. Carneiro <gjc@inescporto.pt> <gustavo@users.sourceforge.net>
Gustavo J A M Carneiro <gjc@inescporto.pt> writes:
No. I said that the original author should send us the patches; we will only accept them from that author.
What if the original author isn't the least interested in Python? I am, but I'm not willing reinvent the wheel.
Then find a way to use that code without incorporating it into Python. Regards, Martin
A Dom, 2003-07-20 às 10:50, Martin v. Löwis escreveu:
Christian Reis <kiko@async.com.br> writes:
a) it is unlikely that patches are accepted from anybody but the author of the code, and b) it is unlikely that patches are implemented that provide huge chunks of the C library.
I'm afraid I didn't quite understand these two points:
a) Do you mean to say that the patch should be sent *to* the original author of the locale code? The original author of the code that *calls* atof/strtod?
No. I said that the original author should send us the patches; we will only accept them from that author.
If the latter I can try and get Alex Larsson to submit the code. Is written permission from the glib team, relicensing the code, not acceptable enough, though?
We would have to discuss this in the PSF. In general, we want the PSF to be owner of all contributed code, see
http://www.python.org/psf/psf-contributor-agreement.html
We had bad experience with contributions by non-authors in the past, and had to back out changes that we later found we had no right to distribute.
b) I'm unsure as to how we should proceed without offering alternative versions of strtod/formatd (which is what the pystrtod.c file includes); AFAICS, the current situation is *caused* by the libc versions not being LC_NUMERIC-safe. Do you see an alternative?
It might well be unimplementable. However, if you can find platform-specific routines that you can wrap with a small wrapper, falling back to strtod if such routines are not available, that might be a way out. For example, on glibc, you could use __strtod_l.
Well, the function does exist, but it's called strtod_l. I posted a new patch to sourceforge. It uses these glibc locale extensions when available, but falls back to the glib implementations if these extensions are not available. https://sourceforge.net/tracker/index.php?func=detail&aid=774665&group_id=5470&atid=305470 Regards. -- Gustavo J. A. M. Carneiro <gjc@inescporto.pt> <gustavo@users.sourceforge.net>
participants (4)
-
"Martin v. Löwis" -
Christian Reis -
Gustavo J A M Carneiro -
martin＠v.loewis.de