[issue28382] Possible deadlock after many multiprocessing.Process are launch
New submission from Alexis:
I am launching a process inside a pool worker, using the multiprocessing module.
After a while, a deadlock append when I am trying to join the process.
Here is a simple version of the code:
import sys, time, multiprocessing
from multiprocessing.pool import ThreadPool
def main():
# Launch 8 workers
pool = ThreadPool(8)
it = pool.imap(run, range(500))
while True:
try:
it.next()
except StopIteration:
break
def run(value):
# Each worker launch its own Process
process = multiprocessing.Process(target=run_and_might_segfault,
args=(value,))
process.start()
while process.is_alive():
sys.stdout.write('.')
sys.stdout.flush()
time.sleep(0.1)
# Will never join after a while, because of a mystery deadlock
process.join()
def run_and_might_segfault(value):
print(value)
if __name__ == '__main__':
main()
And here is a possible output:
~ python m.py
..0
1
8
.9
...10
..11
12
13
14
16
As you can see, process.is_alive() is alway true after few iterations, the
process will never join.
If I CTRL-C the script a get this stacktrace:
Traceback (most recent call last):
File
"/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5/lib/python3.5/multiprocessing/pool.py",
line 680, in next
item = self._items.popleft()
IndexError: pop from an empty deque
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "m.py", line 30, in
main()
File "m.py", line 9, in main
it.next()
File
"/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5
/lib/python3.5/multiprocessing/pool.py", line 684, in next
self._cond.wait(timeout)
File
"/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5
/lib/python3.5/threading.py", line 293, in wait
waiter.acquire()
KeyboardInterrupt
Error in atexit._run_exitfuncs:
Traceback (most recent call last):
File
"/usr/local/Cellar/python3/3.5.1/Frameworks/Python.framework/Versions/3.5
/lib/python3.5/multiprocessing/popen_fork.py", line 29, in poll
pid, sts = os.waitpid(self.pid, flag)
KeyboardInterrupt
Using python 3.5.1 on macos, also tried with 3.5.2 with same issue.
Same result on Debian.
I tried using python 2.7, and it is working well. May be a python 3.5 issue
only?
Here is the link of the stackoverflow question:
http://stackoverflow.com/questions/39884898/large-amount-of-multiprocessing-process-causing-deadlock
--
components: Library (Lib)
messages: 278221
nosy: Hadhoke
priority: normal
severity: normal
status: open
title: Possible deadlock after many multiprocessing.Process are launch
type: behavior
versions: Python 3.5
___
Python tracker
<http://bugs.python.org/issue28382>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12113] test_packaging fails when run twice
Alexis Metaireau added the comment: Same here, cannot reproduce the issue. I wasn't able to reproduce it even before Tarek's commit so I suppose his commit didnt changed anything regarding this hash problem. Antoine & Tarek, does the attached additional test reproduces the issue on your installation? -- assignee: tarek -> alexis keywords: +patch resolution: fixed -> status: closed -> open Added file: http://bugs.python.org/file22091/serve_twice.patch ___ Python tracker <http://bugs.python.org/issue12113> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12391] packaging install fails to clean up temp files
Alexis Metaireau added the comment: I'm +1 on applying this patch as well. Removing files in the tmp directory is far better than letting the OS doing so. -- ___ Python tracker <http://bugs.python.org/issue12391> ___ ___ 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
Alexis Metaireau added the comment: Carl, I believe that's this one: http://wiki.python.org/moin/UsecasesOfDevelop -- ___ Python tracker <http://bugs.python.org/issue8668> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12697] timeiot documention still refers to the timeit.py script
New submission from Alexis Metaireau : The example section of the timeit documentation still refers to "timeit.py", and isn't using the "python -m timeit" syntax used above. http://docs.python.org/library/timeit.html#examples I'm not sure when and if the timeit.py script has been removed from the python installation (and I'm not sure on where to look for this). The timeit.py docstring also refers to this "old" syntax. Should we update it? All credit for this report goes to Boris Feld. -- assignee: alexis components: Library (Lib) messages: 141663 nosy: alexis priority: low severity: normal status: open title: timeiot documention still refers to the timeit.py script versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker <http://bugs.python.org/issue12697> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12697] timeiot documention still refers to the timeit.py script
Changes by Alexis Metaireau : -- nosy: +Boris.FELD ___ Python tracker <http://bugs.python.org/issue12697> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12697] timeit documention still refers to the timeit.py script
Changes by Alexis Metaireau : -- title: timeiot documention still refers to the timeit.py script -> timeit documention still refers to the timeit.py script ___ Python tracker <http://bugs.python.org/issue12697> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6203] 3.x locale does not default to C, contrary to the documentation and to 2.x behavior
Alexis Metaireau added the comment: Maybe could it be useful to specify in the documentation that getlocale() is not intended to be used to get information about what is the locale of the system? It's not explained currently and thus it's a bit weird to have getlocale returning (None, None) even if you have your locales set. -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue6203> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6203] 3.x locale does not default to C, contrary to the documentation and to 2.x behavior
Alexis Metaireau added the comment: I see two different things here: 1) the fact that getlocale() doesn't return (None, None) on some python versions 2) the fact that having it returning (None, None) by default is a bit misleading as users may think that getlocale() is tied to environment variables. That's what was at the origin of #12699 My last remark is about the second bit. Maybe should I start a new issue for this? -- title: 3.x locale does not default to C,contrary to the documentation and to 2.x behavior -> 3.x locale does not default to C, contrary to the documentation and to 2.x behavior ___ Python tracker <http://bugs.python.org/issue6203> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12726] explain why locale.getlocale() does not read system's locales
New submission from Alexis Metaireau : The documentation about locale.getlocale() doesn't talk about the fact that the locale isn't read from the system locale. Thus, it seemed strange to have locale.getlocale() returning (None, None). As it seems to be the expected behaviour, it seems useful to specify this in the documentation and make it explicit. I'm okay to write a patch and apply it. This issue is related to #6203, but does not supersede it (the two conversations are discussing two different things). -- assignee: alexis components: Documentation messages: 141897 nosy: alexis, feth priority: normal severity: normal status: open title: explain why locale.getlocale() does not read system's locales ___ Python tracker <http://bugs.python.org/issue12726> ___ ___ 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
Alexis Metaireau added the comment: _run_setuptools_install is only intended to support setuptools setup.py, converting .egg-info to .dist-info, internally. IMO, you should not care about the differences between setuptools/distutils1/setuptools at this level, as it should be taken care at the install level. When installing old setuptools-based setup.py, the .egg-info should be gone, replaced by a shiny new .dist-info folder. I'm not sure why you're talking about it in the context of develop, can you clarify this? -- ___ Python tracker <http://bugs.python.org/issue8668> ___ ___ 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
Alexis Metaireau added the comment: IOW, in my opinion, support for setuptools develop command is not needed in packaging core, and still be taken care directly be the users wanting to run python setup.py develop: I don't see any reason to make it avaible on the stdlib. -- ___ Python tracker <http://bugs.python.org/issue8668> ___ ___ 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
Alexis Metaireau added the comment: Yep, packaging is not keeping the .egginfo directories, or at least does not plan to keep them (It should be the case currently but I haven't checked recently) in the upcoming release, so I would go on removing support for setuptools' develop command here :) -- ___ Python tracker <http://bugs.python.org/issue8668> ___ ___ 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
Alexis Metaireau added the comment: On 08/18/2011 05:54 PM, higery wrote: > Then do you also mean support that for setuptools install is also not > necessary in packaging core? setuptools install is only supported in packaging because it's a widely used thing, and many python distributions are currently packaged using setuptools features in their setup.py > I think the current implemention way of Packaging 'install' command just offers an executing router to run a proper 'install', which users doesn't need to know. What packaging.install does is, if the project has been packaged using setuptools, relying on it to install the projects, while not letting it take care of the dependencies. Then, the .egginfo is converted to a .distinfo, so the way setuptools distributions are installed is *not* compatible with setuptools installation procedure. It is important to note that setuptools will *not* be a dependency for packaging, but rather the end user will be prompted to install it if it's not present and he wants to install a setuptools based project (or if what he's trying to install relies on setuptools based projects). The problem with the develop command seems different to my eyes: develop is used by developers, not by end users. Thus, proposing them to keep using the "old" setuptools develop command in packaging may seem like encouraging them to continue using setuptools. Rather, I would prefer to say: "well, if you want to use setuptools' develop command, you can continue to do so, but the way to go would probably to repackage your project using shiny new standards". That's one of the handles we have to help the transition to packaging, so taking this occasion seems important to me. -- ___ Python tracker <http://bugs.python.org/issue8668> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12703] Improve error reporting for packaging.util.resolve_name
Alexis Metaireau added the comment: Thanks Rémy, About testing, I would go for modules with errors in it and check that when imported trough this function it does what it is supposed to do. IOW: 1. Create a test python module with errors in their definition (Throw an exception would do the trick) 2a. Try to load this python module, check that the exception is the one thrown in the module 2.b Check that loading a non existing modules still tell us that the module doesn't exist 2.c Check that importing something existing works, trough this function. Hope I'm clear enough, thanks again, Alexis -- ___ Python tracker <http://bugs.python.org/issue12703> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8190] Add a PyPI XML-RPC client module
Alexis Metaireau added the comment: Please, can you be a bit more precise about the missing features ? I'll be glad to cover them. -- ___ Python tracker <http://bugs.python.org/issue8190> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8190] Add a PyPI XML-RPC client module
Alexis Metaireau added the comment: Yes, all the functions are covered. By the way, I've covered all the functions based on the pypi source code, not on the wiki. I'll update the wiki page with some examples soon :) -- ___ Python tracker <http://bugs.python.org/issue8190> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11357] Add support for PEP 381 -- Mirror Authenticity
Alexis Metaireau added the comment: Some nitpicks: In mirrors.get_server_key, the documentation is not up to date with your last changes (raises an error if there is a problem instead of returning None) You do use the name 'package' while talking about distributions or projects. Please be sure to use the right one on the right place (in your case, that's a project). A project (Django) contains releases (Django 1.1, 1.2, 1.3?) which contains distributions (sdist, bdist). The "verify_package" name could probably be changed in "is_trustable" or something like that, or raise an error (Otherwise, one can use verify_package thinking that it will actually check for something, without looking at the return value). In the documentation, you've mainly copy/pasted the PEP and provided examples on how to do the authenticity check with distutils2. While the second part is fine, I think that duplicating the PEP content on the documentation is probably an error: If the PEP changes, then the distutils2 documentation have to change as well. You probably can just refer on the PEP with a link. Adding informations on where did you find the sources of verify.py could be nice as well. Again, thanks for your work ! -- ___ Python tracker <http://bugs.python.org/issue11357> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11357] Add support for PEP 381 -- Mirror Authenticity
Alexis Metaireau added the comment: Antoine Pitrou on #python-dev made interesting remarks about the validation: 16:19 < __ap__> hmm the way the patch does validation is bogus 16:22 < __ap__> because it opens the URL a first time, validates it, then opens it a second time with urlopen() 16:22 < __ap__> without verifying the certificate on the second time 16:23 < __ap__> it should do the validation directly with urlopen() 16:23 < __ap__> (which probably requires defining a custom HTTPSHandler) -- ___ Python tracker <http://bugs.python.org/issue11357> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11921] distutils2 should be able to compile an Extension based on the Python implementation version
Alexis Metaireau added the comment: This raises a concern about python specific python implementations dependencies. We probably could extend PEP 345 in order to support things such as 'platform.python_implementation == "cpython"'. -- ___ Python tracker <http://bugs.python.org/issue11921> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11921] distutils2 should be able to compile an Extension based on the Python implementation version
Alexis Metaireau added the comment: On 29/04/2011 18:20, Daniel Holth wrote: > New in version 2.6. Yep that's it. We would need to backport it in the python2 port of packaging (namely distutils2), but it would do the trick. I just started a discussion about that on the fellowship (to know if we can add this to PEP 345). -- Alexis -- title: distutils2 should be able to compile an Extension based on the Python implementation version -> distutils2 should be able to compile an Extension based on the Python implementation version ___ Python tracker <http://bugs.python.org/issue11921> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5302] Allow package_data globs match directories
Alexis Metaireau added the comment: The MANIFEST.in is definitely gone in distutils2. Can we close that? (don't have the rights to do so ‑ it can be handy on distutils2 bugs) -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue5302> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5243] Missing dependency in distutils build
Alexis Metaireau added the comment: Has the patch been applied on distutils(1/2) ? -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue5243> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue901727] extra_path kwarg to setup() undocumented
Alexis Metaireau added the comment: I've applied the patch on distutils2. This can now be closed. -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue901727> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6087] distutils.sysconfig.get_python_lib gives surprising result when used with a Python build
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue6087> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2200] find_executable fails to find .bat files on win32
Alexis Metaireau added the comment: Have the patch been applied ? (the state is still open since last message) -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue2200> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7546] msvc9compiler.py: add .asm extension
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue7546> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue901727] extra_path kwarg to setup() undocumented
Alexis Metaireau added the comment: Still, the extra_path argument exists and can be used, it's worth to have it documented somewhere, especially if someone have done it. That's also true that apiref.rst is outdated in d2, and will need a complete reshape :) -- ___ Python tracker <http://bugs.python.org/issue901727> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1083299] Distutils doesn't pick up all the files it should.
Changes by Alexis Metaireau : -- components: -Distutils2 nosy: +alexis ___ Python tracker <http://bugs.python.org/issue1083299> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1597850] Cross compiling patches for MINGW
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue1597850> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1294032] Distutils writes keywords comma-separated
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue1294032> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1092365] Distutils needs a way *not* to install files
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue1092365> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1635363] Add command line help to windows unistall binary
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue1635363> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1011113] Make “install” find the build_base directory
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue103> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11213] distutils2 test issue
Alexis Metaireau added the comment: yeah, thanks for that ! -- ___ Python tracker <http://bugs.python.org/issue11213> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11219] Produce a warning when the license is specified in both the License and Classifier metadata fields
Alexis Metaireau added the comment: Hi, I was more thinking about something like: if the license is specified in the "License" metadata, then check that it's not a well known license (which can and must be provided by the classifiers instead). At the end, the code you've wrote is useful, but not complete. Additionally, it seems that your patch make check complaining if you just have *defined* classifiers and license (even if the license is not provided in the classifiers: it complains if there is both defined, regardless what is defined). It should check instead if the classifier field contain the same thing than the license field. -- ___ Python tracker <http://bugs.python.org/issue11219> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11219] Produce a warning when the license is specified in both the License and Classifier metadata fields
Alexis Metaireau added the comment: That's almost what the PEP says, or at least what I understand of it. The platform and license fields should be used only if no matching classifier exists for them. -- ___ Python tracker <http://bugs.python.org/issue11219> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3310] Out-of-date example 3.0b1 Tutorial Classes page, 'issubclass'
New submission from Alexis Layton <[EMAIL PROTECTED]>: The bullet example for 'issubclass' should be updated since neither 'unicode' or 'basestring' are valid anymore. -- assignee: georg.brandl components: Documentation messages: 69363 nosy: alexis.layton, georg.brandl severity: normal status: open title: Out-of-date example 3.0b1 Tutorial Classes page, 'issubclass' type: behavior versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3310> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14317] index.simple module lacking in distutils2
Changes by Alexis Metaireau : -- resolution: -> wont fix status: open -> closed ___ Python tracker <http://bugs.python.org/issue14317> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14317] index.simple module lacking in distutils2
Alexis Metaireau added the comment: The APIs of distutils2 have changed. the "index" module is now named "pypi". So, doing something like:: >>> from distutils2.pypi.simple import Crawler should work. -- ___ Python tracker <http://bugs.python.org/issue14317> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11880] add a {dist-info} category to distutils2
Alexis Metaireau added the comment: Hey, is there any news on this bug? Berker? -- ___ Python tracker <http://bugs.python.org/issue11880> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14294] Requirements are not properly copied into metatdata of dist-info
Alexis Metaireau added the comment: Thanks for reporting this Preston, Could you be a bit more precise on this one? What is the input you are giving (in the dist-info) and what is not being done? (what's the expected output and what's what you have as a result of running util.egginfo_to_distinfo) Éric, I'm not sure #11880 is a dependency of this one, could you expand on this? -- ___ Python tracker <http://bugs.python.org/issue14294> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5302] Allow package_data specs/globs to match directories
Alexis Metaireau added the comment: Agreed on this one. That would avoid to have a new syntax for this case, which seems to be very common. -- ___ Python tracker <http://bugs.python.org/issue5302> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14319] cleanup index switching mechanism on packaging.pypi
New submission from Alexis Metaireau : I need to do some general cleanup on packaging/d2, and especially on this bit. Currently, the implementation is way too complicated for what it does. -- assignee: alexis components: Distutils2 messages: 155903 nosy: alexis, tarek priority: normal severity: normal status: open title: cleanup index switching mechanism on packaging.pypi type: enhancement ___ Python tracker <http://bugs.python.org/issue14319> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14279] packaging.pypi should support flat directories of distributions
Alexis Metaireau added the comment: It is supposed to work already, but I'm not sure this is tested or complete. I'll have a closer look on this. +1 on the general idea. -- assignee: eric.araujo -> alexis ___ Python tracker <http://bugs.python.org/issue14279> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14280] packaging.pypi should not require checksums
Alexis Metaireau added the comment: If no MD5 checksum is present on the crawled simple index, then we don't have to check them. This means we introduce a potential security hole here (md5 checksums were added for a reason). What could be done is to explicitely don't check them if asked so. For instance using a --no-checksum flag when running pysetup, or passing a no_checksum argument when using the crawler. Would that work for you? Éric, this is a different issue than the one you pointed out in the sence that one is for local files and the other is for remote indexes. (Of course, local files, will not need checksums as well). -- ___ Python tracker <http://bugs.python.org/issue14280> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14275] pysetup create doesn't handle install requirements
Changes by Alexis Metaireau : -- dependencies: +Requirements are not properly copied into metatdata of dist-info ___ Python tracker <http://bugs.python.org/issue14275> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14275] pysetup create doesn't handle install requirements
Changes by Alexis Metaireau : -- dependencies: -Requirements are not properly copied into metatdata of dist-info ___ Python tracker <http://bugs.python.org/issue14275> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14275] pysetup create doesn't handle install requirements
Alexis Metaireau added the comment: Thanks for reporting this, Jan-Jaap, I've marked this issue as easy, it's mostly a matter of looking at the passed parameter and outputing the list in the generated file, respecting the PEP 345 format (http://www.python.org/dev/peps/pep-0345/#requires-dist-multiple-use) Do you want to work on this one? -- keywords: +easy ___ Python tracker <http://bugs.python.org/issue14275> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14280] packaging.pypi should not require checksums
Alexis Metaireau added the comment: Right, I'll go for this then. -- ___ Python tracker <http://bugs.python.org/issue14280> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14279] packaging.pypi should support flat directories of distributions
Alexis Metaireau added the comment: Oh, thanks for clarifying this. I'll have a look at what the blockers are on this. I'm wondering if "local files" can be considered a simple index or not. If not, we can add another PyPI reader, which works with local files. -- ___ Python tracker <http://bugs.python.org/issue14279> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14356] Distutils2 ignores site-local configuration
Alexis Metaireau added the comment: The supposed way to work, for OS packagers, is to ship this sysconfig.cfg thing. I'm not sure we should rely on a customized site-local configuration, without defining any standard way of doing this (IOW: what are we looking for in the site-local config?) Also, I would add that this seem to be a compatibility thing, maybe could we add a fallback to site-local if no sysconfig is found? -- ___ Python tracker <http://bugs.python.org/issue14356> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14433] Python 3 interpreter crash with memoryview and os.fdopen
New submission from Alexis Daboville : Hi, I was "playing" with memoryviews when I found this behaviour, launch the Python shell, and then enter the following: >>> import os >>> memoryview(os.fdopen(0)) A TypeError "cannot make memory view because object does not have the buffer interface" is raised and shown in the shell. Then: * On Windows 7, Python 3.2.2: Windows open a window with something like this "python.exe has stopped working" * On CrunchBang Linux (Debian), Python 3.1.3: the shell exits (though echo $? print 0...). On IRC, valhallasw was able to reproduce the bug: [19:24] a__: also happens under 3.2.2 under windows XP /and/ 3.2 under ubuntu natty [19:24] the latter just crashes without any message, the former gives the windows XP equivalent of the 'program has stopped working' message I hope this help, if you need more information please ask. -- messages: 156996 nosy: alexis.d priority: normal severity: normal status: open title: Python 3 interpreter crash with memoryview and os.fdopen type: crash versions: Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue14433> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14433] Python 3 interpreter crash with memoryview and os.fdopen
Alexis Daboville added the comment: First, thank you all for the explanations (sorry for the misleading title about the memoryview, should I rename it?). > @Brian: this isn't a crash. It is completely equivalent to pressing D > at the interactive interpreter prompt. Not exactly, at least on Windows if I type ^Z + (which is the equivalent of ^D) the shell exits normally, while here there's an "annoying" error message (I don't say that it's important, just that that's not completely equivalent) -- ___ Python tracker <http://bugs.python.org/issue14433> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14433] Python 3 interpreter crash with memoryview and os.fdopen
Alexis Daboville added the comment: > And D isn't how you shut down the interpreter on Windows, is it? No Z + is the equivalent (D does nothing under Windows, except "printing" ^D). And in a cmd window it just print another prompt (that's strange that it doesn't exit by the way...). Also, I was thinking about the issue, is it normal to have this crash when we close directly the fd 0, whereas if I do sys.stdin.close() (which has sys.stdin.fileno() == 0) the Python shell continues to work properly? -- ___ Python tracker <http://bugs.python.org/issue14433> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14433] Python 3 interpreter crash on windows when stdin closed in Python shell
Alexis Daboville added the comment: @Amaury: ok thanks, I never heard of this argument before. I tried to reproduce the crash in the Python shell embedded in IDLE and there's no crash (same version 3.2.2, Windows 7): http://i.imgur.com/ayT96.png -- ___ Python tracker <http://bugs.python.org/issue14433> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14915] pysetup may leave a package in a half-installed state
Alexis Metaireau added the comment: Oh, a potential way to avoid this would be to check that the metadata have the python 3 trove classifier in it. We could also add a way to force the installation even if the right classifier is not present with a special flag passed to the command line. Does this sounds like an acceptable change to you? -- ___ Python tracker <http://bugs.python.org/issue14915> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14946] packaging’s pysetup script should be named differently than distutils2’s pysetup
Alexis Metaireau added the comment: Good catch, One solution would be to have the pysetup script name suffixed by the version of python is comes with. For instance, for python 3.3 it would be "pysetup3.3" (that's how it is atm). This means that "pysetup" would point to "pysetup3.3" after a fresh python install, but distutils2 could change this and propose a different version of pysetup. The 3.3 version would still be available but under "pysetup3.3". -- ___ Python tracker <http://bugs.python.org/issue14946> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14948] setup.cfg - rename home_page to homepage
Alexis Metaireau added the comment: While I kind of agree with you, this field is proposed by the PEP 345 and had been approved as it is. It seems probably better to stick with what's defined there mainly because any change to the PEP is a heavy process and we won't have time to go trough it before the 3.3 release. (See http://www.python.org/dev/peps/pep-0345/#home-page-optional) -- ___ Python tracker <http://bugs.python.org/issue14948> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14949] Documentation should state clearly the differences between "pysetup run install_dist" and "pysetup install"
New submission from Alexis Metaireau : The packaging tutorial currently talks about "pysetup run install_dist" and "pysetup install" which aren't doing the same thing: one fetches the dependencies while the other doesn't. This should be stated clearly. -- assignee: eric.araujo components: Distutils2 keywords: easy messages: 161867 nosy: alexis, eric.araujo, tarek priority: normal severity: normal status: open title: Documentation should state clearly the differences between "pysetup run install_dist" and "pysetup install" versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue14949> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14950] packaging.install does not have a clear API.
New submission from Alexis Metaireau : The "packaging.install" module doesn't have a clear API defined and it's doing a lot of indirections between all the functions to get metadata, fetch the dependencies and install what's need to be installed. We might be able to come with a better solution for the API we expose there, and to allow easier maintenance. I'll go ahead this week and propose a change to this module which hopefully will make things clearer. -- assignee: alexis components: Distutils2 messages: 161868 nosy: alexis, tarek priority: normal severity: normal status: open title: packaging.install does not have a clear API. type: enhancement versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue14950> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12355] Crawler doesn't follow redirection
Alexis Metaireau added the comment: Did someone changed anything in the codebase regarding this (or did it solved itself magically?) -- ___ Python tracker <http://bugs.python.org/issue12355> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14949] Documentation should state clearly the differences between "pysetup run install_dist" and "pysetup install"
Alexis Metaireau added the comment: That would be helpful yep. I can add this in the docs if you've not done it already. -- ___ Python tracker <http://bugs.python.org/issue14949> ___ ___ 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
Alexis Metaireau added the comment: I'm +1 on this. Having an "install" command, on a distribution, makes more sense than having an "install_dist" one, because of course the object is a distribution! -- ___ Python tracker <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 Alexis Metaireau : -- stage: -> needs patch ___ Python tracker <http://bugs.python.org/issue13160> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12779] Update packaging documentation
Alexis Metaireau added the comment: I think it could be helpful to have this work at least somewhere so we can work on top of it. For instance if someone wants to do changes in the documentation, then only thing it would do now would be to cause potential merge conflicts. I'm okay to have several commits for this, as it would allow us to work on the documentation with more than one person (theoretically at least). Plus I really want to see those changes! -- ___ Python tracker <http://bugs.python.org/issue12779> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14899] Naming conventions and guidelines for packages and namespace packages
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue14899> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14974] rename packaging.pypi to packaging.index
New submission from Alexis Metaireau : PyPI is the name of a particular index, whereas "index" is a generic term. So ISTM that it would be better to use the latter, semantically-wise. -- assignee: alexis components: Distutils2 messages: 162027 nosy: alexis, tarek priority: normal severity: normal stage: needs patch status: open title: rename packaging.pypi to packaging.index type: enhancement versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue14974> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14974] rename packaging.pypi to packaging.index
Alexis Metaireau added the comment: We are all calling these indexes quite everywhere. We are talking about a Python Package Index and even the mirroring infrastructure is talking about indexes. Because that's under the "packaging" namespace, it's kind of obvious that this deals with indexes "like PyPI". Of course, we also have the documentation which is a good starting point to make people realize what this is about; but I really don't think naming this "index" will be a blocker for anyone. -- ___ Python tracker <http://bugs.python.org/issue14974> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14974] rename packaging.pypi to packaging.index
Alexis Metaireau added the comment: The problem is that PyPI isn't a good name since it's the name of ONE index. Westley, do you have any other idea? Otherwise, I think we should stick to "index", which is a good name for something that's named "index" quite everywhere already. Especially because it's living under the "packaging" namespace. -- ___ Python tracker <http://bugs.python.org/issue14974> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12354] packaging.pypi.simple docs use both client and crawler name, which might be confusing
Alexis Metaireau added the comment:
> Alexis, you introduced the client/crawler naming after reading some book;
> what do you think now?
Making the distinction between a crawler and a client is probably not a
good idea since it introduces two concepts instead of one simple one.
We have indexes and different ways to access them: What about having an
"XMLRPCClient" and a "SimpleClient"?
In addition, having a simpler API, something like
packaging.indexes.get_client('simple' OR 'xmlrpc') can be useful, but
that's a different issue.
--
___
Python tracker
<http://bugs.python.org/issue12354>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14950] Make packaging.install API less confusing and more extensible
Alexis Metaireau added the comment: Attaching a work in progress file which intend to replace the current install.py file. The implementation isn't finished yet but the overall design is here. It comes with four classes: - Installer which manages the overall installation procedure. It shares a distribution cache with the dependency handler so distributions are not downloaded / extracted multiple times. The installer is able to install / remove single distributions OR distributions with their dependency tree. - DependencyHandler which takes care about getting the dependencies from either the metadata stored in the indexes or inside the distirbutions. - The DistributionCache class is just a store containing the location of the distributions that had been extracted/downloaded. It provides methods to ease the work with them (so any external user don't need to care about the state of the distribution when requesting it). - DirectoryMover provides a way to deal with moving/deleting operations with a commit/rollback API. The goal is to simplify a lot the current API and to provide a reusable tool for other installers. why not putting this in shutil at some point. This file is provided here mostly for feedback, but the work is not finished yet. -- Added file: http://bugs.python.org/file25831/install.py ___ Python tracker <http://bugs.python.org/issue14950> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3754] cross-compilation support for python build
Changes by Alexis Metaireau : -- nosy: -alexis ___ Python tracker <http://bugs.python.org/issue3754> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1596321] KeyError at exit after 'import threading' in other thread
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue1596321> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16527] (very) long list of elif causes segfault
New submission from Alexis Daboville: Hi, It looks like using a very long list of elif makes CPython segfault. You can try it with the attached file, which looks like this: if False: pass elif False: pass # thousands of elifs elif False: pass $ python elif_segfault.py Segmentation fault. CPython versions tested: 3.x (all segfaults): 3.1 on Debian 3.2 on Arch Linux 3.3 on Windows 2.6 on Debian: segfaults with a longer list of elifs than the one in the attached file. The PyPy behaviour seems better: it raises 'RuntimeError: maximum recursion depth exceeded'. A possible cause (if I understood <http://greentreesnakes.readthedocs.org/en/latest/nodes.html#If> well) is that there are no elif nodes in the AST, elif are just plain ifs which are stored recursively in the else part of the previous if. (I'm not sure if that's an issue as it's not a real use case, but it makes CPython segfault and I was advised on #python-fr to report it anyway.) -- files: elif_segfault.py messages: 176081 nosy: alexis.d priority: normal severity: normal status: open title: (very) long list of elif causes segfault versions: Python 3.1, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file28068/elif_segfault.py ___ Python tracker <http://bugs.python.org/issue16527> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16527] (very) long list of elif causes segfault
Changes by Alexis Daboville : -- components: +Interpreter Core type: -> crash ___ Python tracker <http://bugs.python.org/issue16527> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16527] (very) long list of elif causes segfault
Alexis Daboville added the comment: I had the feeling that there was a possible issue when reading how elifs were represented in the AST. I'm not insane enough to write so many elifs in a real program ;). I totally agree on the 'nice to have' part rather than 'required'. -- ___ Python tracker <http://bugs.python.org/issue16527> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16527] (very) long list of elif causes segfault
Alexis Daboville added the comment:
I don't think it can be "fixed" with sys.setrecursionlimit for a few reasons:
* I think the issue arises when the AST is built. Otherwise if we put code
before the if it would execute. But that's not the case (try putting a
print('hello') before the if and it won't print anything).
- This also means that you cannot directly call sys.setrecursionlimit in the
file with the elifs.
- Though we can set recursion limit using a second file which will then
import the elifs file: I tried with different limits and CPython still crash in
the same way (and always with the same number of elifs, roughly, because I
didn't binary search for the exact amount of elifs).
- sys.setrecursionlimit controls the stack size of the running Python
program, while here we break C stack directly before running Python bytecode.
* When recursion limit is hit, an exception is raised, there's no segfault:
>>> def f():
... f()
...
>>> f()
# plenty of omitted lines
RuntimeError: maximum recursion depth exceeded
>>>
* Having a RuntimeError raised would be nice, though 'maximum recursion depth
exceeded' may not be the best possible error message as from a 'Python user'
POV there's no recursion here.
---
A possible solution would be, I guess, to store elifs as excepts are stored.
Instead of storing elifs recursively, the else part would just contain a list
of if nodes (and if there is a else, well just store an if True node).
Though I don't know how difficult it would be to implement that, or if it's
likely to break a lot of things which relies on ifs/elifs to be stored that way.
--
___
Python tracker
<http://bugs.python.org/issue16527>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19168] pprint.pprint(..., compact=True) not implemented
New submission from Alexis Layton: Documentation for 3.4 states that the compact keyword-only argument has been added to 3.4. However: Python 3.4.0a3 (default, Oct 2 2013, 14:05:02) [GCC 4.6.3] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import pprint >>> pprint(3, compact=True) Traceback (most recent call last): File "", line 1, in TypeError: 'module' object is not callable >>> pprint.pprint(3, compact=True) Traceback (most recent call last): File "", line 1, in TypeError: pprint() got an unexpected keyword argument 'compact' >>> -- components: Library (Lib) messages: 198969 nosy: AlexisLayton priority: normal severity: normal status: open title: pprint.pprint(..., compact=True) not implemented type: behavior versions: Python 3.4 ___ Python tracker <http://bugs.python.org/issue19168> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19479] textwrap.dedent doesn't work properly with strings containing CRLF
New submission from Alexis Daboville:
If a string contains an empty line and is using CRLF newlines instead of LF
newlines textwrap.dedent doesn't work properly: it returns the original string
w/o dedenting it.
As far as I can tell it's because it considers the empty string to be the
longest common indent
(http://hg.python.org/cpython/file/2.7/Lib/textwrap.py#l372, '[^ \t\n]' matches
'\r').
Expected behavior: textwrap.dedent should work the same way whether lines are
separated by a single LF character or by CRLF.
To repro:
✓ 15:26 dabovill @ morag in /tmp/dedent $ cat dedent.py
import textwrap
lf = '\ta\n\tb\n\n\tc'
crlf = '\ta\r\n\tb\r\n\r\n\tc'
print('- lf')
print(lf)
print('- dedent(lf)')
print(textwrap.dedent(lf))
print('- crlf')
print(crlf)
print('- dedent(crlf)')
print(textwrap.dedent(crlf))
✓ 15:26 dabovill @ morag in /tmp/dedent $ python2.7 dedent.py
- lf
a
b
c
- dedent(lf)
a
b
c
- crlf
a
b
c
- dedent(crlf)
a
b
c
✓ 15:26 dabovill @ morag in /tmp/dedent $ python3.3 dedent.py
- lf
a
b
c
- dedent(lf)
a
b
c
- crlf
a
b
c
- dedent(crlf)
a
b
c
--
components: Library (Lib)
messages: 201975
nosy: alexis.d
priority: normal
severity: normal
status: open
title: textwrap.dedent doesn't work properly with strings containing CRLF
type: behavior
versions: Python 2.7, Python 3.3
___
Python tracker
<http://bugs.python.org/issue19479>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue19479] textwrap.dedent doesn't work properly with strings containing CRLF
Alexis Daboville added the comment: Added patch. -- keywords: +patch Added file: http://bugs.python.org/file32519/dedent.patch ___ Python tracker <http://bugs.python.org/issue19479> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20512] Python3.3 segfaults when using big5hkscs encoding
New submission from Alexis Daboville:
When using the 'big5hkscs' encoding it's possible to make Python3.3 segfault,
here is how to repro:
✗ 13:41 adaboville @ adoboville-mbp in ~ $ py3
Python 3.3.2 (v3.3.2:d047928ae3f6, May 13 2013, 13:52:24)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> 'nb'.encode('big5hkscs')
b'nb'
>>> 'nb'.encode('big5hkscs')
Segmentation fault: 11
Note that it doesn't crash on the first first line, but on the second (even
though both lines are the same). FWIW pypy3.3 doesn't crash:
✓ 13:43 adaboville @ adoboville-mbp in .../pypy3-2.1-beta1-osx64 $ bin/pypy
Python 3.2.3 (d63636b30cc0, Jul 30 2013, 07:02:48)
[PyPy 2.1.0-beta1 with GCC 4.2.1 Compatible Clang Compiler] on darwin
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``why did you guys have to make the
builtin fortune more interesting than actual work? i just catched myself
restarting pypy 20 times''
>>>> 'nb'.encode('big5hkscs')
b'nb'
>>>> 'nb'.encode('big5hkscs')
b'nb'
>>>>
--
messages: 210258
nosy: alexis.d
priority: normal
severity: normal
status: open
title: Python3.3 segfaults when using big5hkscs encoding
type: crash
versions: Python 3.3
___
Python tracker
<http://bugs.python.org/issue20512>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue20512] Python3.3 segfaults when using big5hkscs encoding
Alexis Daboville added the comment: @David: yes, 10.9. -- ___ Python tracker <http://bugs.python.org/issue20512> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7705] libpython2.6.so is not linked correctly on FreeBSD when threads are enabled
New submission from Alexis Ballier : As reported in https://bugs.gentoo.org/show_bug.cgi?id=300961 : # gcc foo.c -lpython2.6 /usr/lib/gcc/i686-gentoo-freebsd7.2/4.4.2/../../../libpython2.6.so: undefined reference to `pthread_create' collect2: ld returned 1 exit status libpython2.6.so doesn't get linked with -pthread; I'll attach a patch fixing this, the configure script does its magic but doesn't reuse that magic for setting LDSHARED. -- components: Build files: python_fbsd_pthread.patch keywords: patch messages: 97800 nosy: aballier severity: normal status: open title: libpython2.6.so is not linked correctly on FreeBSD when threads are enabled versions: Python 2.6 Added file: http://bugs.python.org/file15890/python_fbsd_pthread.patch ___ Python tracker <http://bugs.python.org/issue7705> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8190] Add a PyPI XML-RPC client module
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue8190> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4908] Implement PEP 376
Changes by Alexis Metaireau : -- nosy: +alexis ___ Python tracker <http://bugs.python.org/issue4908> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
