[Python-Dev] usefulness of "extension modules" section in Misc/NEWS
Hi, What's exactly the guideline for choosing between the "Library" and "Extension modules" section when updating Misc/NEWS? Is it just the fact that the modified files live under Lib/ or Modules/? I've frequently made a mistake when updating Misc/NEWS, and when looking at it, I'm not the only one. Is there really a good reason for having distinct sections? If the intended audience for this file are end users, ISTM that the only things that matters is that it's a library change, the fact that the modification impacted Python/C code isn't really relevant. Also, for example if you're rewriting a library from Python to C (or vice versa), should it appear under both sections? FWIW, the What's new documents don't have such a distinction. Cheers, cf ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] usefulness of "extension modules" section in Misc/NEWS
On Sun, Jan 27, 2013 at 7:56 PM, Charles-François Natali wrote: > If the intended audience for this file are end users, ISTM that the > only things that matters is that it's a library change, the fact that > the modification impacted Python/C code isn't really relevant. I have no objection to merging them. A separate section for "C API" may still make sense, though. Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] usefulness of "extension modules" section in Misc/NEWS
On Sun, 27 Jan 2013 10:56:51 +0100 Charles-François Natali wrote: > Hi, > > What's exactly the guideline for choosing between the "Library" and > "Extension modules" section when updating Misc/NEWS? > Is it just the fact that the modified files live under Lib/ or Modules/? > > I've frequently made a mistake when updating Misc/NEWS, and when > looking at it, I'm not the only one. > > Is there really a good reason for having distinct sections? > > If the intended audience for this file are end users, ISTM that the > only things that matters is that it's a library change, the fact that > the modification impacted Python/C code isn't really relevant. Agreed. I think "we" should merge them (for some value of a motivated we :-)). Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 433: Choose the default value of the new cloexec parameter
2013/1/27 Guido van Rossum : > I had missed this detail. I agree that it should be exposed in the > interpreter. To my mind it is more like PYTHONPATH (which corresponds > roughly to sys.path manipulations) than like -R (which changes > something that should never be changed again, otherwise the sanity of > the interpreter be at risk). It would seem hard to unittest the > feature if it cannot be changed from within. But I can also think of > other use cases for changing it from within (e.g. a script that > decides on how to set it using a computation based on its arguments). sys.path is usually only used to add a new path, not to remove path from other libraries. I'm not sure that it's the best example to compare it to sys.setdefaultcloexec(). If sys.setdefaultcloexec() accepts an argument (so allow sys.setdefaultcloexec(False)), problems happen when two libraries, or an application and a library, disagree. Depending how/when the library is loaded, the flag may be True or False. I prefer to have a simple sys.setdefaultcloexec() which always set the flag to True. It's also simpler to explain how the default value is computed (it's less surprising). -- Unit tests can workaround the limitation using subprocesses. My implementation doesn't use sys.setdefaultcloexec() anymore, it just ensures that functions respect the current default value. I ran tests manually to test both default values (True and False). Tests may be improved later to test both defalut values using subprocess. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 433: Choose the default value of the new cloexec parameter
On Sun, 27 Jan 2013 12:23:15 +0100 Victor Stinner wrote: > 2013/1/27 Guido van Rossum : > > I had missed this detail. I agree that it should be exposed in the > > interpreter. To my mind it is more like PYTHONPATH (which corresponds > > roughly to sys.path manipulations) than like -R (which changes > > something that should never be changed again, otherwise the sanity of > > the interpreter be at risk). It would seem hard to unittest the > > feature if it cannot be changed from within. But I can also think of > > other use cases for changing it from within (e.g. a script that > > decides on how to set it using a computation based on its arguments). > > sys.path is usually only used to add a new path, not to remove path > from other libraries. I'm not sure that it's the best example to > compare it to sys.setdefaultcloexec(). > > If sys.setdefaultcloexec() accepts an argument (so allow > sys.setdefaultcloexec(False)), problems happen when two libraries, or > an application and a library, disagree. Depending how/when the library > is loaded, the flag may be True or False. > > I prefer to have a simple sys.setdefaultcloexec() which always set the > flag to True. It's also simpler to explain how the default value is > computed (it's less surprising). I don't think such limitations are very useful in practice. Users calling sys.setdefaultexec() will have to be sufficiently knowledgeable to understand the implications, anyway. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 433: Choose the default value of the new cloexec parameter
On Sun, Jan 27, 2013 at 9:29 PM, Antoine Pitrou wrote: > I don't think such limitations are very useful in practice. Users > calling sys.setdefaultexec() will have to be sufficiently knowledgeable > to understand the implications, anyway. I've yet to hear a use case for being able to turn it off globally if the application developer has indicated they want it on. A global flag that can be turned off programmatically is worse than no global flag at all. If we're never going to migrate to cloexec-on-by-default, then there simply shouldn't be a global flag - the option should just default to False. If we're going to migrate to cloexec-on-by-default some day, then the global flag should purely be a transition strategy to allow people to try out that future behaviour and adjust their application appropriately (by clearing the flag on descriptors that really need to be inherited). The typical default that should be assumed by library code will still be cloexec-off-by-default. A completely flexible global flag is just a plain bad idea for all the reasons Charles-François gave. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Ctypes bug fix for Solaris - too late for 2.7.3?
I hit a bug in the ctypes package on Solaris yesterday. Investigating, I found there is a patch: http://bugs.python.org/issue5289 I applied it and verified that when run as a main program ctypes/util.py now works. Is it too late to get this into 2.7.3? Given the nature of the patch (a new block of code only matched on Solaris, and the fact that find_library is quite broken now on that platform), it's hard to see how things would be worse after applying it. BTW, this will be a requirement for getting PyPy running on Solaris. (That's the context where i encountered it.) Thanks, Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Ctypes bug fix for Solaris - too late for 2.7.3?
2013/1/27 Skip Montanaro : > I hit a bug in the ctypes package on Solaris yesterday. > Investigating, I found there is a patch: > > http://bugs.python.org/issue5289 > > I applied it and verified that when run as a main program > ctypes/util.py now works. > > Is it too late to get this into 2.7.3? Yes, it's far too late for 2.7.3, since that was released last April. :) I think it could go into 2.7.4, though. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Ctypes bug fix for Solaris - too late for 2.7.3?
>> Is it too late to get this into 2.7.3? > > Yes, it's far too late for 2.7.3, since that was released last April. > :) I think it could go into 2.7.4, though. Whoops, sorry. I thought I had remembered some recent discussion of an upcoming 2.7 micro. Off-by-one error, or just brain freeze? :-) Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Ctypes bug fix for Solaris - too late for 2.7.3?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/27/2013 10:31 AM, Skip Montanaro wrote: >>> Is it too late to get this into 2.7.3? >> >> Yes, it's far too late for 2.7.3, since that was released last >> April. :) I think it could go into 2.7.4, though. > > Whoops, sorry. I thought I had remembered some recent discussion of > an upcoming 2.7 micro. Off-by-one error, or just brain freeze? :-) The upcoming micro you recall is 2.7.4. The 2.7.3 train left the station already. ;) Tres. - -- === Tres Seaver +1 540-429-0999 [email protected] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with undefined - http://www.enigmail.net/ iEUEARECAAYFAlEFUVcACgkQ+gerLs4ltQ6X3QCgscrJNOQo2mB5ylS97OYJ7EG/ tKYAl3YvSGLNd9NeZ6AKchreRcjNvYc= =yimz -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Anyone building Python --without-doc-strings?
We (CCP) are certainly compiling python without docstrings for our embedded platforms (that include the PS3) Anyone using python as en engine to be used by programs and not users will appreciate the deletion of unneeded memory. K -Original Message- From: Python-Dev [mailto:[email protected]] On Behalf Of R. David Murray Sent: 27. janúar 2013 00:38 To: [email protected] Subject: Re: [Python-Dev] Anyone building Python --without-doc-strings? On Sat, 26 Jan 2013 17:19:32 +0100, Antoine Pitrou wrote: > On Sat, 26 Jan 2013 17:03:59 +0100 > Stefan Krah wrote: > > Stefan Krah wrote: > > > I'm not sure how accurate the output is for measuring these > > > things, but according to ``ls'' and ``du'' the option is indeed quite > > > worthless: > > > > > > ./configure CFLAGS="-Os -s" LDFLAGS="-s" && make > > > 1.8M Jan 26 16:36 python > > > ./configure --without-doc-strings CFLAGS="-Os -s" LDFLAGS="-s" && make > > > 1.6M Jan 26 16:33 python > > > > The original contribution *was* in fact aiming for "10% smaller", see: > > > > http://docs.python.org/release/2.3/whatsnew/node20.html > > > > So apparently people thought it was useful. > > After a bit of digging, I found the following discussions: > http://mail.python.org/pipermail/python-dev/2001-November/018444.html > http://mail.python.org/pipermail/python-dev/2002-January/019392.html > http://bugs.python.org/issue505375 > > Another reason for accepting the patch seemed to be that it introduced > the Py_DOCSTR() macros, which were viewed as helpful for other reasons > (some people talked about localizing docstrings). > > I would point out that if 200 KB is really a big win for someone, then > Python (and especially Python 3) is probably not the best language for > them. > > It is also ironic how the executable size went up since then (from 0.6 > to more than 1.5 MB) :-) 200K can make a difference. It does on the QNX platform, for example, where there is no virtual memory. It would be nice to reduce that executable size, toobut I'm not volunteering to try (at least not yet) :) --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 433: Choose the default value of the new cloexec parameter
On Sun, Jan 27, 2013 at 3:45 AM, Nick Coghlan wrote: > On Sun, Jan 27, 2013 at 9:29 PM, Antoine Pitrou wrote: >> I don't think such limitations are very useful in practice. Users >> calling sys.setdefaultexec() will have to be sufficiently knowledgeable >> to understand the implications, anyway. > > I've yet to hear a use case for being able to turn it off globally if > the application developer has indicated they want it on. A global flag > that can be turned off programmatically is worse than no global flag > at all. Out of context that last statement sounds pretty absurd. :-) > If we're never going to migrate to cloexec-on-by-default, then there > simply shouldn't be a global flag - the option should just default to > False. That doesn't seem to follow. We might never want to turn it on by default for reasons of compatibility with POSIX (whatever you say, POSIX semantics seep through Python in many places). But it might still be useful to be able to turn it on for specific programs (and doing that in code is a lot more convenient than having to say "run this app with python --cloexec", which sounds a real pain). > If we're going to migrate to cloexec-on-by-default some day, then the > global flag should purely be a transition strategy to allow people to > try out that future behaviour and adjust their application > appropriately (by clearing the flag on descriptors that really need to > be inherited). The typical default that should be assumed by library > code will still be cloexec-off-by-default. But typical library code won't care one way or another, will it? > A completely flexible global flag is just a plain bad idea for all the > reasons Charles-François gave. Honestly, what happened to the idea that we're all adults here? The likelihood that someone is clueless enough to misuse the flag and yet clueful enough to find out how to change it seems remote -- and they pretty much deserve what they get. It's like calling socket.settimeout(0.1) and then complaining that urllib.urlopen() raises exceptions, or calling sys.setrecursionlimit(100) when you are getting StackOverflowError. The only reason I can see why a flag should never be changeable after the fact is when it would end up violating the integrity of the interpreter. But I don't see that here. I just see paranoia about protecting users from all possible security issues. That seems a hopeless quest. That said, I'm sure I'll survive if you ignore my opinion, so I explicitly give you that option -- in the grand scheme of things I can't care that much about this and it seems a mostly theoretical issue. (And, an attacker who can exploit file descriptors given to it can probably find plenty of other attacks on a system they've broken into.) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Boost Software License
Is Boost Software License [1] compatible with Python license? Can I steal some code from Boost library [2]? [1] http://www.boost.org/LICENSE_1_0.txt [2] http://www.boost.org/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Boost Software License
On Sun, Jan 27, 2013 at 06:52:21PM +0200, Serhiy Storchaka wrote: > Is Boost Software License [1] compatible with Python license? Can I > steal some code from Boost library [2]? > > [1] http://www.boost.org/LICENSE_1_0.txt > [2] http://www.boost.org/ BSD-ish license? I think yes, it's compatible with Python license. Also I think you have to copy the license to the section "Licenses and Acknowledgements for Incorporated Software" in Doc/license.rst. Oleg. -- Oleg Broytmanhttp://phdru.name/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] usefulness of "extension modules" section in Misc/NEWS
On Sun, Jan 27, 2013 at 6:02 AM, Antoine Pitrou wrote: > On Sun, 27 Jan 2013 10:56:51 +0100 > Charles-François Natali wrote: > > Hi, > > > > What's exactly the guideline for choosing between the "Library" and > > "Extension modules" section when updating Misc/NEWS? > > Is it just the fact that the modified files live under Lib/ or Modules/? > > > > I've frequently made a mistake when updating Misc/NEWS, and when > > looking at it, I'm not the only one. > > > > Is there really a good reason for having distinct sections? > > > > If the intended audience for this file are end users, ISTM that the > > only things that matters is that it's a library change, the fact that > > the modification impacted Python/C code isn't really relevant. > > Agreed. I think "we" should merge them (for some value of a motivated > we :-)). > "We" is "me" and it was a 2 line delete in 1fabff717ef4 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 433: Choose the default value of the new cloexec parameter
Guido van Rossum writes: > It's like calling socket.settimeout(0.1) and then complaining that > urllib.urlopen() raises exceptions but that's not what's happening. you'll see urllib.urlopen raising exceptions and only afterwards realize that you called into some third party library code that decided to change the timeout. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Boost Software License
Serhiy Storchaka, 27.01.2013 17:52: > Is Boost Software License [1] compatible with Python license? Can I steal > some code from Boost library [2]? > > [1] http://www.boost.org/LICENSE_1_0.txt > [2] http://www.boost.org/ Depends on what you want to do with it after stealing it. Assuming you want to add it to CPython, two things to consider: - Isn't Boost C++ code? - Usually, people who contribute code to CPython must sign a contributors agreement. As far as I understand it, that would be those who wrote it, not those who "stole" it from them. Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 433: Choose the default value of the new cloexec parameter
On Sun, 27 Jan 2013 19:42:59 +0100, Ralf Schmitt wrote: > Guido van Rossum writes: > > > It's like calling socket.settimeout(0.1) and then complaining that > > urllib.urlopen() raises exceptions > > but that's not what's happening. you'll see urllib.urlopen raising > exceptions and only afterwards realize that you called into some third > party library code that decided to change the timeout. What is stopping some some third party library code from calling socket.settimeout(0.1)? --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 433: Choose the default value of the new cloexec parameter
"R. David Murray" writes: > On Sun, 27 Jan 2013 19:42:59 +0100, Ralf Schmitt wrote: >> Guido van Rossum writes: >> >> > It's like calling socket.settimeout(0.1) and then complaining that >> > urllib.urlopen() raises exceptions >> >> but that's not what's happening. you'll see urllib.urlopen raising >> exceptions and only afterwards realize that you called into some third >> party library code that decided to change the timeout. > > What is stopping some some third party library code from calling > socket.settimeout(0.1)? Nothing. That's the point. You just wonder why urlopen fails when the global timeout has been changed by that third party library. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 433: Choose the default value of the new cloexec parameter
On Sun, 27 Jan 2013 21:56:06 +0100, Ralf Schmitt wrote: > "R. David Murray" writes: > > > On Sun, 27 Jan 2013 19:42:59 +0100, Ralf Schmitt wrote: > >> Guido van Rossum writes: > >> > >> > It's like calling socket.settimeout(0.1) and then complaining that > >> > urllib.urlopen() raises exceptions > >> > >> but that's not what's happening. you'll see urllib.urlopen raising > >> exceptions and only afterwards realize that you called into some third > >> party library code that decided to change the timeout. > > > > What is stopping some some third party library code from calling > > socket.settimeout(0.1)? > > Nothing. That's the point. You just wonder why urlopen fails when the > global timeout has been changed by that third party library. Oh, you were agreeing with Guido? I guess I misunderstood. --David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Anyone building Python --without-doc-strings?
Why don't you compile using python -OO and distribute only .pyo code? Victor 2013/1/27 Kristján Valur Jónsson : > We (CCP) are certainly compiling python without docstrings for our embedded > platforms (that include the PS3) > Anyone using python as en engine to be used by programs and not users will > appreciate the deletion of unneeded memory. > K > > -Original Message- > From: Python-Dev [mailto:[email protected]] > On Behalf Of R. David Murray > Sent: 27. janúar 2013 00:38 > To: [email protected] > Subject: Re: [Python-Dev] Anyone building Python --without-doc-strings? > > On Sat, 26 Jan 2013 17:19:32 +0100, Antoine Pitrou > wrote: >> On Sat, 26 Jan 2013 17:03:59 +0100 >> Stefan Krah wrote: >> > Stefan Krah wrote: >> > > I'm not sure how accurate the output is for measuring these >> > > things, but according to ``ls'' and ``du'' the option is indeed quite >> > > worthless: >> > > >> > > ./configure CFLAGS="-Os -s" LDFLAGS="-s" && make >> > > 1.8M Jan 26 16:36 python >> > > ./configure --without-doc-strings CFLAGS="-Os -s" LDFLAGS="-s" && make >> > > 1.6M Jan 26 16:33 python >> > >> > The original contribution *was* in fact aiming for "10% smaller", see: >> > >> > http://docs.python.org/release/2.3/whatsnew/node20.html >> > >> > So apparently people thought it was useful. >> >> After a bit of digging, I found the following discussions: >> http://mail.python.org/pipermail/python-dev/2001-November/018444.html >> http://mail.python.org/pipermail/python-dev/2002-January/019392.html >> http://bugs.python.org/issue505375 >> >> Another reason for accepting the patch seemed to be that it introduced >> the Py_DOCSTR() macros, which were viewed as helpful for other reasons >> (some people talked about localizing docstrings). >> >> I would point out that if 200 KB is really a big win for someone, then >> Python (and especially Python 3) is probably not the best language for >> them. >> >> It is also ironic how the executable size went up since then (from 0.6 >> to more than 1.5 MB) :-) > > 200K can make a difference. It does on the QNX platform, for example, where > there is no virtual memory. It would be nice to reduce that executable size, > toobut I'm not volunteering to try (at least not > yet) :) > > --David > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Anyone building Python --without-doc-strings?
On Sun, Jan 27, 2013 at 4:58 PM, Victor Stinner wrote: > Why don't you compile using python -OO and distribute only .pyo code? > Because .pyo files can be much larger than necessary, e.g. using my mnfy project on decimal (with --safe-transforms) compared to -OO yields:: 224K Lib/decimal.py 200K Lib/__pycache__/decimal.cpython-34.pyc 120K Lib/__pycache__/decimal.cpython-34.pyo 80K decimal-mnfy.py And before you ask, the bytecode is still larger on the minified source. So if you truly want to shrink your binary plus overall memory usage footprint you want to go beyond -OO sometimes (although it is a cheap, fast way to save if you are not explicitly striving to eek out every byte). -Brett -Brett > > Victor > > 2013/1/27 Kristján Valur Jónsson : > > We (CCP) are certainly compiling python without docstrings for our > embedded platforms (that include the PS3) > > Anyone using python as en engine to be used by programs and not users > will appreciate the deletion of unneeded memory. > > K > > > > -Original Message- > > From: Python-Dev [mailto:python-dev-bounces+kristjan= > [email protected]] On Behalf Of R. David Murray > > Sent: 27. janúar 2013 00:38 > > To: [email protected] > > Subject: Re: [Python-Dev] Anyone building Python --without-doc-strings? > > > > On Sat, 26 Jan 2013 17:19:32 +0100, Antoine Pitrou > wrote: > >> On Sat, 26 Jan 2013 17:03:59 +0100 > >> Stefan Krah wrote: > >> > Stefan Krah wrote: > >> > > I'm not sure how accurate the output is for measuring these > >> > > things, but according to ``ls'' and ``du'' the option is indeed > quite worthless: > >> > > > >> > > ./configure CFLAGS="-Os -s" LDFLAGS="-s" && make > >> > > 1.8M Jan 26 16:36 python > >> > > ./configure --without-doc-strings CFLAGS="-Os -s" LDFLAGS="-s" && > make > >> > > 1.6M Jan 26 16:33 python > >> > > >> > The original contribution *was* in fact aiming for "10% smaller", see: > >> > > >> > http://docs.python.org/release/2.3/whatsnew/node20.html > >> > > >> > So apparently people thought it was useful. > >> > >> After a bit of digging, I found the following discussions: > >> http://mail.python.org/pipermail/python-dev/2001-November/018444.html > >> http://mail.python.org/pipermail/python-dev/2002-January/019392.html > >> http://bugs.python.org/issue505375 > >> > >> Another reason for accepting the patch seemed to be that it introduced > >> the Py_DOCSTR() macros, which were viewed as helpful for other reasons > >> (some people talked about localizing docstrings). > >> > >> I would point out that if 200 KB is really a big win for someone, then > >> Python (and especially Python 3) is probably not the best language for > >> them. > >> > >> It is also ironic how the executable size went up since then (from 0.6 > >> to more than 1.5 MB) :-) > > > > 200K can make a difference. It does on the QNX platform, for example, > where there is no virtual memory. It would be nice to reduce that > executable size, toobut I'm not volunteering to try (at least not > > yet) :) > > > > --David > > ___ > > Python-Dev mailing list > > [email protected] > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com > > > > > > ___ > > Python-Dev mailing list > > [email protected] > > http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/victor.stinner%40gmail.com > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
