Re: [Python-Dev] [Python-checkins] r42396 - peps/trunk/pep-0011.txt
[Moving to python-dev] I don't have a strong opinion. Any one else have an opinion about removing --with-wctype-functions from configure? n -- On 2/16/06, M.-A. Lemburg <mal@egenix.com> wrote:
neal.norwitz wrote:
Author: neal.norwitz Date: Thu Feb 16 06:25:37 2006 New Revision: 42396
Modified: peps/trunk/pep-0011.txt Log: MAL says this option should go away in bug report 874534:
The reason for the removal is that the option causes semantical problems and makes Unicode work in non-standard ways on platforms that use locale-aware extensions to the wc-type functions.
Since it wasn't previously announced, we can keep the option until 2.6 unless someone feels strong enough to rip it out.
I've been wanting to rip this out for some time now, but you're right: I forgot to add this to PEP 11, so let's wait for another release.
OTOH, this normally only affects system builders, so perhaps we could do this a little faster, e.g. add a warning in the first alpha and then rip it out with one of the last betas ?!
Modified: peps/trunk/pep-0011.txt
+ Name: Systems using --with-wctype-functions + Unsupported in: Python 2.6 + Code removed in: Python 2.6
Neal Norwitz wrote:
[Moving to python-dev]
I don't have a strong opinion. Any one else have an opinion about removing --with-wctype-functions from configure?
FWIW, I announced this plan in Dec 2004: http://mail.python.org/pipermail/python-dev/2004-December/050193.html I didn't get any replies back then, so assumed that no-one would object, but forgot to add this to the PEP 11. The reason I'd like to get this removed early rather than later is that some Linux distros happen to use the config switch causing the Python Unicode implementation on those distros to behave inconsistent with regular Python builds. After all we've put a lot of effort into making sure that the Unicode implementation does work independently of the platform, even on platforms that don't have Unicode support at all. Another candidate for removal is the --disable-unicode switch. We should probably add a deprecation warning for that in Py 2.5 and then remove the hundreds of #idef Py_USING_UNICODE from the source code in time for Py 2.6.
n --
On 2/16/06, M.-A. Lemburg <mal@egenix.com> wrote:
neal.norwitz wrote:
Author: neal.norwitz Date: Thu Feb 16 06:25:37 2006 New Revision: 42396
Modified: peps/trunk/pep-0011.txt Log: MAL says this option should go away in bug report 874534:
The reason for the removal is that the option causes semantical problems and makes Unicode work in non-standard ways on platforms that use locale-aware extensions to the wc-type functions.
Since it wasn't previously announced, we can keep the option until 2.6 unless someone feels strong enough to rip it out. I've been wanting to rip this out for some time now, but you're right: I forgot to add this to PEP 11, so let's wait for another release.
OTOH, this normally only affects system builders, so perhaps we could do this a little faster, e.g. add a warning in the first alpha and then rip it out with one of the last betas ?!
Modified: peps/trunk/pep-0011.txt
+ Name: Systems using --with-wctype-functions + Unsupported in: Python 2.6 + Code removed in: Python 2.6
Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/mal%40egenix.com
-- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 17 2006)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
On 2/17/06, M.-A. Lemburg <mal@egenix.com> wrote:
Neal Norwitz wrote:
I don't have a strong opinion. Any one else have an opinion about removing --with-wctype-functions from configure?
FWIW, I announced this plan in Dec 2004:
http://mail.python.org/pipermail/python-dev/2004-December/050193.html
I didn't get any replies back then, so assumed that no-one would object, but forgot to add this to the PEP 11.
The reason I'd like to get this removed early rather than later is that some Linux distros happen to use the config switch causing the Python Unicode implementation on those distros to behave inconsistent with regular Python builds.
Like I said I don't have a strong opinion. At least update PEP 11 now. It would be good to ask on c.l.p. I suspect that no one cares enough about this flag to complain. So it's probably ok to remove it. But we should at least give people the opportunity to object.
Another candidate for removal is the --disable-unicode switch.
We should probably add a deprecation warning for that in Py 2.5 and then remove the hundreds of #idef Py_USING_UNICODE from the source code in time for Py 2.6.
I've heard of a bunch of people using --disable-unicode. I'm not sure if it's curiosity or if there are really production builds without unicode. Ask this on c.l.p too. We can update configure to add the warning and add a note to PEP 11. If we don't hear any complaints remove it for 2.6. If there are complaints, we can always back off. n
Neal Norwitz wrote:
On 2/17/06, M.-A. Lemburg <mal@egenix.com> wrote:
Neal Norwitz wrote:
Another candidate for removal is the --disable-unicode switch.
We should probably add a deprecation warning for that in Py 2.5 and then remove the hundreds of #idef Py_USING_UNICODE from the source code in time for Py 2.6.
I've heard of a bunch of people using --disable-unicode. I'm not sure if it's curiosity or if there are really production builds without unicode. Ask this on c.l.p too.
Such a switch quite likely is useful to those creating Python interpreters for small hand-held devices, where space is at a premium. I would hesitate to remove switches to drop features in general, for that reason. Although I have played with reducing the footprint of Python, I am not currently doing so. I could never get the footprint down sufficiently to make it usable, unfortunately. But I would like to see the Python developers maintain an awareness of memory consumption and not assume that Python is always run on modern fully-loaded desktops. We are seeing increasing use of Python in embedded systems these days. -Jeff
On 2/19/06, Jeff Rush <jeff@taupro.com> wrote: [Quoting Neal Norwitz]
I've heard of a bunch of people using --disable-unicode. I'm not sure if it's curiosity or if there are really production builds without unicode. Ask this on c.l.p too.
Such a switch quite likely is useful to those creating Python interpreters for small hand-held devices, where space is at a premium. I would hesitate to remove switches to drop features in general, for that reason.
Although I have played with reducing the footprint of Python, I am not currently doing so. I could never get the footprint down sufficiently to make it usable, unfortunately. But I would like to see the Python developers maintain an awareness of memory consumption and not assume that Python is always run on modern fully-loaded desktops. We are seeing increasing use of Python in embedded systems these days.
Do you know of any embedded platform that doesn't have unicode support as a requirement? Python runs fine on Nokia phones running Symbian, where *everything* is a Unicode string. -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum wrote:
On 2/19/06, Jeff Rush <jeff@taupro.com> wrote: [Quoting Neal Norwitz]
I've heard of a bunch of people using --disable-unicode. I'm not sure if it's curiosity or if there are really production builds without unicode. Ask this on c.l.p too.
Do you know of any embedded platform that doesn't have unicode support as a requirement? Python runs fine on Nokia phones running Symbian, where *everything* is a Unicode string.
1. PalmOS, at least the last time I was involved with it. Python on a Palm is a very tight fit. 2. "GM862 Cellular Module with Python Interpreter" http://tinyurl.com/jgxz These may be dimishing markets as memory capacity increases and I wouldn't argue adding compile flags for such at this late date, but if the flags are already there, perhaps the slight inconvenience to Python-internal developers is worth it. Hey, perhaps dropping out Unicode support is not a big win - I just know it is useful at times to have a collection of flags to drop out floating point, complex arithmetic, language parsing and such for memory-constrained cases. -Jeff
Jeff Rush wrote:
Guido van Rossum wrote:
On 2/19/06, Jeff Rush <jeff@taupro.com> wrote: [Quoting Neal Norwitz]
I've heard of a bunch of people using --disable-unicode. I'm not sure if it's curiosity or if there are really production builds without unicode. Ask this on c.l.p too.
Do you know of any embedded platform that doesn't have unicode support as a requirement? Python runs fine on Nokia phones running Symbian, where *everything* is a Unicode string.
1. PalmOS, at least the last time I was involved with it. Python on a Palm is a very tight fit.
2. "GM862 Cellular Module with Python Interpreter" http://tinyurl.com/jgxz
These may be dimishing markets as memory capacity increases and I wouldn't argue adding compile flags for such at this late date, but if the flags are already there, perhaps the slight inconvenience to Python-internal developers is worth it.
Hey, perhaps dropping out Unicode support is not a big win - I just know it is useful at times to have a collection of flags to drop out floating point, complex arithmetic, language parsing and such for memory-constrained cases.
These switches make the code less maintainable. I'm not even talking about the testing overhead. I'd say that the parties interested in non-Unicode versions of Python should maintain these branches of Python. Dito for other stripped down versions. Note that this does not mean that we should forget about memory consumption issues. It's just that if there's only marginal interest in certain special builds of Python, I don't see the requirement for the Python core developers to maintain them. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 20 2006)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
M.-A. Lemburg wrote:
Note that this does not mean that we should forget about memory consumption issues. It's just that if there's only marginal interest in certain special builds of Python, I don't see the requirement for the Python core developers to maintain them.
Well, the cost of Unicode support is not so much in the algorithmic part, but in the tables that come along with it. AFAICT, everything but unicodectype is optional; that is 5KiB of code and 20KiB of data on x86. Actually, the size of the code *does* matter, at a second glance. Here are the largest object files in the Python code base on my system (not counting dynamic modules): text data bss dec hex filename 4845 19968 0 24813 60ed Objects/unicodectype.o 22633 2432 352 25417 6349 Objects/listobject.o 29259 1412 152 30823 7867 Objects/classobject.o 20696 11488 4 32188 7dbc Python/bltinmodule.o 33579 740 0 34319 860f Objects/longobject.o 34119 16 288 34423 8677 Python/ceval.o 35179 2796 0 37975 9457 Modules/_sre.o 26539 15820 416 42775 a717 Modules/posixmodule.o 35283 8800 1056 45139 b053 Objects/stringobject.o 50360 0 28 50388 c4d4 Python/compile.o 68455 4624 440 73519 11f2f Objects/typeobject.o 69993 9316 1196 80505 13a79 Objects/unicodeobject.o So it appears that dropping Unicode support can indeed provide some savings. For reference, we also have an option to drop complex numbers: 9654 692 4 10350 286e Objects/complexobject.o Regards, Martin
Martin v. Löwis wrote:
M.-A. Lemburg wrote:
Note that this does not mean that we should forget about memory consumption issues. It's just that if there's only marginal interest in certain special builds of Python, I don't see the requirement for the Python core developers to maintain them.
Well, the cost of Unicode support is not so much in the algorithmic part, but in the tables that come along with it. AFAICT, everything but unicodectype is optional; that is 5KiB of code and 20KiB of data on x86. Actually, the size of the code *does* matter, at a second glance. Here are the largest object files in the Python code base on my system (not counting dynamic modules):
text data bss dec hex filename 4845 19968 0 24813 60ed Objects/unicodectype.o 22633 2432 352 25417 6349 Objects/listobject.o 29259 1412 152 30823 7867 Objects/classobject.o 20696 11488 4 32188 7dbc Python/bltinmodule.o 33579 740 0 34319 860f Objects/longobject.o 34119 16 288 34423 8677 Python/ceval.o 35179 2796 0 37975 9457 Modules/_sre.o 26539 15820 416 42775 a717 Modules/posixmodule.o 35283 8800 1056 45139 b053 Objects/stringobject.o 50360 0 28 50388 c4d4 Python/compile.o 68455 4624 440 73519 11f2f Objects/typeobject.o 69993 9316 1196 80505 13a79 Objects/unicodeobject.o
So it appears that dropping Unicode support can indeed provide some savings.
For reference, we also have an option to drop complex numbers:
9654 692 4 10350 286e Objects/complexobject.o
So why not drop that as well ? Note that I'm not saying that these switches are useless - of course they do allow to strip down the Python interpreter. I believe that only very few people are interested in having these options and it's fair enough to put the burden of maintaining these branches on them. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 21 2006)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
M.-A. Lemburg wrote:
Note that I'm not saying that these switches are useless - of course they do allow to strip down the Python interpreter. I believe that only very few people are interested in having these options and it's fair enough to put the burden of maintaining these branches on them.
Which is proven by the fact that many tests fail without unicode. So at least the people building --without-unicode don't care much about brokenness. Georg
M.-A. Lemburg wrote:
I'd say that the parties interested in non-Unicode versions of Python should maintain these branches of Python. Dito for other stripped down versions.
I understand where you're coming from but the embedded market I encounter tends to focus on the hardware side. If they can get a marketing star by grabbing Python off-the shelf, tweak the build and produce something to include with their product, they will. But if they have to maintain a branch, they'll just go with the defacto C API most such devices use.
Note that this does not mean that we should forget about memory consumption issues. It's just that if there's only marginal interest in certain special builds of Python, I don't see the requirement for the Python core developers to maintain them.
These requirements of customization may not be a strong case for today but could be impacting future growth of the language in certain sectors. I'm a rabid Python evangelist and alway try to push Python into more nooks and crannies of the marketplace, similar to how the Linux kernel is available from the tiniest machines to the largest iron. If the focus of Python is to be strictly a desktop, conventional (mostly ;-) language, restricting its adaptability to other less interesting environments may be a reasonable tradeoff to improve its maintainability. But adaptability, especially when you don't fully grok where or how it will be used, can also be a competitive advantage. -Jeff
Jeff Rush wrote:
M.-A. Lemburg wrote:
I'd say that the parties interested in non-Unicode versions of Python should maintain these branches of Python. Dito for other stripped down versions.
I understand where you're coming from but the embedded market I encounter tends to focus on the hardware side. If they can get a marketing star by grabbing Python off-the shelf, tweak the build and produce something to include with their product, they will. But if they have to maintain a branch, they'll just go with the defacto C API most such devices use.
Note that this does not mean that we should forget about memory consumption issues. It's just that if there's only marginal interest in certain special builds of Python, I don't see the requirement for the Python core developers to maintain them.
These requirements of customization may not be a strong case for today but could be impacting future growth of the language in certain sectors. I'm a rabid Python evangelist and alway try to push Python into more nooks and crannies of the marketplace, similar to how the Linux kernel is available from the tiniest machines to the largest iron. If the focus of Python is to be strictly a desktop, conventional (mostly ;-) language, restricting its adaptability to other less interesting environments may be a reasonable tradeoff to improve its maintainability. But adaptability, especially when you don't fully grok where or how it will be used, can also be a competitive advantage.
I don't think this is a strong enough case to warrant having to maintain a separate branch of the Python core. Even platforms like Palm nowadays have enough RAM to cope with the 100kB or so that Unicode support adds. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 21 2006)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::
participants (6)
-
"Martin v. Löwis" -
Georg Brandl -
Guido van Rossum -
Jeff Rush -
M.-A. Lemburg -
Neal Norwitz