[issue13156] _PyGILState_Reinit assumes auto thread state will always exist which is not true.
New submission from Graham Dumpleton graham.dumple...@gmail.com:
This is a followup bug report to fix wrong implementation of
_PyGILState_Reinit() introduced by http://bugs.python.org/issue10517.
I don't have a standalone test case yet. Problem occurs under mod_wsgi with
Python 2.7.2 and thus similarly 3.2 where _PyGILState_Reinit() was also added.
The Python code part which triggers the problem is:
pid = os.fork()
if pid:
sys.stderr.write('Fork succeeded (PID=%s)\n' % pid)
else:
sys.stderr.write('Fork succeeded (child PID=%s)\n' % os.getpid())
time.sleep(60.0)
os._exit(0)
To trigger the problem requires this code be executed from a thread originally
created outside of Python and then calling into a sub interpreter.
This thread would have created its own thread state object for the sub
interpreter call since auto thread states don't work for sub interpreters.
Further, it would never have called into the main interpreter so auto thread
state simply doesn't exist for main interpreter.
When this thread has a fork() occur and _PyGILState_Reinit() is called, the
call of PyGILState_GetThisThreadState() returns NULL because auto thread state
for main interpreter was never initialised for this thread. When it then calls
into PyThread_set_key_value() it is value of NULL and rather than set it, it
thinks internally in find_key() you are doing a get which results in
PyThread_set_key_value() returning -1 and so the fatal error.
So _PyGILState_Reinit() is broken because it assumes that an auto thread state
will always exist for the thread for it to reinit, which will not always be the
case.
The simple fix may be that if PyGILState_GetThisThreadState() returns NULL then
don't do any reinit. Making that change does seem to fix the problem. Code that
works then is:
void
_PyGILState_Reinit(void)
{
PyThreadState *tstate = PyGILState_GetThisThreadState();
if (tstate) {
PyThread_delete_key(autoTLSkey);
if ((autoTLSkey = PyThread_create_key()) == -1)
Py_FatalError(Could not allocate TLS entry);
/* re-associate the current thread state with the new key */
if (PyThread_set_key_value(autoTLSkey, (void *)tstate) 0)
Py_FatalError(Couldn't create autoTLSkey mapping);
}
}
Diff file also attached.
--
components: Extension Modules
files: pystate.c.diff
keywords: patch
messages: 145383
nosy: grahamd, neologix
priority: normal
severity: normal
status: open
title: _PyGILState_Reinit assumes auto thread state will always exist which is
not true.
type: crash
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file23385/pystate.c.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13156
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13156] _PyGILState_Reinit assumes auto thread state will always exist which is not true.
Graham Dumpleton graham.dumple...@gmail.com added the comment: Whoops. Missed the error. The fatal error that occurs is: Fatal Python error: Couldn't create autoTLSkey mapping -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13156 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13156] _PyGILState_Reinit assumes auto thread state will always exist which is not true.
Changes by Charles-François Natali neolo...@free.fr: -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13156 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13156] _PyGILState_Reinit assumes auto thread state will always exist which is not true.
Charles-François Natali neolo...@free.fr added the comment: Note that this doesn't apply to default: the problem is that 2.7 and 3.2 don't use native TLS, and with the ad-hoc TLS implementation, a NULL value isn't supported: /* Internal helper. * If the current thread has a mapping for key, the appropriate struct key* * is returned. NB: value is ignored in this case! * If there is no mapping for key in the current thread, then: * If value is NULL, NULL is returned. * Else a mapping of key to value is created for the current thread, * and a pointer to a new struct key* is returned; except that if * malloc() can't find room for a new struct key*, NULL is returned. * So when value==NULL, this acts like a pure lookup routine, and when * value!=NULL, this acts like dict.setdefault(), returning an existing * mapping if one exists, else creating a new mapping. So PyThread_set_key_value() has different semantics between 2.7/3.2 and default... So _PyGILState_Reinit() is broken because it assumes that an auto thread state will always exist for the thread for it to reinit, which will not always be the case. Hmm... Please see http://docs.python.org/c-api/init.html#non-python-created-threads When threads are created using the dedicated Python APIs (such as the threading module), a thread state is automatically associated to them and the code showed above is therefore correct. However, when threads are created from C (for example by a third-party library with its own thread management), they don’t hold the GIL, nor is there a thread state structure for them. If you need to call Python code from these threads (often this will be part of a callback API provided by the aforementioned third-party library), you must first register these threads with the interpreter by creating a thread state data structure, then acquiring the GIL, and finally storing their thread state pointer, before you can start using the Python/C API. When you are done, you should reset the thread state pointer, release the GIL, and finally free the thread state data structure. The PyGILState_Ensure() and PyGILState_Release() functions do all of the above automatically. The typical idiom for calling into Python from a C thread is: I think you should be calling call PyGILState_Ensure() before (whoch does associate the thread state to the autoTLS key. I let Antoine answer, he's got much more experience than me. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13156 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13156] _PyGILState_Reinit assumes auto thread state will always exist which is not true.
Graham Dumpleton graham.dumple...@gmail.com added the comment: The PyGILState_Ensure() function is only for when working with the main interpreter. These external threads are not calling into the main interpreter. Because they are external threads, calling PyGILState_Ensure() and then PyGILState_Release() will cause a thread state to be created for the main interpreter, but it will also be destroyed on the PyGILState_Release(). The only way to avoid that situation and ensure that the thread state for the main interpreter is therefore maintained would be to call PyGILState_Ensure() and then call PyThreadState_Swap() to change to thread state for the sub interpreter. Problem is that you aren't supposed to use PyThreadState_Swap() any more and recollect that newer Python 3.X even prohibits it in some way through some checks. So, the documentation you quote is only to do with the main interpreter and is not how things work for sub interpreters. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13156 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13156] _PyGILState_Reinit assumes auto thread state will always exist which is not true.
Charles-François Natali neolo...@free.fr added the comment:
So, the documentation you quote is only to do with the main
interpreter and is not how things work for sub interpreters.
You're right, my bad.
However, it would probably be better to destroy/reset the autoTLSkey
even if the current thread doesn't have an associated TLS key (to
avoid stumbling upon the original libc bug of issue #10517):
void
_PyGILState_Reinit(void)
{
PyThreadState *tstate = PyGILState_GetThisThreadState();
PyThread_delete_key(autoTLSkey);
if ((autoTLSkey = PyThread_create_key()) == -1)
Py_FatalError(Could not allocate TLS entry);
/* re-associate the current thread state with the new key */
if (tstate PyThread_set_key_value(autoTLSkey, (void *)tstate) 0)
Py_FatalError(Couldn't create autoTLSkey mapping);
}
Now that i think about it, the problem is even simpler: this patch
shouldn't have been applied to 2.7 and 3.2, it was only relevant for
native pthread TLS implementation (which does allow NULL values).
So the solution would be simply to backout this patch on 2.7 and 3.2.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13156
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13156] _PyGILState_Reinit assumes auto thread state will always exist which is not true.
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13156 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13156] _PyGILState_Reinit assumes auto thread state will always exist which is not true.
Charles-François Natali neolo...@free.fr added the comment: So the solution would be simply to backout this patch on 2.7 and 3.2. Actually, I just checked, and the native TLS implementation is present in 3.2, so this problem shouldn't show up: did you test it with 3.2? AFAICT, this should only affect 2.7 (for which this patch wasn't relevant). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13156 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13156] _PyGILState_Reinit assumes auto thread state will always exist which is not true.
Graham Dumpleton graham.dumple...@gmail.com added the comment: True. Doesn't appear to be an issue with Python 3.2.2. Only Python 2.7.2. I was not aware that the TLS mechanism was changed in Python 3.X so assumed would also affect it. So, looks like the change shouldn't have been applied to Python 2.7. How many moons before Python 2.7.3 though? -- versions: -Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13156 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4431] Distutils MSVC doesn't create manifest file (with fix)
Sébastien Sablé sa...@users.sourceforge.net added the comment: I got this problem again this morning while compiling pywin32. This problem is not specific to me, anyone using Visual Studio 2010 to compile Python is experiencing the same issue: http://nukeit.org/compile-python-2-7-packages-with-visual-studio-2010-express/ https://bitbucket.org/jaraco/jaraco.develop/src/f6e937d98e7f/jaraco/develop/msvc.py Could you please reopen the issue or should I open a new one? Thanks in advance -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4431 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13156] _PyGILState_Reinit assumes auto thread state will always exist which is not true.
Antoine Pitrou pit...@free.fr added the comment: How many moons before Python 2.7.3 though? If you convince python-dev that's it's a critical bug (is it?) I suppose it could happen soon. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13156 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13157] Build Python outside the source directory
New submission from STINNER Victor victor.stin...@haypocalc.com: It is no more possible to build Python outside its source directory. Try using: cd python sources directory mkdir release cd release ../configure make Attached patch should fix this issue. -- files: build.patch keywords: patch messages: 145392 nosy: haypo, loewis, neologix, pitrou priority: normal severity: normal status: open title: Build Python outside the source directory versions: Python 3.3 Added file: http://bugs.python.org/file23386/build.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13157 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13157] Build Python outside the source directory
Changes by STINNER Victor victor.stin...@haypocalc.com: -- components: +Build ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13157 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13158] tarfile.TarFile.getmembers misses some entries
New submission from Sebastien Binet bi...@cern.ch: hi there, it seems tarfile in python 3.2.2 (as installed in archlinux, but I don't see any additional patch applied on top of the vanilla sources: http://projects.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/python ) has troubles giving the complete content of a tar ball. see: $ wget http://downloads.sourceforge.net/sourceforge/boost/boost_1_44_0.tar.gz $ md5sum boost_1_44_0.tar.gz 085fce4ff2089375105d72475d730e15 boost_1_44_0.tar.gz $ python --version Python 3.2.2 $ python2 --version Python 2.7.2 $ python ./foo.py 8145 $ python2 ./foo.py 33635 where foo.py is: ## import tarfile o = tarfile.open(boost_1_44_0.tar.gz) print( %s % len(o.getmembers())) o.close() ## EOF ## is it a known bug ? (this of course prevents TarFile.extractall to be useful w/ python3...) -s -- messages: 145393 nosy: bins priority: normal severity: normal status: open title: tarfile.TarFile.getmembers misses some entries type: behavior versions: Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13158 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4431] Distutils MSVC doesn't create manifest file (with fix)
David Schnur dnsch...@gmail.com added the comment: I haven't commented since opening this issue, but I've been following along. Regarding Marc-Andre's latest comment, I think whether to embed a manifest or not is a separate issue. The current behavior is to embed a manifest, and so it should ensure that the file is created. As others have said, given that distutils expects /MANIFEST implicitly, there seems no harm in adding it explicitly. I agree that this issue should be re-opened, since it's apparently not restricted just to my case of using /MT. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4431 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8668] Packaging: add a 'develop' command
Changes by higery shoulderhig...@gmail.com: Added file: http://bugs.python.org/file23387/adb2cb19ca9b.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8668 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6807] No such file or directory: 'msisupport.dll' in msi.py
Sébastien Sablé sa...@users.sourceforge.net added the comment: I had the same issue today. The patch solved the problem. Thanks -- nosy: +sable ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6807 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6807] No such file or directory: 'msisupport.dll' in msi.py
Changes by Brian Curtin br...@python.org: -- components: +Windows nosy: +brian.curtin ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6807 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12659] Add tests for packaging.tests.support
Éric Araujo mer...@netwok.org added the comment: Yes, you did. There are a few minor edits I’ll make to the patch, but otherwise this is good to commit. -- assignee: tarek - eric.araujo versions: +3rd party ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12659 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13150] Most of Python's startup time is sysconfig
Éric Araujo mer...@netwok.org added the comment: #9878 should also help with start-up time. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13150 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13150] Most of Python's startup time is sysconfig
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13150 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13150] Most of Python's startup time is sysconfig
Éric Araujo mer...@netwok.org added the comment: Actually, #9878 should supersede this bug: it proposes to generate a C module to avoid parsing Makefile and pyconfig.h, and your patch proposes to generate a Python module with the same goal. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13150 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8668] Packaging: add a 'develop' command
Éric Araujo mer...@netwok.org added the comment: Thanks for the updated patch. There are things that should be removed (for example functions like get_develop_method, given that we only support packaging-based projects), and there are a few things to clean up in the tests. What’s more practical for you, a review or a patch? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8668 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13149] optimization for append-only StringIO
Martin v. Löwis mar...@v.loewis.de added the comment: It would be interesting to see how often the bad case triggers, i.e. that a write-only stringio sees any of the other methods invoked at all. As a special case, you may consider that .truncate(0) doesn't really need to realize the buffer first. I also wonder how much StringIO will be used in praxis, as opposed to BytesIO. -- nosy: +loewis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13149 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12753] \N{...} neglects formal aliases and named sequences from Unicode charnames namespace
Martin v. Löwis mar...@v.loewis.de added the comment: If you don't use git-style diffs, Rietveld will much better accommodate patches that don't apply to tip cleanly. Unfortunately, hg git-style diffs don't indicate the base revision, so Rietveld guesses that the base line is tip, and then fails if it doesn't apply exactly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12753 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13150] Most of Python's startup time is sysconfig
Antoine Pitrou pit...@free.fr added the comment: Actually, #9878 should supersede this bug: it proposes to generate a C module to avoid parsing Makefile and pyconfig.h, and your patch proposes to generate a Python module with the same goal. Well, #9878 doesn't have a patch, but perhaps Barry is willing to work on one. Also, if we have a pure Python solution, perhaps a C module isn't needed. The main advantage of the C solution, though, would be to avoid dubious parsing altogher, even at build time. -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13150 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13159] _io.FileIO uses a quadratic-time buffer growth algorithm
New submission from Nadeem Vawda nadeem.va...@gmail.com:
As mentioned in issue 6715, the buffer growth strategy used by _io.FileIO
has quadratic running time if each reallocation is O(n). The code in
question is new_buffersize() from Modules/_io/fileio.c:
if (currentsize SMALLCHUNK) {
/* Keep doubling until we reach BIGCHUNK;
then keep adding BIGCHUNK. */
if (currentsize = BIGCHUNK)
return currentsize + currentsize;
else
return currentsize + BIGCHUNK;
}
return currentsize + SMALLCHUNK;
Is there a reason for this? One possible improvement would be to instead
use the same formula as list.resize() in Objects/listobject.c:
new_allocated = (newsize 3) + (newsize 9 ? 3 : 6);
which has amortized O(n) running time behaviour.
Your thoughts?
--
components: IO
messages: 145403
nosy: benjamin.peterson, nadeem.vawda, pitrou, stutzbach
priority: normal
severity: normal
stage: needs patch
status: open
title: _io.FileIO uses a quadratic-time buffer growth algorithm
type: performance
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13159
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13149] optimization for append-only StringIO
Antoine Pitrou pit...@free.fr added the comment: Yes, these are things I've been wondering about. The use-case for an append-only StringIO is obviously overlapping with the use-case for using ''.join(). However, the implementation I'm proposing is better than ''.join() when writing very small strings, since there's a periodic consolidation. As a special case, you may consider that .truncate(0) doesn't really need to realize the buffer first. True. Also, seek(0) then read() could use the same optimization. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13149 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Martin v. Löwis mar...@v.loewis.de added the comment: Modules/_lzmamodule.c:364: Py_BEGIN_ALLOW_THREADS It seems that the Windows version at least is not thread-safe. If so, you would need an LZMA lock when releasing the GIL. Does the class need to be thread-safe, though? As a matter of principle, Python code must not be able to crash the interpreter or corrupt memory. There are known bugs in this area, but if it's known in advance that an issue exists, we should avoid it. ISTM that there isn't any sensible use case for having two threads feeding data through the same compressor concurrently. Right. So having a per-compressor mutex lock would be entirely reasonable. I could also accept a per-module lock. I could even accept the GIL, and if no other code is forth-coming, I would prefer to keep holding the GIL during comprssion over risking crashes. (If we *do* want thread-safety, then it doesn't matter whether the underlying lib is internally thread-safe or not. We would still need to guard against the possibility of the _lzmamodule.c code in one thread modifying the lzma_stream's input or output pointer while lzma_code is operating on the stream's data in another thread.) I haven't reviewed the module in this respect. If you say that it wouldn't be thread-safe even if LZMA was compiled as thread-safe, then this definitely must be fixed. To elaborate on the policy: giving bogus data in cases of race conditions is ok; crashing the interpreter or corrupting memory is not. If bogus data is given, it would be useful if the bogosity can be specified (e.g. when multiple threads read from the same POSIX file concurrently, they also get bogus data, but in a manner where each input byte is given to exactly one thread). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13151] pysetup3 run bdist_wininst fails
Éric Araujo mer...@netwok.org added the comment: On line 118, replacing 'install' with 'install_dist' should fix it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13151 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Martin v. Löwis mar...@v.loewis.de added the comment: Correct. I copied the algorithm from _io.FileIO, under the assumption that there was a reason for not using a simpler O(n log n) doubling strategy. Do you know of any reason for this? Or is it safe to ignore it? I don't know, but I'd say it's safe to ignore it. To elaborate: ISTM that it's actually a bug in FileIO. I can imagine where it's coming from (i.e. somebody feeling that overhead shouldn't grow unbounded), but I think that's ill-advised - *if* somebody really produces multi-gigabyte data (and some people eventually will), they still deserve good performance, and they will be able to afford the memory overhead (else they couldn't store the actual output, either). Generally we use a less-than-doubling strategy, to conserve memory (see e.g. bytearray.c). Most definitely. In case it isn't clear (but it probably is here): any constant factor 1.0 will provide amortized linear complexity. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13160] Rename install_dist to install
New submission from Éric Araujo mer...@netwok.org: When we first added actions to pysetup, the install command was renamed to install_dist to avoid a name conflict between the install command and the install action. Later, the run action was introduced and now serves to namespace all commands. Thus, we have no conflict anymore. I would like to restore the original name of the install command, for distutils compat: people used to d1 build/install will get the same name, and the section in config files (which are currently compatible with d1 and d2, except for install_dist) will share the same name again (letting people give options in [install], not [install] and [install_dist]). -- assignee: eric.araujo components: Distutils2 messages: 145408 nosy: alexis, eric.araujo priority: normal severity: normal status: open title: Rename install_dist to install versions: 3rd party, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13160 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13160] Rename install_dist to install
Changes by Éric Araujo mer...@netwok.org: -- nosy: +tarek ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13160 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13151] pysetup3 run bdist_wininst fails
Changes by Éric Araujo mer...@netwok.org: -- dependencies: +Rename install_dist to install ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13151 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Nadeem Vawda nadeem.va...@gmail.com added the comment: To elaborate on the policy: giving bogus data in cases of race conditions is ok; crashing the interpreter or corrupting memory is not. If bogus data is given, it would be useful if the bogosity can be specified (e.g. when multiple threads read from the same POSIX file concurrently, they also get bogus data, but in a manner where each input byte is given to exactly one thread). OK, that makes sense. My next patch will include per-compressor locks for LZMACompressor and LZMADecompressor. To elaborate: ISTM that it's actually a bug in FileIO. I've filed issue 13159 proposing that FileIO be fixed. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12602] Missing cross-references in Doc/using
Éric Araujo mer...@netwok.org added the comment:
I suggest that it do so in this instance also, using *script* (in
bold-faced italic) as the entry title.
What do you think about :file:`{script}`? file+{} is what Sphinx uses for
filenames with replaceable parts, which map to the HTML var element, which the
stylesheets display as italics.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12602
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13161] problems with help() documentation of __i*__ operators
New submission from Eli Bendersky eli...@gmail.com: Report from Joao Carneiro in the docs@ maillist: I would like to report that I found a mistake in the document of help(set). In the document all the __i*__ methods are described exactly like the same methods without i before the name. Copied from the document: __ixor__(...) x.__ixor__(y) == x^y __xor__(...) x.__xor__(y) == x^y I suppose that the __ixor__ would mean x^=y and not x^y like the __xor__ method right? This problem also occurs for: __iand__ __ior__ __isub__ The report is on Python 3.2, but the problem also exists in 2.7 It appears that the problem's source is in Objects/typeobject.c, where the __i*__ operators are defined with the IBSLOT macro. The documentation string is the operator, passed to IBSLOT - for __ixor__ it's ^, while it should probably be ^= -- assignee: docs@python components: Documentation messages: 145411 nosy: docs@python, eli.bendersky priority: normal severity: normal status: open title: problems with help() documentation of __i*__ operators versions: Python 2.7, Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13161 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11751] Increase distutils.filelist / packaging.manifest test coverage
Éric Araujo mer...@netwok.org added the comment:
I made a few edits and committed to distutils and packaging. Then I ported the
packaging patch to distutils2, which supports Python 2.4-2.7, and got this
failure:
FAIL: test_glob_to_re (__main__.ManifestTestCase)
--
Traceback (most recent call last):
File distutils2/tests/test_manifest.py, line 88, in test_glob_to_re
self.assertEqual(_glob_to_re('foo*'), 'foo[^/]*\\Z(?ms)')
AssertionError: 'foo[^/]*$' != 'foo[^/]*\\Z(?ms)'
I haven’t dug into it yet.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11751
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13146] Writing a pyc file is not atomic
Charles-François Natali neolo...@free.fr added the comment:
Here is a patch for import.c.
Looks good to me.
This new patch also fixes importlib.
path_tmp = path + '.tmp'
with _io.FileIO(path_tmp, 'wb') as file:
file.write(data)
_os.rename(path_tmp, path)
I don't know exactly the context in which this code runs, but you can have a
corruption if multiple processes try to write the bytecode file at the same
time, since they'll all open the .tmp file: it should be opened with O_EXCL.
Also, as a side note, I'm wondering whether this type of check:
if not sys.platform.startswith('win'):
# On POSIX-like platforms, renaming is atomic
couldn't be rewritten as
if os.name == 'posix':
# On POSIX-like platforms, renaming is atomic
Fox example, does OS-X report as POSIX?
--
nosy: +neologix
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13146
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12602] Missing cross-references in Doc/using
Ezio Melotti ezio.melo...@gmail.com added the comment:
The italics parts are easier to recognize when they are within regular text
(e.g. :file:`path/with/python{XY}/file`). If the whole text is in italic
people might not notice the difference.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12602
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13146] Writing a pyc file is not atomic
Antoine Pitrou pit...@free.fr added the comment:
This new patch also fixes importlib.
path_tmp = path + '.tmp'
with _io.FileIO(path_tmp, 'wb') as file:
file.write(data)
_os.rename(path_tmp, path)
I don't know exactly the context in which this code runs, but you can
have a corruption if multiple processes try to write the bytecode file
at the same time, since they'll all open the .tmp file: it should be
opened with O_EXCL.
Or perhaps append the PID to the name of the temp file ?
(easier done in Python than in C :-))
Also, as a side note, I'm wondering whether this type of check:
if not sys.platform.startswith('win'):
# On POSIX-like platforms, renaming is atomic
couldn't be rewritten as
if os.name == 'posix':
# On POSIX-like platforms, renaming is atomic
No, because os.py is not available to importlib (which must be
bootstrappable early). See the _bootstrap.py header for information
about what is available; this is also why we use FileIO instead of
open().
Fox example, does OS-X report as POSIX?
I think so.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13146
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12344] Add **kwargs to get_reinitialized_command
Changes by Thomas Holmes tho...@devminded.com: Added file: http://bugs.python.org/file23388/7db732ac6796.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12344 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3902] Packages containing only extension modules have to contain __init__.py
Éric Araujo mer...@netwok.org added the comment: Looks good, will commit. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3902 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12393] Packaging should provide support for extensible categories
Éric Araujo mer...@netwok.org added the comment: Great. Do you want to update the docs (packaging/setupscript and maybe packaging/commandref too) or shall I do it? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13159] _io.FileIO uses a quadratic-time buffer growth algorithm
Nadeem Vawda nadeem.va...@gmail.com added the comment: I've attached a patch that makes the suggested change to FileIO, and also to _bz2.BZ2Compressor/Decompressor (which currently have the same issue). -- keywords: +patch Added file: http://bugs.python.org/file23389/buffer-growth.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13159 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13159] _io.FileIO uses a quadratic-time buffer growth algorithm
Changes by Nadeem Vawda nadeem.va...@gmail.com: -- stage: needs patch - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13159 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13159] _io.FileIO uses a quadratic-time buffer growth algorithm
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13159 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12344] Add **kwargs to get_reinitialized_command
Changes by Thomas Holmes tho...@devminded.com: Added file: http://bugs.python.org/file23390/1bb1132840e6.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12344 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12344] Add **kwargs to get_reinitialized_command
Thomas Holmes tho...@devminded.com added the comment: Still working with Éric to determine the proper behavior of get_reinitialized_commands. Latest patch is known incorrect but a step closer to our destination. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12344 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12367] select.error has no errno attribute
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 8bbfb24d4824 by Victor Stinner in branch 'default': Issue #12367: Add a test on error attribute of select.error http://hg.python.org/cpython/rev/8bbfb24d4824 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12367 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13156] _PyGILState_Reinit assumes auto thread state will always exist which is not true.
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset ee4fe16d9b48 by Charles-François Natali in branch '2.7': Issue #13156: revert changeset f6feed6ec3f9, which was only relevant for native http://hg.python.org/cpython/rev/ee4fe16d9b48 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13156 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13063] test_concurrent_futures failures on Windows: IOError('[Errno 232] The pipe is being closed') on _send_bytes()
STINNER Victor victor.stin...@haypocalc.com added the comment: The issue has been fixed by the merge of the PEP 3151: I now get a BrokenPipeError with errno=32 and winerror=232. -- status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13063 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13150] Most of Python's startup time is sysconfig
Terry J. Reedy tjre...@udel.edu added the comment: Since #9878 proposes an *alternate* solution to *part* of the sysconfig problem, I disagree with 'supersede'. A Python solution would be more useful for other implementations if enough of the sysconfig info is not CPython specific. A CPython design feature is that it parses and compiles Python code just once per run, and imported modules just once until the code changes (or might have). For functions, everything possible is put into a behind-the-scenes code object. So even inner functions are parsed and compiled just once. The problem with sysconfig, it appears, is that lacks the equivalent design feature but instead does the equivalent of re-parsing and re-compiling inner functions with each outer function call. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13150 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13156] _PyGILState_Reinit assumes auto thread state will always exist which is not true.
Charles-François Natali neolo...@free.fr added the comment: Here's a patch for 3.2 and default which calls PyThread_set_key_value() only if there was an auto thread state previously associated (while the current code works with pthread TLS, there are other implementations which may behave strangely, and there's still the ad-hoc implementation in Python/thread.c). -- Added file: http://bugs.python.org/file23391/tstate_after_fork.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13156 ___diff --git a/Python/pystate.c b/Python/pystate.c --- a/Python/pystate.c +++ b/Python/pystate.c @@ -586,9 +586,9 @@ autoInterpreterState = NULL; } -/* Reset the TLS key - called by PyOS_AfterFork. +/* Reset the TLS key - called by PyOS_AfterFork(). * This should not be necessary, but some - buggy - pthread implementations - * don't flush TLS on fork, see issue #10517. + * don't reset TLS upon fork(), see issue #10517. */ void _PyGILState_Reinit(void) @@ -598,8 +598,10 @@ if ((autoTLSkey = PyThread_create_key()) == -1) Py_FatalError(Could not allocate TLS entry); -/* re-associate the current thread state with the new key */ -if (PyThread_set_key_value(autoTLSkey, (void *)tstate) 0) +/* If the thread had an associated auto thread state, reassociate it with + * the new key (this will not hold, for example, for a thread created + * outside of Python calling into a subinterpreter). */ +if (tstate PyThread_set_key_value(autoTLSkey, (void *)tstate) 0) Py_FatalError(Couldn't create autoTLSkey mapping); } ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13157] Build Python outside the source directory
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 1811c4e5527f by Victor Stinner in branch 'default': Issue #13157: Fix building Python outside its source tree http://hg.python.org/cpython/rev/1811c4e5527f -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13157 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12602] Missing cross-references in Doc/using
Terry J. Reedy tjre...@udel.edu added the comment: Since *script* is a file -- that is all variable -- that seems appropriate. Bold italic tends to be more notably different from bold italic than the normal pair. In any case, italic is the doc standard for function parameter names. It seems more sensible than introducing a unique occurrence of angle brackets. An alternative is to simply delete the angle brackets. If we consistently applied the italicize non-literal symbolic parameter names rule to command line examples, we would italicize 'command', 'module-name', 'script', and 'args' in python [-BdEiOQsStuUvVWxX3?] [-c command | -m module-name | script | - ] [args] just like in function signatures. I actually would like that as it would similarly diffentiate them from the literal constants meant to be entered as written. Has that ever been discussed by the doc group? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12602 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13155] Optimize finding the max character width
STINNER Victor victor.stin...@haypocalc.com added the comment: Without the patch: python3.2 -m timeit 'x=é+x*1' 'x[1:]' 10 loops, best of 3: 2.18 usec per loop python3.3 -m timeit 'x=é+x*1' 'x[1:]' 10 loops, best of 3: 6.68 usec per loop -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13155] Optimize finding the max character width
STINNER Victor victor.stin...@haypocalc.com added the comment: With find_max_char4.patch: python3.3 -m timeit 'x=é+x*1' 'x[1:]' 10 loops, best of 3: 1.96 usec per loop -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13156] _PyGILState_Reinit assumes auto thread state will always exist which is not true.
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 3313ce92cef7 by Charles-François Natali in branch '2.7': Issue #13156: Add an entry in Misc/NEWS. http://hg.python.org/cpython/rev/3313ce92cef7 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13156 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13154] pep-0000.txt doesn't build anymore
Changes by Mike Hoy mho...@gmail.com: -- nosy: +mikehoy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13146] Writing a pyc file is not atomic
Charles-François Natali neolo...@free.fr added the comment:
Or perhaps append the PID to the name of the temp file ?
(easier done in Python than in C :-))
I don't really like appending PIDs to generate file names:
- if you have multiple processes at the same time, they'll all write
their own file which will end up being replaced by the last one to
perform the move, whereas with O_EXCL, they'll see immediately that
another instance is writing it (the overhead is negligible with such
small files, but maybe not so much when creating the file requires a
certain amout of work)
- if processes crash at the wrong time, you can end up with a flurry
of filename.PID
- the last one is even more insidious and unlikely, but here it goes:
the PID is unique only on a given machine: if you have, for example, a
network file system shared between multiple hosts, then you can have a
PID collision, whereas O_EXCL is safe (O_EXCL doesn't work on NFSv2,
but nowadays every OS implements it correctly on NFSv3)
O_EXCL is really what POSIX offers to solve this (and it's also what
import.c does).
Also, as a side note, I'm wondering whether this type of check:
if not sys.platform.startswith('win'):
# On POSIX-like platforms, renaming is atomic
couldn't be rewritten as
if os.name == 'posix':
# On POSIX-like platforms, renaming is atomic
No, because os.py is not available to importlib (which must be
bootstrappable early). See the _bootstrap.py header for information
about what is available; this is also why we use FileIO instead of
open().
OK. So is the O_EXCL approach possible? Would something like
_io.open(_os.open(path, _os.O_CREATE|os.O_EXCL...), 'wb')
work?
Also, since this can be quite tricky and redundant, how about adding a
framework to do this kind of thing to the standard library?
Something like
with atomic_create(final path, 'b') as f:
f.write(data)
where atomic_create would be a context manager that would make `f`
point to a temporary file (open with O_EXCL :-), and do the rename at
the end. It could also accept an option to ensure durability (i.e.
call fsync() on the file and on the parent directory). Note that it
probably wouldn't help here, since we only have access to a really
limited part of the library :-)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13146
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12393] Packaging should provide support for extensible categories
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: Great. Do you want to update the docs (packaging/setupscript and maybe packaging/commandref too) or shall I do it? Feel free to do it, if that's OK with you. I've got a couple of other pythonv issues which are taking my time at the moment, plus I am also looking at Windows binary packaging as discussed recently on python-dev. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12393 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13155] Optimize finding the max character width
STINNER Victor victor.stin...@haypocalc.com added the comment: find_max_char5.patch: - don't use adjusted ~mask+1: precompute the right max_char - rename findwidth.h to find_max_char.h - add some #undef -- Added file: http://bugs.python.org/file23392/find_max_char5.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13154] pep-0000.txt doesn't build anymore
Mike Hoy mho...@gmail.com added the comment: :~/peps$ find . -name *.txt | xargs grep canterbury ./pep-3152.txt:Author: Gregory Ewing greg.ew...@canterbury.ac.nz ./pep-0380.txt:Author: Gregory Ewing greg.ew...@canterbury.ac.nz ./pep-0284.txt:Greg Ewing greg.ew...@canterbury.ac.nz ./pep-0335.txt:Author: Gregory Ewing g...@cosc.canterbury.ac.nz Looks like pep-0335.txt has a Gregory Ewing with a different email address (g...@cosc.canterbury.ac.nz) that is normally associated with Gregory Ewing (greg.ew...@canterbury.ac.nz). Which is an error according to: pep0/output.py: if too_many_emails: err_output = [] for author, emails in too_many_emails: err_output.append(%s: %r % (author, emails)) raise ValueError(some authors have more than one email address listed:\n + '\n'.join(err_output)) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13157] Build Python outside the source directory
Roumen Petrov bugtr...@roumenpetrov.info added the comment: Which is platform with broken VPATH support and/or make ? -- nosy: +rpetrov ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13157 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13146] Writing a pyc file is not atomic
STINNER Victor victor.stin...@haypocalc.com added the comment: with atomic_create(final path, 'b') as f: See issues #8604 and #8828. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13146 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13157] Build Python outside the source directory
STINNER Victor victor.stin...@haypocalc.com added the comment: Which is platform with broken VPATH support and/or make ? Well, my commit is maybe useless... I tried to have two builds at the same time: - debug in Python source code (e.g. ~/python) - release in a subdirectory in the Python source code (e.g. ~/python/release) If I compile in debug mode before building in release mode, the build of the release mode fails because make finds some objects in source tree (and so think that it doesn't need to build them). I tried to avoid completly VPATH to support this use case, but I'm not sure that it is possible (at least, it doesn't work: it fails to build pgen in the release). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13157 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13155] Optimize finding the max character width
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 9c7d3207fc15 by Antoine Pitrou in branch 'default': Issue #13155: Optimize finding the optimal character width of an unicode string http://hg.python.org/cpython/rev/9c7d3207fc15 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13155] Optimize finding the max character width
Antoine Pitrou pit...@free.fr added the comment: find_max_char5.patch: - don't use adjusted ~mask+1: precompute the right max_char - rename findwidth.h to find_max_char.h - add some #undef Thank you, I've committed this version. -- resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13155 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13151] pysetup3 run bdist_wininst fails
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment:
On line 118, replacing 'install' with 'install_dist' should fix it.
Sadly, it just defers the problem:
vinay@eta-natty:~/projects/dory$ pysetup3 run bdist_wininst
running bdist_wininst
running build
running build_py
running build_scripts
installing to build/bdist.linux-i686/wininst
running install_lib
creating build/bdist.linux-i686
creating build/bdist.linux-i686/wininst
creating build/bdist.linux-i686/wininst/PURELIB
creating build/bdist.linux-i686/wininst/PURELIB/apackage
running install_scripts
creating build/bdist.linux-i686/wininst/SCRIPTS
changing mode of build/bdist.linux-i686/wininst/SCRIPTS/dory to 755
running install_distinfo
creating build/bdist.linux-i686/wininst/PURELIB/dory-0.1.dist-info
creating build/bdist.linux-i686/wininst/PURELIB/dory-0.1.dist-info/METADATA
creating build/bdist.linux-i686/wininst/PURELIB/dory-0.1.dist-info/INSTALLER
creating build/bdist.linux-i686/wininst/PURELIB/dory-0.1.dist-info/REQUESTED
creating build/bdist.linux-i686/wininst/PURELIB/dory-0.1.dist-info/RECORD
Traceback (most recent call last):
File /usr/local/bin/pysetup3, line 4, in module
sys.exit(main())
File /usr/local/lib/python3.3/packaging/run.py, line 653, in main
return dispatcher()
File /usr/local/lib/python3.3/packaging/run.py, line 642, in __call__
return func(self, self.args)
File /usr/local/lib/python3.3/packaging/run.py, line 91, in wrapper
return f(*args, **kwargs)
File /usr/local/lib/python3.3/packaging/run.py, line 288, in _run
dist.run_command(cmd, dispatcher.command_options[cmd])
File /usr/local/lib/python3.3/packaging/dist.py, line 709, in run_command
cmd_obj.run()
File /usr/local/lib/python3.3/packaging/command/bdist_wininst.py, line 175,
in run
self.create_exe(arcname, fullname, self.bitmap)
File /usr/local/lib/python3.3/packaging/command/bdist_wininst.py, line 243,
in create_exe
cfgdata = self.get_inidata()
File /usr/local/lib/python3.3/packaging/command/bdist_wininst.py, line 202,
in get_inidata
info = (metadata.long_description or '') + '\n'
AttributeError: 'Metadata' object has no attribute 'long_description'
It appears that there is some confusion as to whether to use attribute or item
access. The failing code above needs to be replaced with something like
if 'long_description' in metadata:
info = metadata['long_description']
else:
info = metadata.get('description', '')
info += '\n'
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13151
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13157] Build Python outside the source directory
Roumen Petrov bugtr...@roumenpetrov.info added the comment: I wonder why you are not stopped by: configure: error: source directory already configured; run make distclean there first. (for sure you remove some files but not all) Applied patch is save but I cannot understand what actually is resolved. Note that someone already report as bug(?) attempt to build outside when first project is compiled in source. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13157 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13162] Trying to install a binary extension as a resource file causes pysetup to give a traceback
New submission from Paul Moore p.f.mo...@gmail.com:
I am trying to create a pysetup package that contains a precompiled binary
extension, which can be installed without compiling, by using the resource file
feature of setup.cfg. This may be incorrect usage of pysetup, but at a minimum,
a proper error message should be given rather than a traceback.
With a directory containing an extension hello.pyd plus the following setup.cfg
file:
[metadata]
name = hello
version = 0.1
author = Paul Moore
author-email = p.f.mo...@gmail.com
summary = Test C extension
[files]
resources =
hello.pyd = {platlib}
I get a traceback when I do pysetup install:
PS D:\Data\python-sample\bin pysetup install
Installing from source directory: 'D:\\Data\\python-sample\\bin'
running install_dist
running build
running install_data
running install_distinfo
creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info
creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\METADATA
creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\INSTALLER
creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\REQUESTED
creating D:\Data\cpython\Lib\site-packages\hello-0.1.dist-info\RESOURCES
Traceback (most recent call last):
File D:\Data\cpython\lib\runpy.py, line 160, in _run_module_as_main
__main__, fname, loader, pkg_name)
File D:\Data\cpython\lib\runpy.py, line 73, in _run_code
exec(code, run_globals)
File D:\Data\cpython\lib\packaging\run.py, line 666, in module
sys.exit(main())
File D:\Data\cpython\lib\packaging\run.py, line 653, in main
return dispatcher()
File D:\Data\cpython\lib\packaging\run.py, line 642, in __call__
return func(self, self.args)
File D:\Data\cpython\lib\packaging\run.py, line 91, in wrapper
return f(*args, **kwargs)
File D:\Data\cpython\lib\packaging\run.py, line 164, in _install
return not install_local_project(target)
File D:\Data\cpython\lib\packaging\install.py, line 122, in
install_local_project
return _run_install_from_dir(path)
File D:\Data\cpython\lib\packaging\install.py, line 160, in
_run_install_from_dir
func(source_dir)
File D:\Data\cpython\lib\packaging\install.py, line 87, in
_run_packaging_install
dist.run_command('install_dist')
File D:\Data\cpython\lib\packaging\dist.py, line 709, in run_command
cmd_obj.run()
File D:\Data\cpython\lib\packaging\command\install_dist.py, line 506, in run
self.run_command(cmd_name)
File D:\Data\cpython\lib\packaging\command\cmd.py, line 330, in run_command
self.distribution.run_command(command)
File D:\Data\cpython\lib\packaging\dist.py, line 709, in run_command
cmd_obj.run()
File D:\Data\cpython\lib\packaging\command\install_distinfo.py, line 112,
in run
writer.writerow(row)
TypeError: 'str' does not support the buffer interface
If this configuration is invalid a better error message should be given.
However, I would also like to know what (if any) would be the correct way of
writing a setup.cfg file to install a compiled extension like this.
For background on why I am trying to do things in this (odd) way, see the
python-dev thread starting at
http://mail.python.org/pipermail/python-dev/2011-October/113956.html
--
assignee: tarek
components: Distutils2, Library (Lib)
messages: 145441
nosy: alexis, eric.araujo, pmoore, tarek
priority: normal
severity: normal
status: open
title: Trying to install a binary extension as a resource file causes pysetup
to give a traceback
type: behavior
versions: Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue13162
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13163] `port` and `host` are confused in `_get_socket
New submission from Ram Rachum r...@rachum.com: Look here: http://hg.python.org/cpython/file/3313ce92cef7/Lib/smtplib.py#l279 `port` and `host` are confused. I saw this is fixed on 3.2; possibly it should be fixed in the next 2.7 micro release too. -- components: Library (Lib) messages: 145442 nosy: cool-RR priority: normal severity: normal status: open title: `port` and `host` are confused in `_get_socket versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13163 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13159] _io.FileIO uses a quadratic-time buffer growth algorithm
Antoine Pitrou pit...@free.fr added the comment: The patch looks good to me, thanks. -- versions: +Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13159 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13154] pep-0000.txt doesn't build anymore
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13154] pep-0000.txt doesn't build anymore
Senthil Kumaran sent...@uthcode.com added the comment: Fixed in 25ff1adf5f30 -- nosy: +orsenthil resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13154 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue13150] Most of Python's startup time is sysconfig
Changes by John O'Connor tehj...@gmail.com: -- nosy: +jcon ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue13150 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12807] Optimization/refactoring for {bytearray, bytes, unicode}.strip()
Antoine Pitrou pit...@free.fr added the comment:
Please double check the removal of _PyUnicode_XStrip.
I think it's ok. It is private, undocumented, and the only references
returned by Google Code Search are in Python itself.
I'll review the patch later, thank you.
--
title: Move strip() to stringlib - Optimization/refactoring for {bytearray,
bytes, unicode}.strip()
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12807
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Changes by Nadeem Vawda nadeem.va...@gmail.com: Added file: http://bugs.python.org/file23393/bdf0afbbbd80.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Changes by Nadeem Vawda nadeem.va...@gmail.com: Removed file: http://bugs.python.org/file23168/591277fe6b4a.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6715] xz compressor support
Nadeem Vawda nadeem.va...@gmail.com added the comment: Patch update time! Noteworthy changes: * Windows build support, thanks to Amaury * Thread safety for LZMACompressor and LZMADecompressor, by means of per-instance locks * O(n) buffer growth strategy I've tried running the tests on Windows, but I've been getting failures that don't look like they're related to the new code. I think they are due to issue 7443. I'll try and tweak my Windows setup a bit over the weekend to see if I can get things working smoothly. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
