Re: [Python-Dev] Removing Non-Unicode Support?
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): textdata bss dec hex filename 4845 19968 0 2481360ed Objects/unicodectype.o 226332432 352 254176349 Objects/listobject.o 292591412 152 308237867 Objects/classobject.o 20696 11488 4 321887dbc Python/bltinmodule.o 33579 740 0 34319860f Objects/longobject.o 34119 16 288 344238677 Python/ceval.o 351792796 0 379759457 Modules/_sre.o 26539 15820 416 42775a717 Modules/posixmodule.o 3528388001056 45139b053 Objects/stringobject.o 50360 0 28 50388c4d4 Python/compile.o 684554624 440 73519 11f2f Objects/typeobject.o 6999393161196 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 10350286e 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 ! ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Removing Non-Unicode Support?
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 ! ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Removing Non-Unicode Support?
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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Removing Non-Unicode Support?
Guido van Rossum wrote: On 2/19/06, Jeff Rush [EMAIL PROTECTED] 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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Removing Non-Unicode Support?
Jeff Rush wrote: Guido van Rossum wrote: On 2/19/06, Jeff Rush [EMAIL PROTECTED] 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 ! ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Removing Non-Unicode Support?
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): textdata bss dec hex filename 4845 19968 0 2481360ed Objects/unicodectype.o 226332432 352 254176349 Objects/listobject.o 292591412 152 308237867 Objects/classobject.o 20696 11488 4 321887dbc Python/bltinmodule.o 33579 740 0 34319860f Objects/longobject.o 34119 16 288 344238677 Python/ceval.o 351792796 0 379759457 Modules/_sre.o 26539 15820 416 42775a717 Modules/posixmodule.o 3528388001056 45139b053 Objects/stringobject.o 50360 0 28 50388c4d4 Python/compile.o 684554624 440 73519 11f2f Objects/typeobject.o 6999393161196 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 10350286e Objects/complexobject.o Regards, Martin ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Removing Non-Unicode Support?
Neal Norwitz wrote: On 2/17/06, M.-A. Lemburg [EMAIL PROTECTED] 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 ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Removing Non-Unicode Support?
On 2/19/06, Jeff Rush [EMAIL PROTECTED] 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/) ___ 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/archive%40mail-archive.com
