Re: [Python-Dev] Does trunk still support any compilers that *don't* allow declaring variables after code?
On 02.05.2012 15:37, Matt Joiner wrote: On May 2, 2012 6:00 PM, Antoine Pitrou solip...@pitrou.net mailto:solip...@pitrou.net wrote: On Wed, 02 May 2012 01:43:32 -0700 Larry Hastings la...@hastings.org mailto:la...@hastings.org wrote: I realize we can't jump to C99 because of A Certain Compiler. (Its name rhymes with Bike Row Soft Frizz You All See Muss Muss.) But even that compiler added this extension in the early 90s. Do we officially support any C compilers that *don't* permit intermingled variable declarations and code? Do we *unofficially* support any? And if we do, what do we gain? Well, there's this one called MSVC, which we support quite officially. Not sure if comic genius or can't rhyme. This rhyming non-sense is surely above the English abilities of many of us foreigners. I had to read Larry's text five times (two times after you indicated that it indeed ought to rhyme - it finally worked when I read it aloud). So, folks: if you want to be understood, please keep the obfuscation of the English language to a fairly low level. 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] Does trunk still support any compilers that *don't* allow declaring variables after code?
I realize we can't jump to C99 because of A Certain Compiler. (Its name rhymes with Bike Row Soft Frizz You All See Muss Muss.) But even that compiler added this extension in the early 90s. No, it didn't. The MSVC version that we currently use (VS 2008) still doesn't support it. 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] [RELEASED] Python 3.3.0 alpha 3
The What's New document also starts with a long list of PEPs. This seems to be the standard format as What's New for 3.2 follows the same layout. Perhaps adding an overview or highlights at the start would be a good idea. You seem to assume that Python users are not able to grasp long itemized lists including numbers. I think readers are very capable of filtering this kind of information. As for presenting highlights: the PEPs *are* the highlights of a new release. The numerous bug fixes and minor enhancements don't get listed at all. 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] [RELEASED] Python 3.3.0 alpha 3
Martin v. Löwis wrote: The What's New document also starts with a long list of PEPs. This seems to be the standard format as What's New for 3.2 follows the same layout. Perhaps adding an overview or highlights at the start would be a good idea. You seem to assume that Python users are not able to grasp long itemized lists including numbers. I think readers are very capable of filtering this kind of information. Just because readers are capable of filtering a long list of PEPs in an arbitrary order does not mean that they should have to. Many readers will just skim the list, but would probably read a summary in full. As for presenting highlights: the PEPs *are* the highlights of a new release. The numerous bug fixes and minor enhancements don't get listed at all. But PEPs can have very different purposes. It would be useful to summarize the language changes (with links to the relevant PEPs) separately to library extensions and optimizations. If the reader is interested in new features, then information about optimisations are just clutter. And vice-versa. Cheers, Mark. ___ 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] [RELEASED] Python 3.3.0 alpha 3
Any such summary prose will be written by the What's New author (Raymond Hettinger for the 3.x series). Such text definitely *won't* be written until after feature freeze (which occurs with the first beta, currently planned for late June). Until that time, the draft What's New is primarily rough notes written by everyone else for Raymond's benefit (and, of course, for the benefit of anyone checking out the alpha and beta releases). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] [RELEASED] Python 3.3.0 alpha 3
On 05/07/2012 11:00 AM, Mark Shannon wrote: Martin v. Löwis wrote: The What's New document also starts with a long list of PEPs. This seems to be the standard format as What's New for 3.2 follows the same layout. Perhaps adding an overview or highlights at the start would be a good idea. You seem to assume that Python users are not able to grasp long itemized lists including numbers. I think readers are very capable of filtering this kind of information. Just because readers are capable of filtering a long list of PEPs in an arbitrary order does not mean that they should have to. Many readers will just skim the list, but would probably read a summary in full. As for presenting highlights: the PEPs *are* the highlights of a new release. The numerous bug fixes and minor enhancements don't get listed at all. But PEPs can have very different purposes. It would be useful to summarize the language changes (with links to the relevant PEPs) separately to library extensions and optimizations. If the reader is interested in new features, then information about optimisations are just clutter. And vice-versa. Sorry, I think that's tough luck then. The list isn't nearly long enough to warrant splitting up. The announcement should stay compact. And as Nick said, the What's New will be there for those who want a longer overview by topics. 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] PEP 405 (pyvenv) and system Python upgrades
3) Symlink the interpreter rather than copying. I include this here for the sake of completeness, but it's already been rejected due to significant problems on older Windows' and OS X. That sounds the right solution to me. PEP 405 specifies that bin/python3 exists, but not that it is the actual Python interpreter binary that is normally used. For each target system, a solution should be defined that allows in-place updates of Python that also update all venvs automatically. For example, for Windows, it would be sufficient to just have the executable in bin/, as the update will only affect pythonXY.dll. That executable may be different from the regular python.exe, and it might be necessary that it locates its Python installation first. For Unix, symlinks sound fine. Not sure what the issue with OS X is. 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
[Python-Dev] Adding types.build_class for 3.3
A while back I pointed out that there's no easy PEP 3115 compliant way to dynamically create a class (finding the right metaclass, calling __prepare__, etc). I initially proposed providing this as operator.build_class, and Daniel Urban created a patch that implements that API (http://bugs.python.org/issue14588). However, in starting to write the documentation for the new API, I realised that the operator module really isn't the right home for the functionality. Instead, I'm now thinking we should add a _types C extension module and expose the new function as types.build_class(). I don't want to add an entire new module just for this feature, and the types module seems like an appropriate home for it. Thoughts? Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] PEP 405 (pyvenv) and system Python upgrades
On 7 May, 2012, at 11:52, Martin v. Löwis wrote: 3) Symlink the interpreter rather than copying. I include this here for the sake of completeness, but it's already been rejected due to significant problems on older Windows' and OS X. That sounds the right solution to me. PEP 405 specifies that bin/python3 exists, but not that it is the actual Python interpreter binary that is normally used. For each target system, a solution should be defined that allows in-place updates of Python that also update all venvs automatically. For example, for Windows, it would be sufficient to just have the executable in bin/, as the update will only affect pythonXY.dll. That executable may be different from the regular python.exe, and it might be necessary that it locates its Python installation first. For Unix, symlinks sound fine. Not sure what the issue with OS X is. The bin/python3 executable in a framework is a small stub that execv's the real interpreter that is stuffed in a Python.app bundle inside the Python framework. That's done to ensure that GUI code can work from the command-line, Apple's GUI framework refuse to work when the executable is not in an application bundle. Because of this trick pyvenv won't know which executable the user actually called and hence cannot find the pyvenv configuration file (which is next to the stub executable). Ronald smime.p7s Description: S/MIME cryptographic signature ___ 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] [Python-checkins] cpython: Issue #14716: Change integer overflow check in unicode_writer_prepare()
On Mon, May 7, 2012 at 12:08 PM, victor.stinner
python-check...@python.org wrote:
http://hg.python.org/cpython/rev/ab500b297900
changeset: 76821:ab500b297900
user: Victor Stinner victor.stin...@gmail.com
date: Mon May 07 13:02:44 2012 +0200
summary:
Issue #14716: Change integer overflow check in unicode_writer_prepare()
to compute the limit at compile time instead of runtime. Patch writen by
Serhiy
Storchaka.
if (newlen PyUnicode_GET_LENGTH(writer-buffer)) {
- /* overallocate 25% to limit the number of resize */
- if (newlen = (PY_SSIZE_T_MAX - newlen / 4))
+ /* Overallocate 25% to limit the number of resize.
+ Check for integer overflow:
+ (newlen + newlen / 4) = PY_SSIZE_T_MAX */
+ if (newlen = (PY_SSIZE_T_MAX - PY_SSIZE_T_MAX / 5))
newlen += newlen / 4;
Hmm. Very clever, but it's not obvious that that overflow check is
mathematically sound. As it turns out, the maths works provided that
PY_SSIZE_T_MAX isn't congruent to 4 modulo 5; since PY_SSIZE_T_MAX
will almost always be one less than a power of 2 and powers of 2 are
always congruent to 1, 2 or 4 modulo 5, we're safe.
Is the gain from this kind of micro-optimization really worth the cost
of replacing obviously correct code with code whose correctness needs
several minutes of thought?
Mark
___
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] Adding types.build_class for 3.3
On 05/07/2012 01:10 PM, Nick Coghlan wrote: A while back I pointed out that there's no easy PEP 3115 compliant way to dynamically create a class (finding the right metaclass, calling __prepare__, etc). I initially proposed providing this as operator.build_class, and Daniel Urban created a patch that implements that API (http://bugs.python.org/issue14588). However, in starting to write the documentation for the new API, I realised that the operator module really isn't the right home for the functionality. Instead, I'm now thinking we should add a _types C extension module and expose the new function as types.build_class(). I don't want to add an entire new module just for this feature, and the types module seems like an appropriate home for it. Yay for being able to get rid of the stupidities the types module goes through to get at its types (i.e. if we start having a C module, the whole contents can go there.) As for build_class: at the moment the types module really only has types, and to add build_class there is just about as weird as in operator IMO. cheers, 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] Adding types.build_class for 3.3
2012/5/7 Nick Coghlan ncogh...@gmail.com: A while back I pointed out that there's no easy PEP 3115 compliant way to dynamically create a class (finding the right metaclass, calling __prepare__, etc). I initially proposed providing this as operator.build_class, and Daniel Urban created a patch that implements that API (http://bugs.python.org/issue14588). However, in starting to write the documentation for the new API, I realised that the operator module really isn't the right home for the functionality. Instead, I'm now thinking we should add a _types C extension module and expose the new function as types.build_class(). I don't want to add an entire new module just for this feature, and the types module seems like an appropriate home for it. Actually, there used to be a _types C module before we figured out that all the types could be extracted in Python. :) Maybe you could make it a static or class method of type? -- Regards, Benjamin ___ 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] [Python-checkins] cpython: Issue #14716: Change integer overflow check in unicode_writer_prepare()
On Mon, May 7, 2012 at 12:35 PM, Mark Dickinson dicki...@gmail.com wrote: will almost always be one less than a power of 2 and powers of 2 are always congruent to 1, 2 or 4 modulo 5, we're safe. Bah. That should have read 1, 2, 3 or 4 modulo 5. ___ 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] Adding types.build_class for 3.3
On Mon, May 7, 2012 at 9:54 PM, Georg Brandl g.bra...@gmx.net wrote: As for build_class: at the moment the types module really only has types, and to add build_class there is just about as weird as in operator IMO. Oh no, types is definitely less weird - at least it's related to the type system, whereas the operator module is about operator syntax (attrgetter, itemgetter and index are at least related to the dot operator and subscripting syntax) Benjamin's suggestion of a class method on type may be a good one, though. Then the invocation (using all arguments) would be: mcl.build_class(name, bases, keywords, exec_body) Works for me, so unless someone else can see a problem I've missed, we'll go with that. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] Adding types.build_class for 3.3
On 05/07/2012 02:15 PM, Nick Coghlan wrote: On Mon, May 7, 2012 at 9:54 PM, Georg Brandl g.bra...@gmx.net wrote: As for build_class: at the moment the types module really only has types, and to add build_class there is just about as weird as in operator IMO. Oh no, types is definitely less weird - at least it's related to the type system, whereas the operator module is about operator syntax (attrgetter, itemgetter and index are at least related to the dot operator and subscripting syntax) Benjamin's suggestion of a class method on type may be a good one, though. Then the invocation (using all arguments) would be: mcl.build_class(name, bases, keywords, exec_body) Works for me, so unless someone else can see a problem I've missed, we'll go with that. Works for me. 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] Adding types.build_class for 3.3
On 05/07/2012 02:15 PM, Nick Coghlan wrote: Benjamin's suggestion of a class method on type may be a good one, though. Then the invocation (using all arguments) would be: mcl.build_class(name, bases, keywords, exec_body) Works for me, so unless someone else can see a problem I've missed, we'll go with that. Note that to call mcl.build_class, you have to find a metaclass that works for bases, which is the job of build_class. Putting it as a function in the operator module seems like a better solution. ___ 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] PEP 405 (pyvenv) and system Python upgrades
On 05/07/2012 04:26 AM, Ronald Oussoren wrote: On 7 May, 2012, at 11:52, Martin v. Löwis wrote: 3) Symlink the interpreter rather than copying. I include this here for the sake of completeness, but it's already been rejected due to significant problems on older Windows' and OS X. That sounds the right solution to me. PEP 405 specifies that bin/python3 exists, but not that it is the actual Python interpreter binary that is normally used. For each target system, a solution should be defined that allows in-place updates of Python that also update all venvs automatically. For example, for Windows, it would be sufficient to just have the executable in bin/, as the update will only affect pythonXY.dll. That executable may be different from the regular python.exe, and it might be necessary that it locates its Python installation first. For Unix, symlinks sound fine. Not sure what the issue with OS X is. The bin/python3 executable in a framework is a small stub that execv's the real interpreter that is stuffed in a Python.app bundle inside the Python framework. That's done to ensure that GUI code can work from the command-line, Apple's GUI framework refuse to work when the executable is not in an application bundle. Because of this trick pyvenv won't know which executable the user actually called and hence cannot find the pyvenv configuration file (which is next to the stub executable). It occurs to me, belatedly, that this also means that upgrades should be a non-issue with OS X framework builds (presuming the upgraded actual-Python-binary gets placed in the same location, and the previously copied stub will still exec it without trouble), in which case we can symlink on OS X non-framework builds and copy on OS X framework builds and be happy. Carl ___ 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] [Python-checkins] cpython: Issue #14716: Change integer overflow check in unicode_writer_prepare()
07.05.12 14:35, Mark Dickinson написав(ла): Hmm. Very clever, but it's not obvious that that overflow check is mathematically sound. My fault. Overflow will be at PY_SSIZE_T_MAX congruent to 4 modulo 5 (which is impossible if PY_SSIZE_T_MAX is one less than a power of 2). Mathematically strict limit must be (PY_SSIZE_T_MAX - 1 - (PY_SSIZE_T_MAX - 4) / 5). ___ 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] [Python-checkins] cpython: Issue #14716: Change integer overflow check in unicode_writer_prepare()
07.05.12 18:48, Serhiy Storchaka написав(ла): My fault. However, it's not my fault. I suggested `newlen (PY_SSIZE_T_MAX - PY_SSIZE_T_MAX / 5)` and not `newlen = (PY_SSIZE_T_MAX - PY_SSIZE_T_MAX / 5)`. In this case, there is no overflow. ___ 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] PEP 405 (pyvenv) and system Python upgrades
On 05/07/2012 03:52 AM, Martin v. Löwis wrote: 3) Symlink the interpreter rather than copying. I include this here for the sake of completeness, but it's already been rejected due to significant problems on older Windows' and OS X. That sounds the right solution to me. PEP 405 specifies that bin/python3 exists, but not that it is the actual Python interpreter binary that is normally used. For each target system, a solution should be defined that allows in-place updates of Python that also update all venvs automatically. I propose that for Windows, that solution is to have a new enough version of Windows and the necessary privileges, and use the --symlink option to the pyvenv script, or else to manually update venvs using pyvenv --upgrade. For example, for Windows, it would be sufficient to just have the executable in bin/, as the update will only affect pythonXY.dll. That executable may be different from the regular python.exe, and it might be necessary that it locates its Python installation first. This sounds to me like a level of complexity unwarranted by the severity of the problem, especially when considering the additional burden it imposes on alternative Python implementations. Carl ___ 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] [Python-checkins] cpython: Issue #14716: Change integer overflow check in unicode_writer_prepare()
On Mon, 7 May 2012 12:35:27 +0100 Mark Dickinson dicki...@gmail.com wrote: Hmm. Very clever, but it's not obvious that that overflow check is mathematically sound. As it turns out, the maths works provided that PY_SSIZE_T_MAX isn't congruent to 4 modulo 5; since PY_SSIZE_T_MAX will almost always be one less than a power of 2 and powers of 2 are always congruent to 1, 2 or 4 modulo 5, we're safe. Is the gain from this kind of micro-optimization really worth the cost of replacing obviously correct code with code whose correctness needs several minutes of thought? Agreed that the original code is good enough. Dividing by 4 is fast, and this particular line of code is followed by a memory reallocation. In general, clever micro-optimizations that don't produce significant performance improvements should be avoided, IMHO :-) Regards Antoine. ___ 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] Assigning copyright...
Hello, http://www.python.org/psf/contrib/ I took care of the formalities. I am not sure how to proceed further. Would python-dev want me to draft a PEP? Regards, --stefan PS: Personally, I am not a 100pct convinced that having a PEP is a good thing in this case, as it makes a perfectly transparent optimization visible. AFAIR Sun opted to keep their instruction derivatives secret, i.e., the second edition of the JVM internals does not even mention them anymore. ___ 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
[Python-Dev] Point of building without threads?
Hello, I guess a long time ago, threading support in operating systems wasn't very widespread, but these days all our supported platforms have it. Is it still useful for production purposes to configure --without-threads? Do people use this option for something else than curiosity of mind? Regards Antoine. ___ 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] Assigning copyright...
On 05/07/2012 09:23 PM, stefan brunthaler wrote: Hello, http://www.python.org/psf/contrib/ I took care of the formalities. I am not sure how to proceed further. Would python-dev want me to draft a PEP? Regards, --stefan PS: Personally, I am not a 100pct convinced that having a PEP is a good thing in this case, as it makes a perfectly transparent optimization visible. AFAIR Sun opted to keep their instruction derivatives secret, i.e., the second edition of the JVM internals does not even mention them anymore. I think you'll find that we don't keep a lot of things secret about CPython and its implementation. Although this is different when it comes to the community. The PSU has ___ 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
[Python-Dev] Python 3.3 cannot find BeautifulSoup but Python 3.2 can
I use up-to-date Debian testing (wheezy), amd64 architecture. I compiled and installed Python 3.3.0 alpha 3 using altinstall. Debian wheezy comes with python3.2 (and 2.6 and 2.7). I installed the Debian package python3-bs4 (BeautifulSoup). I also downloaded a clone developmental copy of 3.3. Python3.3a3 cannot find module bs4. Neither can the clone. Python3.2 can find the module. Here is a session with the clone: ./python Python 3.3.0a3+ (default:10ccbb90a8e9, May 6 2012, 19:11:02) [GCC 4.6.3] on linux Type help, copyright, credits or license for more information. import bs4 Traceback (most recent call last): File stdin, line 1, in module File frozen importlib._bootstrap, line 974, in _find_and_load ImportError: No module named 'bs4' [71413 refs] What is the problem? ___ 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] PEP 405 (pyvenv) and system Python upgrades
The bin/python3 executable in a framework is a small stub that execv's the real interpreter that is stuffed in a Python.app bundle inside the Python framework. That's done to ensure that GUI code can work from the command-line, Apple's GUI framework refuse to work when the executable is not in an application bundle. Because of this trick pyvenv won't know which executable the user actually called and hence cannot find the pyvenv configuration file (which is next to the stub executable). I don't understand. The executable that the user actually called: does that refer to a) the stub (which the user *actually* called) or b) the eventual binary (which is what gets *actually* run). If a), then I think argv[0] just needs to continue to refer to the stub, which is easy to achieve in execv. If b), I wonder why the code needs to know the location to the binary inside the bundle. But if this is needed to know, I suggest that some environment variable is passed from the stub to the actual binary (akin PYTHONHOME). How does the stub normally find out where the framework is located? 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
[Python-Dev] Python 3.3 cannot import BeautifulSoup but Python 3.2 can
I use up-to-date Debian testing (wheezy), amd64 architecture. I compiled and installed Python 3.3.0 alpha 3 using altinstall. Debian wheezy comes with python3.2 (and 2.6 and 2.7). I installed the Debian package python3-bs4 (BeautifulSoup4 for Python3). I also downloaded a clone developmental copy of 3.3. Python3.3a3 cannot find module bs4. Neither can the clone. Python3.2 can find the module. Here is a session with the clone: ./python Python 3.3.0a3+ (default:10ccbb90a8e9, May 6 2012, 19:11:02) [GCC 4.6.3] on linux Type help, copyright, credits or license for more information. import bs4 Traceback (most recent call last): File stdin, line 1, in module File frozen importlib._bootstrap, line 974, in _find_and_load ImportError: No module named 'bs4' [71413 refs] What is the problem? ___ 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] PEP 405 (pyvenv) and system Python upgrades
On 07.05.2012 18:35, Carl Meyer wrote: On 05/07/2012 03:52 AM, Martin v. Löwis wrote: 3) Symlink the interpreter rather than copying. I include this here for the sake of completeness, but it's already been rejected due to significant problems on older Windows' and OS X. That sounds the right solution to me. PEP 405 specifies that bin/python3 exists, but not that it is the actual Python interpreter binary that is normally used. For each target system, a solution should be defined that allows in-place updates of Python that also update all venvs automatically. I propose that for Windows, that solution is to have a new enough version of Windows and the necessary privileges, and use the --symlink option to the pyvenv script, or else to manually update venvs using pyvenv --upgrade. Sounds fine to me as well. For example, for Windows, it would be sufficient to just have the executable in bin/, as the update will only affect pythonXY.dll. That executable may be different from the regular python.exe, and it might be necessary that it locates its Python installation first. This sounds to me like a level of complexity unwarranted by the severity of the problem, especially when considering the additional burden it imposes on alternative Python implementations. OTOH, it *significantly* reduces the burden on Python end users, for whom creation of a venv under a privileged account is a significant hassle. This being free software, anybody needs to scratch her own itches, of course. 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] Assigning copyright...
On 07.05.2012 21:23, stefan brunthaler wrote: Hello, http://www.python.org/psf/contrib/ I took care of the formalities. I am not sure how to proceed further. Would python-dev want me to draft a PEP? Submit a patch to the bug tracker, against default's head. 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] Python 3.3 cannot import BeautifulSoup but Python 3.2 can
Hello, On Mon, 07 May 2012 16:42:50 -0400 Edward C. Jones edcjo...@comcast.net wrote: I use up-to-date Debian testing (wheezy), amd64 architecture. I compiled and installed Python 3.3.0 alpha 3 using altinstall. Debian wheezy comes with python3.2 (and 2.6 and 2.7). I installed the Debian package python3-bs4 (BeautifulSoup4 for Python3). I also downloaded a clone developmental copy of 3.3. Python3.3a3 cannot find module bs4. Neither can the clone. Python3.2 can find the module. Here is a session with the clone: python-dev is for development *of* Python. For general Python questions, you should ask on python-list: http://mail.python.org/mailman/listinfo/python-list (quick answer: you must install BeautifulSoup specifically for your compiled interpreter. Python does not share libraries accross different interpreter versions) Regards Antoine. ___ 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] Python 3.3 cannot import BeautifulSoup but Python 3.2 can
On Mon, May 07, 2012 at 04:42:50PM -0400, Edward C. Jones edcjo...@comcast.net wrote: I use up-to-date Debian testing (wheezy), amd64 architecture. I compiled and installed Python 3.3.0 alpha 3 using altinstall. Debian wheezy comes with python3.2 (and 2.6 and 2.7). I installed the Debian package python3-bs4 (BeautifulSoup4 for Python3). I also downloaded a clone developmental copy of 3.3. Python3.3a3 cannot find module bs4. Could it be bs4 is installed in python3.2-specific path and hence it's not in python3.3 sys.path? Oleg. -- Oleg Broytmanhttp://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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] PEP 405 (pyvenv) and system Python upgrades
Ronald Oussoren ronaldoussoren at mac.com writes: Because of this trick pyvenv won't know which executable the user actually called and hence cannot find the pyvenv configuration file (which is next to the stub executable). Ah, but the stub has been changed to set an environment variable, __PYTHONV_LAUNCHER__, which points to itself, before it execs the real Python. On OS X, Python code checks for this, rather than sys.executable, to determine the location of the pyvenv.cfg file. This seems to work for me (Ned Deily is looking into it more closely, I believe). Regards, Vinay Sajip ___ 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] Python 3.3 cannot import BeautifulSoup but Python 3.2 can
On May 07, 2012, at 04:42 PM, Edward C. Jones wrote: I use up-to-date Debian testing (wheezy), amd64 architecture. I compiled and installed Python 3.3.0 alpha 3 using altinstall. Debian wheezy comes with python3.2 (and 2.6 and 2.7). I installed the Debian package python3-bs4 (BeautifulSoup4 for Python3). I also downloaded a clone developmental copy of 3.3. Python3.3a3 cannot find module bs4. Neither can the clone. Python3.2 can find the module. Here is a session with the clone: Remember that Debian installs its system packages into dist-packages not site-packages. This is a Debian delta from upstream. http://wiki.debian.org/Python Cheers, -Barry ___ 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] Assigning copyright...
I think you'll find that we don't keep a lot of things secret about CPython and its implementation. Yeah, I agree that this is in principal a good thing and what makes CPython ideally suited for research. However, my optimizations make use of unused opcodes, which might be used in the future by actual CPython instructions (e.g., from my previous patch to the new one the YIELD_FROM instruction has been added.) I'd say the situation is similar to the threaded code/computed goto's issue. Although this is different when it comes to the community. The PSU has ? I am going to file a patch like Martin von Loewis suggested. Thanks, --stefan ___ 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] [Python-checkins] cpython: Issue #14716: Change integer overflow check in unicode_writer_prepare()
However, it's not my fault. I suggested `newlen (PY_SSIZE_T_MAX - PY_SSIZE_T_MAX / 5)` and not `newlen = (PY_SSIZE_T_MAX - PY_SSIZE_T_MAX / 5)`. In this case, there is no overflow. Oh. I didn't understand why you replaced = by , and so I used =. Anyway, I reverted the change for all reasons listed in this thread. Victor ___ 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] PEP 405 (pyvenv) and system Python upgrades
On 7 May 2012 21:55, Martin v. Löwis mar...@v.loewis.de wrote: This sounds to me like a level of complexity unwarranted by the severity of the problem, especially when considering the additional burden it imposes on alternative Python implementations. OTOH, it *significantly* reduces the burden on Python end users, for whom creation of a venv under a privileged account is a significant hassle. Personally, I would find a venv which required being run as an admin account to be essentially unusable on Windows (particularly Windows 7, where this means creating venvs in an elevated console window). Allowing for symlinks as an option is fine, I guess, but I'd be -1 on it being the default. Paul. ___ 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] Point of building without threads?
I guess a long time ago, threading support in operating systems wasn't very widespread, but these days all our supported platforms have it. Is it still useful for production purposes to configure --without-threads? Do people use this option for something else than curiosity of mind? At work, I'm working on embedded systems (television set top boxes) with a Linux kernel with the GNU C library, and we do use threads! I'm not sure that Python runs on slower/smaller systems because they have other constrains like having very few memory, maybe no MMU and not using the glibc but µlibc for example. There is the python-on-a-chip project. It is written from scratch and is very different from CPython. I don't think that it uses threads. http://code.google.com/p/python-on-a-chip/ Victor ___ 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] Adding types.build_class for 3.3
Nick Coghlan wrote: Instead, I'm now thinking we should add a _types C extension module and expose the new function as types.build_class(). I don't want to add an entire new module just for this feature, and the types module seems like an appropriate home for it. Dunno. Currently the only thing the types module contains is types. A function would seem a bit out of place there. I don't think there's too much wrong with putting it in the operators module -- it's a function doing something that is otherwise expressed by special syntax. -- Greg ___ 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] [Python-checkins] cpython: Issue #14716: Change integer overflow check in unicode_writer_prepare()
Mark Dickinson wrote: Is the gain from this kind of micro-optimization really worth the cost of replacing obviously correct code with code whose correctness needs several minutes of thought? The original code isn't all that obviously correct to me either. I would need convincing that the arithmetic being used to check for overflow can't itself suffer from overflow. At least that much is obvious from the new version. -- Greg ___ 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] Adding types.build_class for 3.3
For those suggesting the operator module is actually a good choice, there's no way to add this function without making major changes to the module description (go read it - I only realised the problem when I went to add the docs). It's a bad fit (*much* worse than types or a class method) -- Sent from my phone, thus the relative brevity :) On May 8, 2012 9:01 AM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: Nick Coghlan wrote: Instead, I'm now thinking we should add a _types C extension module and expose the new function as types.build_class(). I don't want to add an entire new module just for this feature, and the types module seems like an appropriate home for it. Dunno. Currently the only thing the types module contains is types. A function would seem a bit out of place there. I don't think there's too much wrong with putting it in the operators module -- it's a function doing something that is otherwise expressed by special syntax. -- Greg __**_ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/**mailman/listinfo/python-devhttp://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/**mailman/options/python-dev/** ncoghlan%40gmail.comhttp://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ 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] Adding types.build_class for 3.3
On Mon, May 7, 2012 at 6:15 AM, Nick Coghlan ncogh...@gmail.com wrote: On Mon, May 7, 2012 at 9:54 PM, Georg Brandl g.bra...@gmx.net wrote: As for build_class: at the moment the types module really only has types, and to add build_class there is just about as weird as in operator IMO. Oh no, types is definitely less weird - at least it's related to the type system, whereas the operator module is about operator syntax (attrgetter, itemgetter and index are at least related to the dot operator and subscripting syntax) Benjamin's suggestion of a class method on type may be a good one, though. Then the invocation (using all arguments) would be: mcl.build_class(name, bases, keywords, exec_body) Works for me, so unless someone else can see a problem I've missed, we'll go with that. +1 -eric ___ 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] Adding types.build_class for 3.3
On Mon, May 7, 2012 at 11:42 PM, Hrvoje Niksic hrvoje.nik...@avl.com wrote: On 05/07/2012 02:15 PM, Nick Coghlan wrote: Benjamin's suggestion of a class method on type may be a good one, though. Then the invocation (using all arguments) would be: mcl.build_class(name, bases, keywords, exec_body) Works for me, so unless someone else can see a problem I've missed, we'll go with that. Note that to call mcl.build_class, you have to find a metaclass that works for bases, which is the job of build_class. Putting it as a function in the operator module seems like a better solution. No, the mcl in the call is just the designated metaclass - the *actual* metaclass of the resulting class definition may be something different. That's why this is a separate method from mcl.__new__. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
[Python-Dev] Spread Python
Python Freakz .., Anyone of you interested to write a series of article regarding the great python language ?..The series must be including a brief of python history, applications , advantages, related topics and tutorials etc ...I hope it will be a great experience for you to share,learn and spread python for all.The article will be published in www.texplod.com. If any one interested please send me a private message -- *Regards* * * Cre@tivmindz www.texplod.com ra ___ 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
[Python-Dev] Spread Python
Python Freakz .., Anyone of you interested to write a series of article regarding the great python language ?..The series must be including a brief of python history, applications , advantages, related topics and tutorials etc ...I hope it will be a great experience for you to share,learn and spread python for all.The article will be published in www.texplod.com. If any one interested please send me a private message -- *Regards* * * Cre@tivmindz www.texplod.com ra -- *Regards* * * Cre@tivmindz www.texplod.com ___ 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
