[issue11715] Building Python on multiarch Debian and Ubuntu
Nick Coghlan ncogh...@gmail.com added the comment: I'm not sure this is 100% fixed. After dist-upgrading the Kubuntu VM on my netbook and updating to the latest Py3k code, I got a lot of test errors, even after a make distclean and ./configure. The errors went away after manually tweaking LDFLAGS as Christian describes here: http://lipyrary.blogspot.com/2011/05/how-to-compile-python-on-ubuntu-1104.html -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11715 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12775] immense performance problems related to the garbage collector
New submission from Daniel Svensson dsvens...@gmail.com: I've noticed problems with the GC in two applications. In one case the application did not respond to SOAP-requests for 9 seconds, every couple of minutes, when it really shouldn't have taken more than 20ms. In another case we had one operation executed by 20 threads that ought to have taken 0.5 seconds, but instead took about 90 seconds. Both cases were solved by disabling the garbage collector and hunting down possible circular references. Once this was done, the first example went down to its expected 20ms max latency, and the second one to its 0.5s processing time. Here is a short python script that demonstrates the issue, the JSON file in this case is 1.2GB large: import cjson, time, gc def read_json_blob(): t0 = time.time() fd = file(mytestfile) data = fd.read() fd.close() t1 = time.time() parsed = cjson.decode(data) t2 = time.time() print read file in %.2fs, parsed json in %.2fs, total of %.2fs % \ (t1-t0, t2-t1, t2-t0) read_json_blob() read file in 10.57s, parsed json in 531.10s, total of 541.67s gc.disable() read_json_blob() read file in 0.59s, parsed json in 15.13s, total of 15.72s gc.collect() 0 I don't understand how Python can work like this default, at least not without a warning, to me it looks like a joke gone too far. All documentation ought to recommend people to disable the garbage collector at the first sign of performance problems, or the garbage collector problem should be fixed, this the Documentation or Interpreter Core Components in the ticket classification. -- assignee: docs@python components: Documentation, Interpreter Core messages: 142305 nosy: docs@python, dsvensson priority: normal severity: normal status: open title: immense performance problems related to the garbage collector type: performance versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12772] fractional day attribute in datetime class
Changes by Daniel Urban urban.dani...@gmail.com: -- nosy: +durban versions: +Python 3.3 -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12772 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12775] immense performance problems related to the garbage collector
Changes by Daniel Urban urban.dani...@gmail.com: -- nosy: +durban ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
New submission from Arnaud Fontaine ar...@debian.org: When specifying a function to be called in type keyword argument of add_argument(), the function is actually called twice (when a default value is set and then when the argument is given). While this may not be a problem in most cases (such as converting to an int for example), it is an issue for example when trying to open a file whose filename is given as a default value but is not accessible for whatever reason because the first call will fail whereas only the second should be done. I know this may sound like a twisted example but the type function should not be called twice anyhow IMHO. I tested with Python 2.7 and 3.2 from Debian packages only but the bug seems to be present in py3k and 2.7 hg branches as well. I have attached a small script showing the issue and two patches (for 2.7 and tip (py3k) hg branches), including an additional test case. All argparse tests pass well with 2.7 and 3.2. Hope that's ok. -- components: Library (Lib) files: example-argparse-type-function-called-twice.py messages: 142306 nosy: arnau priority: normal severity: normal status: open title: argparse: type conversion function should be called only once type: behavior versions: Python 2.7, Python 3.2 Added file: http://bugs.python.org/file22926/example-argparse-type-function-called-twice.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12776 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine ar...@debian.org: -- keywords: +patch Added file: http://bugs.python.org/file22927/py2.7-argparse-call-type-function-once.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12776 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Arnaud Fontaine ar...@debian.org: Added file: http://bugs.python.org/file22928/py3k-argparse-call-type-function-once.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12776 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12767] document threading.Condition.notify
Antoine Pitrou pit...@free.fr added the comment: I asked the user who reported this documentation omission what he's using the 'n' argument for. His reply: Yes I am using the n parameter, it is mainly to implement a subclass of Queue that supports bulk get and put operations. This enhances the performance of repeated get/put calls when the Queue is created using multiprocessing.Manager. I think it's fine to document it. It's been there for a long time. Besides, if we know how to notify one thread, we are certainly able to notify n of them :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12767 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3871] cross and native build of python for mingw32 with distutils
Changes by Kalev Lember kalevlem...@gmail.com: -- nosy: +kalev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3871 ___ ___ 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 Kalev Lember kalevlem...@gmail.com: -- nosy: +kalev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3754 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12760] Add create mode to open()
Antoine Pitrou pit...@free.fr added the comment: The #ifdef O_EXCL in the source code is probably very old. Copying a message I posted on python-ideas: O_EXCL is a POSIX standard. It is also supported under Windows by the _open/_wopen compatibility functions (which we use for file I/O). Probably there are very old systems which don't support it, and perhaps new systems that don't implement it *correctly* (meaning not atomically); for the former I'd say we just don't care (who's gonna run Python 3 on a 1995 system?) and for the latter, well, if the OS designers think it's fine, let's just expose it as it is. As for NFS, there's an interesting comment from 2007 here: http://lwn.net/Articles/251971/ “My NFS tester shows that it at least appears to work with Linux, Solaris and FreeBSD: http://www.dovecot.org/list/dovecot/2007-July/024102.html. Looking at Linux 2.6 sources it doesn't look like it tries to implement a racy O_EXCL check in client side (fs/nfs/nfs3proc.c nfs3_proc_create()), so the test's results should be correct. I don't know if other OSes do that. I guess it would be nice to have a better O_EXCL tester which tries to catch race conditions.” -- assignee: docs@python - components: -Documentation, Tests nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12760 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12760] Add create mode to open()
David Townshend aquavita...@gmail.com added the comment: My aim isn't to add all the commonly used flags, that would be pointless since its already possible using os.open. The aim is to add a missing feature to the builtin open(), i.e. file creation. At the moment open() implements read, write, and append, and creation is only implied by write. But in many cases, an explicit creation is desired (i.e, specifically create a new file, with an exception on failure). It is true that this is possible with os.open, but it is somewhat obscure, especially for beginners, and is not as easy to read as open(file, 'c') -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12760 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9850] obsolete macpath module dangerously broken and should be removed
Oleg Oshmyan chor...@inbox.lv added the comment:
I fully agree with Ronald’s proposal. And for a start, here is a trivial patch
that fixes macpath.join('', ...) [at the moment it just returns its last
argument]. By the way, this fix is probably eligible for inclusion in
Python 2.7 too.
I also have ‘implement macpath.relpath’ in my to-do list, although in practice
this means nothing.
--
keywords: +patch
nosy: +chortos
Added file: http://bugs.python.org/file22929/macpath_join_fix.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9850
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12775] immense performance problems related to the garbage collector
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: Which version of Python did you test with? Can you try with version 3.2? -- nosy: +amaury.forgeotdarc ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12775] immense performance problems related to the garbage collector
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12775] immense performance problems related to the garbage collector
STINNER Victor victor.stin...@haypocalc.com added the comment: Can you try to write a short example to reproduce the problem? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Charles-François Natali neolo...@free.fr added the comment: My question too! I would say that stable releases should probably not get this change, but should force sys.platform to linux2 on 3.x kernels. The point is precisely that we don't change anything: applications checking against sys.platform are already broken, there's no reason to comfort them into using this defective check. The applications that encountered the problem (chromium, matplotlib and probably others) already performed the change to sys.platform.startswith(), so it's really the only way to go. BTW, does anybody think sys.platform should use a more dynamic approach for calculating its value? Well, maybe not necessary if Python 3.3 will just say 'linux'. There's already platform.system() for that. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12760] Add create mode to open()
Charles-François Natali neolo...@free.fr added the comment: The #ifdef O_EXCL in the source code is probably very old. Copying a message I posted on python-ideas: O_EXCL is a POSIX standard. It is also supported under Windows by the _open/_wopen compatibility functions (which we use for file I/O). If it's supported by Windows then I'm OK (not that I personaly care about Windows :-). and is not as easy to read as open(file, 'c') Well, I'd rather have this flag called 'x', to be consistent with glibc's fopen(): c (since glibc 2.3.3) Do not make the open operation, or subsequent read and write operations, thread cancellation points. x Open the file exclusively (like the O_EXCL flag of open(2)). If the file already exists, fopen() fails, and sets errno to EEXIST. This flag is ignored for fdopen(). By the way, could you submit your patch as a mercurial diff (hg diff)? It makes it easier to review under Rietveld. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12760 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12760] Add create mode to open()
David Townshend aquavita...@gmail.com added the comment: Changing form 'c' to 'x' is easy enough, and if there is already a convention it makes sense to stick to it. I thought I had done a mercurial diff! I'll try again and resubmit. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12760 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9200] Make str methods work with non-BMP chars on narrow builds
Ezio Melotti ezio.melo...@gmail.com added the comment: The attached patch fixes all the str.is* methods and makes them work on narrow builds with non-BMP chars. It also includes the _Py_UNICODE_NEXT macro proposed in #10542. -- Added file: http://bugs.python.org/file22930/issue9200.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9200 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Ezio Melotti ezio.melo...@gmail.com added the comment: I attached a patch to fix the str.is* methods on #9200 that also includes the macro. Since they are not public there, I don't see a reason to do 2 separate commits on 2.7/3.2 (one for the feature and one for the fix). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10542 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9200] Make str methods work with non-BMP chars on narrow builds
Ezio Melotti ezio.melo...@gmail.com added the comment:
(Note: I copied the macros from the other patch without changing the name. If
the approach is good I'll get rid of the prefixes and separate the words in
IS{HIGH|LOW}SURROGATE with an _.)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9200
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9200] Make str methods work with non-BMP chars on narrow builds
Changes by Ezio Melotti ezio.melo...@gmail.com: Removed file: http://bugs.python.org/file22930/issue9200.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9200 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9200] Make str methods work with non-BMP chars on narrow builds
Changes by Ezio Melotti ezio.melo...@gmail.com: Added file: http://bugs.python.org/file22931/issue9200.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9200 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12775] immense performance problems related to the garbage collector
Charles-François Natali neolo...@free.fr added the comment: There's been some work done on the GC some time ago to address this type of pattern (I think to reduce from quadratic complexity to amortized linear complexity). I'm adding Antoine and Martin who were involved in this. Here is a short python script that demonstrates the issue, the JSON file in this case is 1.2GB large: A couple remarks: - please indicate the Python version you're using - you should put your test in a script, one with gc.disable() at the top, to avoid using any cache that might be used internally by cjson - you should perform echo 3 /proc/sys/vm/drop_cache before each run to make sure you start with a cold page/buffer cache (see how fast your file got read the second time you called read_json_blob()?) -- nosy: +loewis, neologix, pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12760] Add create mode to open()
Julian Berman julian+python@grayvines.com added the comment: A minor documentation error in io.rst line 475 which was changed to: + The *mode* can be ``'c'``, ``'r'``, ``'w'`` or ``'a'`` for reading + (default), writing, or appending. and should have creating at the front I assume, like you have it later. -- nosy: +Julian ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12760 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12760] Add create mode to open()
Antoine Pitrou pit...@free.fr added the comment: Well, I'd rather have this flag called 'x', to be consistent with glibc's fopen(): c (since glibc 2.3.3) Do not make the open operation, or subsequent read and write operations, thread cancellation points. x Open the file exclusively (like the O_EXCL flag of open(2)). If the file already exists, fopen() fails, and sets errno to EEXIST. This flag is ignored for fdopen(). Yeah, but I think exclusively is quite misleading since it does not perform any locking of any kind. Also, I don't think we'll ever integrate the glibc's c option in io.open(). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12760 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] packaging: generate scripts from callable (dotted paths)
higery shoulderhig...@gmail.com added the comment: IIUC the support for setup.py is transitional, i.e. legacy support, for existing packages transitioning from distutils/setuptools/Distribute to packaging. New features should not rely on the existence of setup.py. I know, the implementation way of scripts has nothing to do with the setup.cfg or setup.py, these two files are just different ways to offer configuration values. So just don't worry about that. What the I try to express here is : There are two kinds of configuration files supported in Packaging, and you can say it maybe a transition consideration from distutils/setuptools to Packaging, but if you look into the documents of Packaging(you can generate it from the /Doc directory), you will get to know that Packaging has a more further and important consideration - setup.cfg and setup.py place different roles in a project, setup.py offers developers to set while setup.cfg offers users to edit in a cheap and easy way... Certainly you can set anyone of these two files to reach the same goal. Just visit /Doc/build/html/packaging/configfile.html to know more about the different roles of these two configuration files. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12394 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] packaging: generate scripts from callable (dotted paths)
higery shoulderhig...@gmail.com added the comment: BTW higery, did you use any of the build-scripts functionality I developed in the pythonv branch? NO. I removed the 'copy_scripts' function, so I did not use your developed functionality. After this change, Packaging module now just builds new-style scripts and old-style scripts will be built by distutils/setuptools. To support the old-style scripts generated by d*/s* in p*, we can use the resource system. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12394 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12775] immense performance problems related to the garbage collector
Antoine Pitrou pit...@free.fr added the comment: As Charles-François said: it would be nice to know which Python version you are using. Also, if you could test with 2.7 or 3.2 and the standard json module (or the latest simplejson if you prefer). Also, while Python's performance is not always excellent, it is quite rare for it to be GC-limited, so the advice you are suggesting we give would be misleading for most use cases. Note that instead of disabling the GC, you can tune its parameters by calling set_threshold. For example: u, v, w = gc.get_threshold() gc.set_threshold(u, v * 10, w * 50) (this will make full collections occur 500 times less often) Or you could disable the GC only when decoding JSON data and reenable it afterwards. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12775 ___ ___ 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/file22932/af7d14ff129b.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
[issue12777] Inconsistent use of VOLUME_NAME_* with GetFinalPathNameByHandle
New submission from Antoine Pitrou pit...@free.fr: In the implementation of nt._getfinalpathname() (in posixmodule.c) we have: /* We have a good handle to the target, use it to determine the target path name. */ buf_size = Py_GetFinalPathNameByHandleW(hFile, 0, 0, VOLUME_NAME_NT); [...] result_length = Py_GetFinalPathNameByHandleW(hFile, target_path, buf_size, VOLUME_NAME_DOS); There doesn't seem to be a good reason to use VOLUME_NAME_NT in the first call and VOLUME_NAME_DOS in the second. Especially given the second call might require more characters than the first call, and therefore return a truncated path. -- components: Library (Lib) messages: 142325 nosy: brian.curtin, pitrou, tim.golden priority: low severity: normal status: open title: Inconsistent use of VOLUME_NAME_* with GetFinalPathNameByHandle type: behavior versions: Python 3.2, Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12777 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12777] Inconsistent use of VOLUME_NAME_* with GetFinalPathNameByHandle
Brian Curtin br...@python.org added the comment: Adding Jason - I'll dig around for it, but I think I brought this up in the past and I seem to remember him having a justification for it. (apologies if I'm thinking of something else) -- nosy: +jason.coombs ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12777 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12775] immense performance problems related to the garbage collector
Daniel Svensson dsvens...@gmail.com added the comment: The bug note contains a test script. You just have to generate a huge JSON-blob, or allocate 1 GB or so and pickle it down to file and replace the cjson.decode to pickle.loads, pickle is about 20 times faster without GC. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12775] immense performance problems related to the garbage collector
Daniel Svensson dsvens...@gmail.com added the comment: Or you could disable the GC only when decoding JSON data and reenable it afterwards. JSON was just an example, and disabling/enabling the GC is not safe in a multithreaded environment? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12775 ___ ___ 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
higery shoulderhig...@gmail.com added the comment: Through discussing inside or outside the mailing list on this bug tracker, current 'develop' has been made a kind of command other than an action. But there still isn't a consensus of the concrete implemention way, so I keep this command name as 'develop' and the simple usage of this command is : pysetup run develop BTW, most developers in this list have agreed that 'develop' is a kind of install command, so I also add an entry funtion 'install_editable' for it, like 'install_local_project' for the 'install_dist' command. In addition, current patch also supports several ways to run the 'develop' which is learned from the source code of install.py. When installing, there are three ways, '_run_packaging_install', '_run_setuptools_install', and '_run_distutils_install', so here for develop command, there are two ways, '_run_packaging_develop' and '_run_setuptools_develop'. You can know more through the source code and docs in this patch. BTW, should way convert the .egg-info directory to .dist-info directory? -- ___ 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
[issue12777] Inconsistent use of VOLUME_NAME_* with GetFinalPathNameByHandle
Jason R. Coombs jar...@jaraco.com added the comment: I agree the two calls should probably be consistent, though I also suspect that VOLUME_NAME_NT is always longer than VOLUME_NAME_DOS. My justification for using VOLUME_NAME_NT is that the final name might not be located on a DOS-accessible name. My suspicion was that VOLUME_NAME_NT was more general purpose (though somewhat less user-friendly), so preferable in the case that the name isn't exposed to the user. It's been a while since I've investigated it, but I think you can have symlinks to UNC paths as well as \\?\ paths, so my concern is VOLUME_NAME_DOS might not work with those paths. Some tests are probably called for. In the case of nt._getfinalpathname(), it's not obvious to me how it might be used, so VOLUME_NAME_DOS may be more appropriate. Or perhaps _getfinalpathname should pass that parameter through. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12777 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12775] immense performance problems related to the garbage collector
Antoine Pitrou pit...@free.fr added the comment: The bug note contains a test script. You just have to generate a huge JSON-blob, or allocate 1 GB or so and pickle it down to file and replace the cjson.decode to pickle.loads, pickle is about 20 times faster without GC. You can't say that any huge JSON blob will exhibit the same performance characteristics as yours. I just tested json.loads() with a rather trivial 300MB JSON string, and it took a couple of seconds (on 2.7). Does it reproduce your workload? I don't know. disabling/enabling the GC is not safe in a multithreaded environment? You are right that disabling/enabling the GC is a global setting. But that still leaves the option of tuning the parameters. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12760] Add create mode to open()
Charles-François Natali neolo...@free.fr added the comment:
Yeah, but I think exclusively is quite misleading since it does not
perform any locking of any kind.
It might be misleading, but I find it clear enough, and this name has been
endorsed by POSIX.
Furthermore, there's an added bonus: actually, with the old I/O layer, one can
already pass an 'x' flag to open, since it just calls fopen:
cf@neobox:~$ strace -e open python -c open('/tmp/foo', 'wx')
[...]
open(/tmp/foo, O_WRONLY|O_CREAT|O_EXCL|O_TRUNC|O_LARGEFILE, 0666) = 3
cf@neobox:~$ strace -e open python -c open('/tmp/foo', 'wx')
[...]
open(/usr/lib/pymodules/python2.6/string, O_RDONLY|O_LARGEFILE) = -1 ENOENT
(No such file or directory)
IOError: [Errno 17] File exists: '/tmp/foo'
I don't know if it's documented behavior, but the OP in issue 12105 was using
it with python 2.
Changing it to 'x' would make such code backward-compatible.
Finally, when I read open('/tmp/foo', 'wx'), it's immediately clear to me
what's going on, while I'd have to look at open()'s documentation to find out
what the 'c' flag does.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12760
___
___
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 ale...@notmyidea.org 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 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
[issue8668] Packaging: add a 'develop' command
Alexis Metaireau ale...@notmyidea.org 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 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
[issue12760] Add create mode to open()
STINNER Victor victor.stin...@haypocalc.com added the comment: I don't know if it's documented behavior See #12103: it is not documented. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12760 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12777] Inconsistent use of VOLUME_NAME_* with GetFinalPathNameByHandle
Antoine Pitrou pit...@free.fr added the comment: That's slightly off-topic, but is it enough to strip the leading '\\?\' (and replace 'UNC' with '\'), or are there other things to watch out for? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12777 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12650] Subprocess leaks fd upon kill()
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 9ee802642d86 by Charles-François Natali in branch '2.7': Issue #12650: Fix a race condition where a subprocess.Popen could leak http://hg.python.org/cpython/rev/9ee802642d86 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12650 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12778] JSON-serializing a large container takes too much memory
New submission from Antoine Pitrou pit...@free.fr: On a 8GB RAM box (more than 6GB free), serializing many small objects can eat all memory, while the end result would take around 600MB on an UCS2 build: $ LANG=C time opt/python -c import json; l = [1] * (100*1024*1024); encoded = json.dumps(l) Traceback (most recent call last): File string, line 1, in module File /home/antoine/cpython/opt/Lib/json/__init__.py, line 224, in dumps return _default_encoder.encode(obj) File /home/antoine/cpython/opt/Lib/json/encoder.py, line 188, in encode chunks = self.iterencode(o, _one_shot=True) File /home/antoine/cpython/opt/Lib/json/encoder.py, line 246, in iterencode return _iterencode(o, 0) MemoryError Command exited with non-zero status 1 11.25user 2.43system 0:13.72elapsed 99%CPU (0avgtext+0avgdata 27820320maxresident)k 2920inputs+0outputs (12major+1261388minor)pagefaults 0swaps I suppose the encoder internally builds a large list of very small unicode objects, and only joins them at the end. Probably we could join it by chunks so as to avoid this behaviour. -- messages: 142338 nosy: ezio.melotti, pitrou, rhettinger priority: normal severity: normal status: open title: JSON-serializing a large container takes too much memory type: resource usage versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12757] undefined name in doctest.py
Michele Orrù maker...@gmail.com added the comment: It is possible to retrieve the current module using _normalize_module(None), or instead use the test name (dt_test.name) just like in DocTestCase.shortDescription. Since there is no doc about it, IMHO we should use unittest's standard as guideline, which is: shortDescription() Returns a description of the test, or None if no description has been provided. The default implementation of this method returns the first line of the test method’s docstring, if available, or None. (i.e., DocTestCase._dt_test.name) What's your opinion? -- nosy: +maker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12757 ___ ___ 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
higery shoulderhig...@gmail.com added the comment: Alexis Metaireau ale...@notmyidea.org added the comment: I'm not sure why you're talking about it in the context of develop, can you clarify this? My consideration is : if in Packaging we always convert .egg-info directory to .dist-info directory, then my two different kinds of ways(setuptools' develop or packaging's develop) for the 'develop' command are unnecessary, we can just retain the new-style packaging's develop, which mean '_run_packaging_develop' function here. -- ___ 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
[issue8668] Packaging: add a 'develop' command
Alexis Metaireau ale...@notmyidea.org 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 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
[issue12394] packaging: generate scripts from callable (dotted paths)
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: There are two kinds of configuration files supported in Packaging, and you can say it maybe a transition consideration from distutils/setuptools to Packaging, but if you look into the documents of Packaging(you can generate it from the /Doc directory), you will get to know that Packaging has a more further and important consideration - setup.cfg and setup.py place different roles in a project, setup.py offers developers to set while setup.cfg offers users to edit in a cheap and easy way... Certainly you can set anyone of these two files to reach the same goal. I think I understand that much. The point of setup.cfg is to do away with the completely ad-hoc nature of code that developers can put into setup.py, which prevents playing nicely with distro package managers. I'm fairly sure I've seen Tarek say that for developers, no more setup.py - in fact, I've just found where he said it: http://tarekziade.wordpress.com/2011/05/22/packaging-has-landed-in-the-stdlib/ and also http://pycon.tv/#/video/57 (at around 6:55 into the video, and at 8:30 - there is no more setup.py - meaning in the new way of doing things) So the role of setup.py is historical, and the way developers customise installations is through using hooks. These work well enough, and I am currently using them in the nemo project which is a companion to the pythonv branch - see http://www.red-dove.com/screencasts/pythonv/pythonv.html -- Added file: http://bugs.python.org/file22933/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12394 ___htmlbodydiv style=color:#000; background-color:#fff; font-family:tahoma, new york, times, serif;font-size:10ptdiv id=yiv159912332div style=color: rgb(0, 0, 0); background-color: rgb(255, 255, 255); font-family: tahoma,new york,times,serif; font-size: 10pt;div id=yiv159912332yui_3_2_0_14_131367940402095brblockquote id=yiv159912332yui_3_2_0_14_131367940402054 style=border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;div id=yiv159912332yui_3_2_0_14_131367940402094 class=yiv159912332yui_3_2_0_14_131367940402057 style=font-family: tahoma,new york,times,serif; font-size: 10pt;div id=yiv159912332yui_3_2_0_14_131367940402093 class=yiv159912332yui_3_2_0_14_131367940402059 style=font-family: times new roman,new york,times,serif; font-size: 12pt;There are two kinds of configuration files supported in Packaging, and you can say it maybe a transition consideration fromnbsp; distutils/setuptools to Packaging, but if you look into the documents of Packaging(you can generate it from the /Doc directory), you will get to know that Packaging has a more further and important consideration - setup.cfg and setup.py place different roles in a project, setup.py offers developers to set while setup.cfg offers users to edit in a cheap and easy way... Certainly you can set anyone of these two files to reach the same goal.brspan/span/div/div/blockquoteI think I understand that much. The point of setup.cfg is to do away with the completely ad-hoc nature of code that developers can put into setup.py, which prevents playing nicely with distro package managers. I'm fairly sure I've seen Tarek say that for developers, no more setup.py - in fact, I've just found where he said it:/divdiv id=yiv159912332yui_3_2_0_14_131367940402095br/divdiv id=yiv159912332yui_3_2_0_14_131367940402095http://tarekziade.wordpress.com/2011/05/22/packaging-has-landed-in-the-stdlib//divdiv id=yiv159912332yui_3_2_0_14_131367940402095br/divdiv id=yiv159912332yui_3_2_0_14_131367940402095and alsobr/divdiv id=yiv159912332yui_3_2_0_14_131367940402095br/divdiv id=yiv159912332yui_3_2_0_14_131367940402095http://pycon.tv/#/video/57 (at around 6:55 into the video, and at 8:30 - there is no more setup.py - meaning in the new way of doing things)br/divdiv id=yiv159912332yui_3_2_0_14_131367940402095br/divdiv id=yiv159912332yui_3_2_0_14_131367940402095So the role of setup.py is historical, and the way developers customise installations is through using hooks. These work well enough, and I am currently using them in the nemo project which is a companion to the pythonv branch - see http://www.red-dove.com/screencasts/pythonv/pythonv.html/divdiv id=yiv159912332yui_3_2_0_14_131367940402095br/divdiv id=yiv159912332yui_3_2_0_14_131367940402095brdiv id=yiv159912332yui_3_2_0_14_131367940402094 class=yiv159912332yui_3_2_0_14_131367940402057 style=font-family: tahoma,new york,times,serif; font-size: 10pt;div id=yiv159912332yui_3_2_0_14_131367940402093 class=yiv159912332yui_3_2_0_14_131367940402059 style=font-family: times new roman,new york,times,serif; font-size: 12pt;br/div/div/div/div/div/div/body/html___ Python-bugs-list mailing list Unsubscribe:
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Barry A. Warsaw ba...@python.org added the comment: On Aug 18, 2011, at 01:15 PM, Charles-François Natali wrote: Charles-François Natali neolo...@free.fr added the comment: My question too! I would say that stable releases should probably not get this change, but should force sys.platform to linux2 on 3.x kernels. The point is precisely that we don't change anything: applications checking against sys.platform are already broken, there's no reason to comfort them into using this defective check. The applications that encountered the problem (chromium, matplotlib and probably others) already performed the change to sys.platform.startswith(), so it's really the only way to go. I still think that sys.platform for the stable releases should never report 'linux3'. Updating the various conditionals *probably* has low risk of regression, but I think you have to check that very carefully. BTW, does anybody think sys.platform should use a more dynamic approach for calculating its value? Well, maybe not necessary if Python 3.3 will just say 'linux'. There's already platform.system() for that. TOOWTDI -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12775] immense performance problems related to the garbage collector
Daniel Svensson dsvens...@gmail.com added the comment: Working on getting a reasonable large file to test with on my laptop where I have 2.6, 2.7, 3.2. The Python version where the problem became apparent was 2.5.2 as the software is deployed on Debian Lenny. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
STINNER Victor victor.stin...@haypocalc.com added the comment: I still think that sys.platform for the stable releases should never report 'linux3' I don't understand why do you want to have a special case for Linux. sys.platform is already different for each major version of: * FreeBSD * OpenBSD * NetBSD * unixware * openunix * sco_sv * sunos * hp-ux (Ok, some of them are dead and you cannot expect new major versions :-)) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Barry A. Warsaw ba...@python.org added the comment: On Aug 18, 2011, at 03:45 PM, STINNER Victor wrote: I don't understand why do you want to have a special case for Linux. sys.platform is already different for each major version of: We already have special cases for cygwin, darwin, and irix (okay, the latter is dead too :). I'm just suggesting one more special case for linux* (see configure.in and search for MACHDEP) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ 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
higery shoulderhig...@gmail.com added the comment: IOW, in my opinion, support for setuptools develop command is not needed in packaging core Then do you also mean support that for setuptools install is also not necessary 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. 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. It also the same to 'develop'. BTW, I think it's ok if setuptools is already installed when a user try to run 'python setup.py develop', if not, python will report error. In addition, Packaging use a different way to issue commands - cd to the source directory, and use 'pysetup run develop' to do the job. Old setup.py will be supported only by issuing commands under the source directory containing the setup.py, and if setuptools exists, Packaging will dispatch the job to it. -- ___ 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
[issue12650] Subprocess leaks fd upon kill()
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 7d358379c5fb by Charles-François Natali in branch '2.7': Issue #12650: only run the tests on Unix. http://hg.python.org/cpython/rev/7d358379c5fb -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12650 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] packaging: generate scripts from callable (dotted paths)
Vinay Sajip vinay_sa...@yahoo.co.uk added the comment: NO. I removed the 'copy_scripts' function, so I did not use your developed functionality. After this change, Packaging module now just builds new-style scripts and old-style scripts will be built by distutils/setuptools. To support the old-style scripts generated by d*/s* in p*, we can use the resource system. Not just as is, I believe. When scripts are installed (as opposed to other resources), it's not enough to copy them across to the configured destination: you also need to change their shebang lines to point to the appropriate Python executable. This is particularly important in virtualenvs where there could be any number of Python executables (of different versions) represented. But how will we know which .py files mentioned in resources are data, and which are actually scripts? To me, it actually makes more sense to keep those scripts in the [scripts] section, and have some way of recognising which scripts need to be copied/amended and which ones need to be generated from callables. -- Added file: http://bugs.python.org/file22934/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12394 ___htmlbodydiv style=color:#000; background-color:#fff; font-family:tahoma, new york, times, serif;font-size:10ptdiv id=yiv1385342022div style=color: rgb(0, 0, 0); background-color: rgb(255, 255, 255); font-family: tahoma,new york,times,serif; font-size: 10pt;div id=yiv1385342022yui_3_2_0_14_131368247675778brblockquote id=yiv1385342022yui_3_2_0_14_131368247675754 style=border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;div id=yiv1385342022yui_3_2_0_14_131368247675785 class=yiv1385342022yui_3_2_0_14_131368247675757 style=font-family: tahoma,new york,times,serif; font-size: 10pt;div id=yiv1385342022yui_3_2_0_14_131368247675784 class=yiv1385342022yui_3_2_0_14_131368247675759 style=font-family: times new roman,new york,times,serif; font-size: 12pt;font id=yiv1385342022yui_3_2_0_14_131368247675783 face=Arial size=2hr size=1b id=yiv1385342022yui_3_2_0_14_131368247675782span id=yiv1385342022yui_3_2_0_14_131368247675781 style=font-weight: bold;/span/b/fontNO. I removed the 'copy_scripts' function, so I did not use your developed functionality. After this change, Packaging module now just builds new-style scripts and old-style scripts will be built by distutils/setuptools. To support the old-style scripts generated by d*/s* in p*, we can use the resource system.brspan/span/div/div/blockquoteNot just as is, I believe. When scripts are installed (as opposed to other resources), it's not enough to copy them across to the configured destination: you also need to change their shebang lines to point to the appropriate Python executable. This is particularly important in virtualenvs where there could be any number of Python executables (of different versions) represented. But how will we know which .py files mentioned in resources are data, and which are actually scripts?brbrTo me, it actually makes more sense to keep those scripts in the [scripts] section, and have some way of recognising which scripts need to be copied/amended and which ones need to be generated from callables.brbr/div/div/div/div/body/html___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
STINNER Victor victor.stin...@haypocalc.com added the comment: I'm just suggesting one more special case for linux* You suggest to have a special case in Python 2.7 and 3.2, but not in Python 3.3 (3.1, 2.6, etc.)? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12776] argparse: type conversion function should be called only once
Changes by Ned Deily n...@acm.org: -- nosy: +bethard ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12776 ___ ___ 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 ale...@notmyidea.org 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 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
[issue12760] Add create mode to open()
David Townshend aquavita...@gmail.com added the comment: I hope this patch suits you better :-) I've updated the documentation typo (thanks for pointing that out). I've also changed 'c' to 'x', since I think that if there is a convention we should stick to it. I don't think that it matters if the glibc docs say 'exclusive', as long it its clear in the python docs what it does, which I think it is. Having said that, I don't really have a strong opinion either way, so I'll happily change it back to 'c' if its preferred. -- Added file: http://bugs.python.org/file22935/open_create_x-2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12760 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Barry A. Warsaw ba...@python.org added the comment: On Aug 18, 2011, at 03:58 PM, STINNER Victor wrote: STINNER Victor victor.stin...@haypocalc.com added the comment: I'm just suggesting one more special case for linux* You suggest to have a special case in Python 2.7 and 3.2, but not in Python 3.3 (3.1, 2.6, etc.)? Correct. We can't touch Python 3.1, 2.6, or earlier because those are all in security-only mode, and unless a specific security related issue is identified, the change should not be made there. That's just life (a recent similar example is support for multiarch in newer Debian and Ubuntu releases - we just don't support that in security-only Pythons). We can and should change Python 3.2 and 2.7 to only report 'linux2' for backward compatibility. For Python 3.3, we should do the right thing, which IMO is to set sys.platform to 'linux' without the version number. In parallel we can change the stdlib tests to use .startswith() and encourage third party developers to use .startswith() also. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Antoine Pitrou pit...@free.fr added the comment: Correct. We can't touch Python 3.1, 2.6, or earlier because those are all in security-only mode, and unless a specific security related issue is identified, the change should not be made there. That's just life (a recent similar example is support for multiarch in newer Debian and Ubuntu releases - we just don't support that in security-only Pythons). We can and should change Python 3.2 and 2.7 to only report 'linux2' for backward compatibility. It means someone upgrading from 2.6 to 2.7 will see sys.platform change from linux3 to linux2. That breaks compatibility. For Python 3.3, we should do the right thing, which IMO is to set sys.platform to 'linux' without the version number. In parallel we can change the stdlib tests to use .startswith() and encourage third party developers to use .startswith() also. The latter is already done in the documentation. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
STINNER Victor victor.stin...@haypocalc.com added the comment: For Python 3.3, (...) In parallel we can change the stdlib tests to use .startswith() done, see my changeset 50f1922bc1d5 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12775] immense performance problems related to the garbage collector
Daniel Svensson dsvens...@gmail.com added the comment: using: (except in python2.5 case where simplejson is used, which ought to be the same thing right?) import time, gc, json, sys def read_json_blob(): t0 = time.time() fd = open(datatest1.json) data = fd.read() fd.close() t1 = time.time() parsed = json.loads(data) t2 = time.time() print(read file in %.2fs, parsed json in %.2fs, total of %.2fs % (t1-t0, t2-t1, t2-t0)) if len(sys.argv) 1 and sys.argv[1] == nogc: gc.disable() read_json_blob() print(gc.collect()) daniel@neutronstar:~$ sudo bash -c echo 3 /proc/sys/vm/drop_caches; python3.2 gc.py nogc read file in 1.34s, parsed json in 2.74s, total of 4.07s 0 daniel@neutronstar:~$ sudo bash -c echo 3 /proc/sys/vm/drop_caches; python3.2 gc.py read file in 1.33s, parsed json in 2.71s, total of 4.05s 0 daniel@neutronstar:~$ sudo bash -c echo 3 /proc/sys/vm/drop_caches; python2.6 gc.py read file in 0.89s, parsed json in 56.03s, total of 56.92s 0 daniel@neutronstar:~$ sudo bash -c echo 3 /proc/sys/vm/drop_caches; python2.6 gc.py nogc read file in 0.89s, parsed json in 56.38s, total of 57.27s 0 daniel@neutronstar:~$ sudo bash -c echo 3 /proc/sys/vm/drop_caches; python2.7 gc.py read file in 0.89s, parsed json in 3.87s, total of 4.75s 0 daniel@neutronstar:~$ sudo bash -c echo 3 /proc/sys/vm/drop_caches; python2.7 gc.py nogc read file in 0.89s, parsed json in 3.91s, total of 4.80s 0 daniel@aether:~$ sudo bash -c echo 3 /proc/sys/vm/drop_caches; python2.5 gc.py read file in 0.11s, parsed json in 53.00s, total of 53.11s 0 daniel@aether:~$ sudo bash -c echo 3 /proc/sys/vm/drop_caches; python2.5 gc.py nogc read file in 0.14s, parsed json in 53.13s, total of 53.28s 0 Everything is equally slow.. no weird things there, except that Python 3.2 seems to take more time to load the file. Nice performance improvement of the json module in 3.2 compared to older Python versions. Next up. Trying with cjson which decodes via a binary module: import time, gc, cjson, sys def read_json_blob(): t0 = time.time() fd = open(datatest1.json) data = fd.read() fd.close() t1 = time.time() parsed = cjson.decode(data) t2 = time.time() print(read file in %.2fs, parsed json in %.2fs, total of %.2fs % (t1-t0, t2-t1, t2-t0)) if len(sys.argv) 1 and sys.argv[1] == nogc: gc.disable() read_json_blob() print(gc.collect()) daniel@neutronstar:~$ sudo bash -c echo 3 /proc/sys/vm/drop_caches; python2.6 gc.py read file in 0.89s, parsed json in 2.58s, total of 3.46s 0 daniel@neutronstar:~$ sudo bash -c echo 3 /proc/sys/vm/drop_caches; python2.6 gc.py nogc read file in 0.89s, parsed json in 1.44s, total of 2.33s 0 daniel@neutronstar:~$ sudo bash -c echo 3 /proc/sys/vm/drop_caches; python2.7 gc.py nogc read file in 0.89s, parsed json in 1.53s, total of 2.42s 0 daniel@neutronstar:~$ sudo bash -c echo 3 /proc/sys/vm/drop_caches; python2.7 gc.py read file in 0.89s, parsed json in 1.54s, total of 2.43s 0 daniel@neutronstar:~$ sudo bash -c echo 3 /proc/sys/vm/drop_caches; python2.6 gc.py nogc read file in 0.89s, parsed json in 1.44s, total of 2.33s 0 daniel@neutronstar:~$ sudo bash -c echo 3 /proc/sys/vm/drop_caches; python2.6 gc.py read file in 0.89s, parsed json in 2.58s, total of 3.47s 0 daniel@neutronstar:~$ sudo bash -c echo 3 /proc/sys/vm/drop_caches; python2.6 gc.py read file in 0.89s, parsed json in 2.58s, total of 3.47s 0 daniel@neutronstar:~$ sudo bash -c echo 3 /proc/sys/vm/drop_caches; python2.6 gc.py nogc read file in 0.89s, parsed json in 1.43s, total of 2.32s 0 daniel@aether:~$ sudo bash -c echo 3 /proc/sys/vm/drop_caches; python2.5 gc.py read file in 0.14s, parsed json in 1.58s, total of 1.73s 0 daniel@aether:~$ sudo bash -c echo 3 /proc/sys/vm/drop_caches; python2.5 gc.py nogc read file in 0.16s, parsed json in 1.07s, total of 1.23s 0 daniel@aether:~$ sudo bash -c echo 3 /proc/sys/vm/drop_caches; python2.5 gc.py read file in 0.14s, parsed json in 1.58s, total of 1.72s 0 daniel@aether:~$ sudo bash -c echo 3 /proc/sys/vm/drop_caches; python2.5 gc.py nogc read file in 0.14s, parsed json in 1.06s, total of 1.20s The file is actually a bit too small for good measurement when using cjson, but interesting point here is obviously the huge difference between GC and no GC in Python 2.5, and quite a bit win in 2.6 too, which becomes a lot more apparent with larger files. Another interesting thing is that Python 2.6 is consistently faster than 2.7 when the GC is disabled in 2.6, compared to both enabled and disabled in 2.7. The cjson isn't compatible with Python 3.2 so I cannot verify how things work there. So overall it looks like it's less of a problem in newer versions of Python. We are phasing out the software that is deployed on Debian Lenny so it's a problem that will go away. I don't think I have any objections with closing this ticket again.
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
STINNER Victor victor.stin...@haypocalc.com added the comment: If we change Python 2.7.3 and 3.2.2 to force sys.platform to linux2 (instead of linux3) and use linux in Python 3.3, we will have 3 differents values of sys.platform if Python is built on Linux 3: - linux3 on Python = 2.7.2 or Python = 3.2.1 - linux2 on 2.7.3 = Python or 3.2.2 = Python 3.3 - linux on Python = 3.3 I don't see how it will help backward or forward compatibility... It's exactly as the current state (sys.platform == 'linux3' on all Python versions): applications have to use sys.platform.startswith() to work correctly on any Linux version. Well, except maybe if you plan to write applications working only on Python = 2.7.3? ... this version is not released yet. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Changes by Charles-François Natali neolo...@free.fr: -- nosy: -neologix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9200] Make str methods work with non-BMP chars on narrow builds
STINNER Victor victor.stin...@haypocalc.com added the comment: I don't think that macros specific to unicodeobject.c should get the _PY_UNICODE_ prefix. _Py_ prefix is reserved to exported symbols, but symbols reserved for the Python interprefer itself. For _Py_UNICODE_NEXT, you can call it NEXT_CHARACTER(). _Py_UNICODE_ISHIGHSURROGATE,_Py_UNICODE_ISLOWSURROGATE and _Py_UNICODE_JOIN_SURROGATES are only used once, I would prefer to see them inlined in _Py_UNICODE_NEXT. The first cast to Py_UCS4 in _Py_UNICODE_JOIN_SURROGATES is useless. It looks like the macro can be simplified to something like: #define _Py_UNICODE_NEXT(ptr, end) \ (_Py_UNICODE_ISHIGHSURROGATE(*(ptr)) (ptr) (end)) _Py_UNICODE_ISLOWSURROGATE((ptr)[1] ? \ ((ptr) += 2,_Py_UNICODE_JOIN_SURROGATES((ptr)[-2], (ptr)[-1])) : \ (Py_UCS4)*(ptr)++) (you don't need two a?b:c) I would prefer to see _Py_UNICODE_NEXT as a function instead of a macro because it has border effect (ptr++ or ptr += 2). You cannot write Py_UNICODE_ISALNUM(_Py_UNICODE_NEXT(p, e)) for example, because Py_UNICODE_ISALNUM is defined as: #define Py_UNICODE_ISALNUM(ch) (Py_UNICODE_ISALPHA(ch) || Py_UNICODE_ISDECIMAL(ch) || Py_UNICODE_ISDIGIT(ch) || Py_UNICODE_ISNUMERIC(ch)) And so _Py_UNICODE_NEXT is expanded 4 times. It is also horrible to debug a program having such long macro. If you really want to keep it as a macro, please add a least a big warning. It's also confusing to have two attachments with the same name :-/ -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9200 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12775] immense performance problems related to the garbage collector
Changes by Daniel Svensson dsvens...@gmail.com: -- versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12775] immense performance problems related to the garbage collector
Ezio Melotti ezio.melo...@gmail.com added the comment: IIRC the C acceleration for json were added in 2.7/3.2, and are used automatically when you import json. In the previous releases the json module was implemented in pure Python. That explains why it's much slower on Python 2.5/6. -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12775] immense performance problems related to the garbage collector
Daniel Svensson dsvens...@gmail.com added the comment: Yes, but this ticket was only opened due to time delta between no-gc and gc, not as much absolute time, but that's a nice improvement. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12778] JSON-serializing a large container takes too much memory
poq p...@gmx.com added the comment: I think this is because dumps() uses the C encoder. Making the C encoder incremental (i.e. iterator-based) like the Python encoder would solve this. I actually looked into doing this for issue #12134, but it didn't seem so simple; Since C has no yield, I think the iterator would need to maintain its own stack to keep track of where it is in the object tree it's encoding... If there is interest though, I may be able to write a patch when I have some time off again... -- nosy: +poq ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12778 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12775] immense performance problems related to the garbage collector
Antoine Pitrou pit...@free.fr added the comment: So overall it looks like it's less of a problem in newer versions of Python. We are phasing out the software that is deployed on Debian Lenny so it's a problem that will go away. I don't think I have any objections with closing this ticket again. Thanks for the comprehensive measurements. Indeed I think it doesn't seem it is a problem in 2.7/3.2. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12775 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9200] Make str methods work with non-BMP chars on narrow builds
Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: STINNER Victor victor.stin...@haypocalc.com added the comment: I don't think that macros specific to unicodeobject.c should get the _PY_UNICODE_ prefix. _Py_ prefix is reserved to exported symbols, but symbols reserved for the Python interprefer itself. For _Py_UNICODE_NEXT, you can call it NEXT_CHARACTER(). Can we please stick to the things we discussed on issue10542. The macros are intended to be public starting with 3.3, not private and they are meant to be used outside the interpreter as well. They will only be private for patch level release patches. For those you don't need the Py-prefix, but it also doesn't hurt having it there. _Py_UNICODE_ISHIGHSURROGATE,_Py_UNICODE_ISLOWSURROGATE and _Py_UNICODE_JOIN_SURROGATES are only used once, I would prefer to see them inlined in _Py_UNICODE_NEXT. The first cast to Py_UCS4 in _Py_UNICODE_JOIN_SURROGATES is useless. It looks like the macro can be simplified to something like: #define _Py_UNICODE_NEXT(ptr, end) \ (_Py_UNICODE_ISHIGHSURROGATE(*(ptr)) (ptr) (end)) _Py_UNICODE_ISLOWSURROGATE((ptr)[1] ? \ ((ptr) += 2,_Py_UNICODE_JOIN_SURROGATES((ptr)[-2], (ptr)[-1])) : \ (Py_UCS4)*(ptr)++) (you don't need two a?b:c) I would prefer to see _Py_UNICODE_NEXT as a function instead of a macro because it has border effect (ptr++ or ptr += 2). You cannot write Py_UNICODE_ISALNUM(_Py_UNICODE_NEXT(p, e)) for example, because Py_UNICODE_ISALNUM is defined as: #define Py_UNICODE_ISALNUM(ch) (Py_UNICODE_ISALPHA(ch) || Py_UNICODE_ISDECIMAL(ch) || Py_UNICODE_ISDIGIT(ch) || Py_UNICODE_ISNUMERIC(ch)) And so _Py_UNICODE_NEXT is expanded 4 times. It is also horrible to debug a program having such long macro. If you really want to keep it as a macro, please add a least a big warning. Having it as function would kill the performance advantage, so that's not really an option. The use case you mention is also not really realistic. Adding an extra warning to the macro version is still a good idea, though. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9200 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12765] test_packaging failure under Snow Leopard
Éric Araujo mer...@netwok.org added the comment: Is it possible to run the test suite with -vv on the buildbot to see the changes made to os.environ? On a related note, is it possible to get SSH access to a similar machine? If not, I will add debugging info in a commit and watch the buildbot; it will be more tedious and also make noise for python-checkins, but well. -- components: +Distutils2, Macintosh -Library (Lib), Tests nosy: +alexis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12765 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9850] obsolete macpath module dangerously broken and should be removed
Éric Araujo mer...@netwok.org added the comment: Thanks for the patch. Is the function already tested or does someone need to add a test? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9850 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12779] Update packaging documentation
Éric Araujo mer...@netwok.org added the comment: (Replying to myself so that this report doesn’t show up in the “Issues without reply” section of the weekly email) -- nosy: +docs@python ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12650] Subprocess leaks fd upon kill()
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 8ca7f109ce79 by Charles-François Natali in branch '3.2': Issue #12650: Fix a race condition where a subprocess.Popen could leak http://hg.python.org/cpython/rev/8ca7f109ce79 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12650 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12779] Update packaging documentation
New submission from Éric Araujo mer...@netwok.org: The documentation for packaging is outdated: it refers to setup.py instead of setup.cfg or pysetup, it talks about removed parts like compress (.Z) archives or bdist_rpm, and needs a good read-through. I have started to work on this, so I’m opening this report to prevent someone else from duplicating efforts. -- assignee: eric.araujo components: Distutils2, Documentation messages: 142367 nosy: alexis, eric.araujo priority: normal severity: normal status: open title: Update packaging documentation versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12779 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11553] Docs for: import, packages, site.py, .pth files
Éric Araujo mer...@netwok.org added the comment: FYI, I have updated the site module and distutils/packaging docs to document the PEP 370 features. There has been no feedback, so I will backport to 2.7 and close the reports. See linked bugs to read the changesets. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11553 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12761] Typo in Doc/license.rst
Sandro Tosi sandro.t...@gmail.com added the comment: After a closer look (thanks Ezio), the proper patch should be something like: diff --git a/Doc/license.rst b/Doc/license.rst --- a/Doc/license.rst +++ b/Doc/license.rst @@ -874,9 +874,8 @@ zlib -The :mod:`zlib` extension is built using an included copy of the zlib -sources if the zlib version found on the system is too old to be -used for the build:: +The :mod:`zlib` extension is built using the zlib version found on the system, +but an included copy of the zlib sources is shipped for the Windows build:: Copyright (C) 1995-2011 Jean-loup Gailly and Mark Adler because the embedded zlib is not used in the linux build (but always the system one, and if absent, no zlib module is built) while we have several references of Modules/zlib/ files in PC/VC* and PCbuild/*.vcproj (that I can't read); adding to nosy the windows expert to have their opinion. -- nosy: +brian.curtin, tim.golden resolution: fixed - stage: committed/rejected - patch review status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12761 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5845] rlcompleter should be enabled automatically
Changes by Éric Araujo mer...@netwok.org: Removed file: http://bugs.python.org/file21399/fix-5845.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5845 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5845] rlcompleter should be enabled automatically
Éric Araujo mer...@netwok.org added the comment: Updated patch (not using Mercurial, looks like I haven’t enough bandwidth to push all those changesets). -- Added file: http://bugs.python.org/file22936/fix-5845.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5845 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12720] Expose linux extended filesystem attributes
Benjamin Peterson benja...@python.org added the comment: Here is a new patch, implementing Antoine's suggestions. -- Added file: http://bugs.python.org/file22937/xattrs.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12720 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11599] Useless error message when distutils fails compiling
Changes by Éric Araujo mer...@netwok.org: Removed file: http://bugs.python.org/file21316/fix-compile-error-messages.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11599 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11599] Useless error message when distutils fails compiling
Changes by Éric Araujo mer...@netwok.org: Added file: http://bugs.python.org/file22938/fix-11599.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11599 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12650] Subprocess leaks fd upon kill()
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 148d75d106f1 by Charles-François Natali in branch 'default': Issue #12650: Fix a race condition where a subprocess.Popen could leak http://hg.python.org/cpython/rev/148d75d106f1 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12650 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8286] distutils: path '[...]' cannot end with '/' -- need better error message
Éric Araujo mer...@netwok.org added the comment: Can you test with this patch? -- keywords: +patch versions: -Python 3.1 Added file: http://bugs.python.org/file22939/sdist-no-traceback-3.2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8286 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12780] Clean up tests for pyc/pyo in __file__
New submission from Éric Araujo mer...@netwok.org: After PEP 3147, __file__ always points to the py file, not pyc/pyo. I found two instances of obsolete code. -- files: fix-11599.diff keywords: patch messages: 142375 nosy: benjamin.peterson, eric.araujo, vinay.sajip priority: normal severity: normal stage: commit review status: open title: Clean up tests for pyc/pyo in __file__ versions: Python 3.3 Added file: http://bugs.python.org/file22940/fix-11599.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12780 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] packaging: generate scripts from callable (dotted paths)
Changes by Éric Araujo mer...@netwok.org: Removed file: http://bugs.python.org/file22933/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12394 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] packaging: generate scripts from callable (dotted paths)
Changes by Éric Araujo mer...@netwok.org: Removed file: http://bugs.python.org/file22934/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12394 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12765] test_packaging failure under Snow Leopard
Antoine Pitrou pit...@free.fr added the comment: Bill is the owner of that buildbot. -- nosy: +janssen ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12765 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] packaging: generate scripts from callable (dotted paths)
Éric Araujo mer...@netwok.org added the comment: scripts = foo = a.b.c.main foowin = a.b.c.winmain -window This is great. About -window: I don’t think using a fake option style (leading -) is useful, and I’d reuse the setuptools name, “gui”. I also think this good idea of yours can solve our other feature requests: unit2 = unittest2.main.main unit2-tk = unittest2.gui.main window spamd = spamlib.daemon.main sbin The first example is a regular script; the second one will use pythonw on Windows and Mac OS X; the third one would install to /usr/sbin instead of /usr/bin on POSIX. What do you think? 'scripts' belongs to the 'files' section in setup.cfg, it's still ok now to place it in 'files'? As I said in private email, I don’t think it’s a concern at all, but maybe other people disagree. An alternate idea: using a new section: [scripts] sphinx-build = sphinx.build.main You should ask on the fellowship ML. About setup.cfg and setup.py. In general, packaging totally ignores setup.py. However, one goal is to support generated setup.py that take all the info from the setup.cfg file, thanks to pysetup generate-setup. In that case, there’s a compatibility question, as you said: what do we do with scripts as dotted paths? It would be too much pain to use inspect.getsource to copy our functions that generate scripts into the setup.py file. I think our documentation should just advise people to create an old-style script file and manually add it in their setup.py. To support the old-style scripts generated by d*/s* in p*, we can use the resource system. Not just as is, I believe. When scripts are installed (as opposed to other resources), it's not enough to copy them across to the configured destination: you also need to change their shebang lines to point to the appropriate Python executable. That is true. I see too possible solutions: tell people to use a hook, or have special handling for resources registered in the scripts category (IOW a built-in hook). I prefer the second option. But how will we know which .py files mentioned in resources are data, and which are actually scripts? Distutils scripts are not actually restricted to Python scripts. The shebang updating only happens if a regex matches. To answer your question: the resources system uses categories, one of which is “scripts”. I’m -1 on using heuristics to handle both distutils-style files and packaging-style dotted paths (Vinay’s latest message). It’s much cleaner to have separate fields or sections. (BTW Vinay, remember that Roundup creates attachments when someone sends HTML email) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12394 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12780] Clean up tests for pyc/pyo in __file__
Changes by Éric Araujo mer...@netwok.org: Removed file: http://bugs.python.org/file22940/fix-11599.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12780 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12780] Clean up tests for pyc/pyo in __file__
Changes by Éric Araujo mer...@netwok.org: Added file: http://bugs.python.org/file22941/__file__-cant-contain-pyc-in-3.2.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12780 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12394] packaging: generate scripts from callable (dotted paths)
Éric Araujo mer...@netwok.org added the comment: Heh, I messed up my example: unit2-tk = unittest2.gui.main gui -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12394 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Martin v. Löwis mar...@v.loewis.de added the comment: The point is precisely that we don't change anything: applications checking against sys.platform are already broken, there's no reason to comfort them into using this defective check. You grossly misunderstand the concept of backwards compatibility. At times, features get added to allow even buggy (or perceived-buggy) applications to continue to work under a change. The applications that encountered the problem (chromium, matplotlib and probably others) already performed the change to sys.platform.startswith(), so it's really the only way to go. I'm very certain that not all applications have been changed yet. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Martin v. Löwis mar...@v.loewis.de added the comment: I don't understand why do you want to have a special case for Linux. sys.platform is already different for each major version of: That's because Linux uses major version numbers in an entirely different way than these systems. There is a traditional usage of major versions (to indicate significant changes), and the systems you list follow this practice. And then there are systems that break with that tradition, and use the major version for marketing and other purposes, and Linux is one of them. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Martin v. Löwis mar...@v.loewis.de added the comment: It means someone upgrading from 2.6 to 2.7 will see sys.platform change from linux3 to linux2. That breaks compatibility. No, it doesn't. Code that works on 2.6 and Linux 3 will likely support both linux2 and linux3, so it will continue just fine on 2.7. I'd rather phrase this differently: Python 2.6 does not support Linux 3. Tough luck, since Linux 3 was released long after Python 2.6. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
James Y Knight f...@users.sourceforge.net added the comment: Well, except maybe if you plan to write applications working only on Python = 2.7.3? ... this version is not released yet. No, of course I don't plan on writing new code that checks sys.platform == 'linux2'. That's ridiculous. I plan to use *already written* applications on Python2.7.3 binaries that have already been built (and thus were built on a 2.x kernel and report linux2), on Python=2.7.3 which will be fixed to continue reporting linux2, and on Python2.7.3 which have had the same fix backported to them by distros, since Python upstream won't do it for earlier branches. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12326 ___ ___ 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: [...] so I keep this command name as 'develop' and the simple usage of this command is : pysetup run develop So far, so good. BTW, most developers in this list have agreed that 'develop' is a kind of install command, so I also add an entry funtion 'install_editable' for it, That can be useful. On the other hand, pip uses subprocesses instead of calling Python functions, to make sure an error in the called code does not stop pip. I still think it’s a nice function to have. The name should be changed: “editable” is not used in our current terminology, so install_develop would be IMO better. I also think that “pysetup install --develop path/to/project” would be a nice high-level way to use develop, in the future. About supporting setup.py develop: I think too that it is not needed. Supporting setup.py install is a needed feature for *users*, as Alexis said; conversely, having a packaging-only develop feature can help seduce *developers* to use the new standards and tools. My vote is for removing setup.py develop support. -- ___ 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
