[issue12780] Clean up tests for pyc/pyo in __file__
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 98d13885a574 by Vinay Sajip in branch '3.2': Issue #12780: Removed checks in logging for .pyc/.pyo in __file__. http://hg.python.org/cpython/rev/98d13885a574 New changeset ac0c04d8eafb by Vinay Sajip in branch 'default': Issue #12780: Merged fix from 3.2. http://hg.python.org/cpython/rev/ac0c04d8eafb -- nosy: +python-dev ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Marc-Andre Lemburg m...@egenix.com added the comment: James Y Knight wrote: James Y Knight f...@users.sourceforge.net added the comment: Sure, you can compile and run Python on both versions of Linux, but what if your application uses features that are only present in Linux 3.0 and later ? This comment is making me think you've missed just how irrelevant kernel version 3.0 really is. To a first approximation, it *has no new features*. Now, to be sure, there are a couple of things, sure. Just like there were a couple new features in 2.6.39 two months earlier, 2.6.38 two months before that, 2.6.37 two months before that, and so on, every 2-3 months, back to the release of 2.6.7 or so in 2004. I am aware of the history behind that version number change. The difference between Linux 2.x and 3.x may be small nowadays, but another 20 kernel releases down the road, the difference will show. BTW: The new attribute should contain the complete version number, not just the major version. `uname -r` would provide a good start. To be useful, that would have to be a runtime-computed thing, not the build-time value that sys.platform's trailing number is. But we already have that: os.uname(). It certainly doesn't need a second name. There are two aspects to consider: 1. The platform Python (and presumably the application) was compiled on. 2. The platform Python and the application are currently running on. Both Python and the application will make certain assumptions about the platform depending on the compile time environment. If the deployment platform is too different from that environment, it won't run or not as expected. So you need both the compile and the runtime version information. The suggested change removes the compile time information from the platform string, so that information needs to be preserved in a new attribute. -- ___ 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 von Gagern martin.vgag...@gmx.net added the comment:
As people keep stating how easy the change from sys.platform == 'linux2' to
sys.platform.startswith('linux') is, e.g. msg142385, please also keep in mind
cases like someDict.get(sys.platform) where the comparison is implicit and
therefore a simple change to startswith won't do the trick. Seen that in the
wild.
Besides that, I can only wholeheartedly agree to the points so eloquently
described by Martin v. Löwis and James Y Knight. Thanks!
Let's please force it to 'linux2' for the next 2.7 and 3.2 releases, so people
can use recent kernels without breaking (or having to rewrite) third-party
apps. Let's also encourage distros to do the same for older releases, perhaps
even suggesting patches.
--
___
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 von Gagern martin.vgag...@gmx.net added the comment: Marc-Andre Lemburg wrote: Both Python and the application will make certain assumptions about the platform depending on the compile time environment. Can you give examples for this? So you need both the compile and the runtime version information. I very much doubt that any feature in Python is actually enabled if compiled under Linux 3. If so that's probably a bug in Python, due to the small number of features added from 2.6.39 to 3.0. Either the feature was introduced into Linux before 3.0, in which case Python should use it as early as possible, or the feature was introduced in some 3.x release, in which case not all Linux 3 builds will have it. So the single digit major number will not be enough for this kind of checks, and the safest way is to check for the feature itself, e.g. by simply using it and handling NotImplementedException appropriately. That approach is more portable for new platforms as well. -- ___ 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'
Marc-Andre Lemburg m...@egenix.com added the comment: Martin von Gagern wrote: Martin von Gagern martin.vgag...@gmx.net added the comment: Marc-Andre Lemburg wrote: Both Python and the application will make certain assumptions about the platform depending on the compile time environment. Can you give examples for this? Sure, just have a look at how different the various minor release Mac OS X versions are. They even changed the default architecture without bumping the major version of the OS. A configure run on one OS version will pick up different environment settings than on a later one. As a result Python and application extensions use different libs/packages/tools or even create completely different runtimes (e.g. one for PPC, the other for i386). So you need both the compile and the runtime version information. I very much doubt that any feature in Python is actually enabled if compiled under Linux 3. If so that's probably a bug in Python, due to the small number of features added from 2.6.39 to 3.0. Either the feature was introduced into Linux before 3.0, in which case Python should use it as early as possible, or the feature was introduced in some 3.x release, in which case not all Linux 3 builds will have it. So the single digit major number will not be enough for this kind of checks, and the safest way is to check for the feature itself, e.g. by simply using it and handling NotImplementedException appropriately. That approach is more portable for new platforms as well. That works fine for features that you can programmatically control. It doesn't work well for static data that you provide externally depending on the platform OS version. Take e.g. the plat-freebsdN directories with the OS dependent constants/functions as example. As already mentioned, the diff between Linux 2.x and 3.x will grow over time and while there may not be much to see now, things will change in the coming years. Just look at the differences between plat-linux1 and plat-linux2 (plat-linux1 was phased out in Python 2.4 so you have to go back to Python 2.3 or earlier). -- ___ 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
[issue10504] Trivial mingw compile fixes
Changes by Kalev Lember kalevlem...@gmail.com: -- nosy: +kalev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10504 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10293] PyMemoryView object has obsolete members
Stefan Krah stefan-use...@bytereef.org added the comment: I think PyBUF_SHADOW was the renamed version of PyBUF_UPDATEIFCOPY from the PEP. :) -- nosy: +skrah ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10293 ___ ___ 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()
Charles-François Natali neolo...@free.fr added the comment: The test now passes on the buildbots, closing. -- status: open - closed ___ 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
[issue12783] test_posix failure on FreeBSD 6.4: test_get_and_set_scheduler_and_param
New submission from Charles-François Natali neolo...@free.fr:
http://www.python.org/dev/buildbot/all/builders/x86%20FreeBSD%206.4%203.x/builds/1734/steps/test/logs/stdio
==
ERROR: test_get_and_set_scheduler_and_param (test.test_posix.PosixTester)
--
Traceback (most recent call last):
File
/usr/home/db3l/buildarea/3.x.bolen-freebsd/build/Lib/test/test_posix.py, line
878, in test_get_and_set_scheduler_and_param
posix.sched_setparam(0, param)
OSError: [Errno 22] Invalid argument
--
The reason is quite simple:
http://freebsd.active-venture.com/FreeBSD-srctree/newsrc/posix4/ksched.c.html
/*
* XXX About priorities
*
* POSIX 1003.1b requires that numerically higher priorities be of
* higher priority. It also permits sched_setparam to be
* implementation defined for SCHED_OTHER. I don't like
* the notion of inverted priorites for normal processes when
* you can use setpriority for that.
*
* I'm rejecting sched_setparam for SCHED_OTHER with EINVAL.
*/
[...]
int ksched_setparam(register_t *ret, struct ksched *ksched,
struct proc *p, const struct sched_param *param)
{
register_t policy;
int e;
e = getscheduler(policy, ksched, p);
if (e == 0)
{
if (policy == SCHED_OTHER)
e = EINVAL;
else
e = ksched_setscheduler(ret, ksched, p, policy, param);
}
return e;
}
And indeed, sched_setparam is implementation-defined if the process' scheduling
policy is SCHED_OTHER, see
http://pubs.opengroup.org/onlinepubs/007908799/xsh/sched_setparam.html
If the current scheduling policy for the process specified by pid is not
SCHED_FIFO or SCHED_RR, including SCHED_OTHER, the result is
implementation-dependent.
It seems that FreeBSD made the choice of returning EINVAL, but it changed in
recent versions (the test passes on FreeBSD 8).
I'm not sure about the best solution though:
1) don't perform this test if the scheduling policy is not SCHED_RR or
SCHED_FIFO
2) skip this test on FreeBSD versions that return EINVAL (maybe adding a new
requires_freebsd_version to test.support)
--
components: Tests
messages: 142423
nosy: benjamin.peterson, neologix
priority: normal
severity: normal
stage: needs patch
status: open
title: test_posix failure on FreeBSD 6.4: test_get_and_set_scheduler_and_param
type: behavior
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12783
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12707] Deprecate addinfourl getters
Éric Araujo mer...@netwok.org added the comment: For these two reasons I propose to: * document the 3 attributes as the suggested way to access this information; * deprecate the 3 getters; * avoid to document the now undocumented getcode(); +1 The addclosehook class could be provided via an alternative constructor I can’t say why, but I don’t like that. -- nosy: +eric.araujo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12707 ___ ___ 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: The suggested change removes the compile time information from the platform string, so that information needs to be preserved in a new attribute. -1 on any new platform identification attribute. We already have too many of them, and there's the platform module for precise identification. -- ___ 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
[issue11564] pickle not 64-bit ready
Antoine Pitrou pit...@free.fr added the comment: I have tried running the tests on a machine with 12GB of RAM, but when I do so, the new tests get skipped saying not enough memory, even when I specify -M 11G on the command-line. How much does it say is required? Did you remove the skips in BigmemPickleTests? The problem seems to be the change to the precisionbigmemtest decorator in test.support. I don't understand what the purpose of the dryrun flag is, but the modified condition for skipping doesn't look right to me. Well, perhaps I got the logic wrong. Debugging welcome :) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11564 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12256] Link isinstance/issubclass doc to abc module
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset eeb8a440bde0 by Éric Araujo in branch '3.2': Link isinstance/issubclass to the ABC glossary entry (#12256) http://hg.python.org/cpython/rev/eeb8a440bde0 New changeset e2e8c752c1b6 by Éric Araujo in branch '3.2': Mention virtual subclasses in the glossary entry for ABCs (#12256). http://hg.python.org/cpython/rev/e2e8c752c1b6 New changeset 5160d8eb3468 by Éric Araujo in branch 'default': Merge fixes for #12256 and typos from 3.2 http://hg.python.org/cpython/rev/5160d8eb3468 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1626300] 'Installing Python Modules' does not work for Windows
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 59f7bbe1236c by Éric Araujo in branch '3.2': Remove obsolete term + indicate how to find the program (#1626300). http://hg.python.org/cpython/rev/59f7bbe1236c New changeset adaec1a0dd47 by Éric Araujo in branch '3.2': Fix instance I missed in 59f7bbe1236c (#1626300) http://hg.python.org/cpython/rev/adaec1a0dd47 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1626300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10149] Data truncation in expat parser
Éric Araujo mer...@netwok.org added the comment: I was about to commit an edited version of your patch (attached) but then I thought we should check whether this isn’t really a bug. I just don’t see why expat would chunk without paying heed to the newlines if it is supposed to chunk at newlines. -- Added file: http://bugs.python.org/file22945/pyexpat.rst.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10149 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12256] Link isinstance/issubclass doc to abc module
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 96222062239f by Éric Araujo in branch '2.7': Link isinstance/issubclass to the ABC glossary entry (#12256) http://hg.python.org/cpython/rev/96222062239f -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10745] setup.py install --user option undocumented
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 25a48fe791e6 by Éric Araujo in branch '2.7': Add documentation for PEP 370 features in distutils (#10745). http://hg.python.org/cpython/rev/25a48fe791e6 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10745 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8617] Better document user site-packages in site module doc
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset b3f72b6450f1 by Éric Araujo in branch '2.7': Improve documentation for PEP 370 support in site module (#8617). http://hg.python.org/cpython/rev/b3f72b6450f1 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8617 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1626300] 'Installing Python Modules' does not work for Windows
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset e9022dc7a411 by Éric Araujo in branch '2.7': Remove obsolete term + indicate how to find the program (#1626300). http://hg.python.org/cpython/rev/e9022dc7a411 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1626300 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10745] setup.py install --user option undocumented
Changes by Éric Araujo mer...@netwok.org: -- components: +Distutils nosy: +alexis resolution: - fixed stage: - committed/rejected status: open - closed versions: +Python 2.7, Python 3.2, Python 3.3 -3rd party ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10745 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11564] pickle not 64-bit ready
Nadeem Vawda nadeem.va...@gmail.com added the comment: How much does it say is required? Did you remove the skips in BigmemPickleTests? Yes, I did remove the skips. It says 2GB for some, and 4GB for others. Well, perhaps I got the logic wrong. Debugging welcome :) I'd be glad to do so, but I'm not sure what the aim of the dryrun flag is. Do you want to make it the default that precisionbigmem tests are skipped, unless the decorator invocation explicitly specifies dryrun=False? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11564 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8617] Better document user site-packages in site module doc
Changes by Éric Araujo mer...@netwok.org: -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue8617 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12256] Link isinstance/issubclass doc to abc module
Éric Araujo mer...@netwok.org added the comment: I committed a modified version of the patch. -- resolution: - fixed stage: commit review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12256 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11564] pickle not 64-bit ready
Antoine Pitrou pit...@free.fr added the comment: I'd be glad to do so, but I'm not sure what the aim of the dryrun flag is. Do you want to make it the default that precisionbigmem tests are skipped, unless the decorator invocation explicitly specifies dryrun=False? No, the point is to avoid running these tests when -M is not specified. See what happens with other bigmem tests. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11564 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9173] logger statement not guarded in shutil._make_tarball
Éric Araujo mer...@netwok.org added the comment: I fixed this in 615a29295d5f but forgot to mention the bug number in the commit message. To reproduce the bug, I only had to backport two lines from 3.2, so I did not use your patch. Thanks to both of you nonetheless for the report and help! -- assignee: tarek - eric.araujo resolution: - fixed stage: patch review - committed/rejected status: open - closed versions: -Python 3.1, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9173 ___ ___ 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
Changes by Éric Araujo mer...@netwok.org: -- keywords: +easy ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12703 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12707] Deprecate addinfourl getters
Ezio Melotti ezio.melo...@gmail.com added the comment: I thought about having another class, but I couldn't come up with a decent name for it (ResponseWithCloseHook?). After all it's still a Response and unless you need a way to distinguish responses with and without close hooks, I think it might be better to have a single class for both. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12707 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10149] Data truncation in expat parser
Fred L. Drake, Jr. f...@fdrake.net added the comment: Chunking of the data is expected with Expat. There are no promises about *where* chunks are broken; the underlying behavior will break at line endings, but is not limited to that. Setting buffer_text informs the Python wrapper that it's allowed to combine the chunks reported by the Expat library; this was made optional since it could affect working applications (changing the default with the move to Python 3 may have been acceptable, though). -- nosy: +fdrake ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10149 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12782] Multiple context expressions do not support parentheses for continuation across lines
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +benjamin.peterson, ncoghlan type: behavior - feature request versions: -Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12782 ___ ___ 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'
Marc-Andre Lemburg m...@egenix.com added the comment: Antoine Pitrou wrote: Antoine Pitrou pit...@free.fr added the comment: The suggested change removes the compile time information from the platform string, so that information needs to be preserved in a new attribute. -1 on any new platform identification attribute. We already have too many of them, and there's the platform module for precise identification. Please reread the quoted sentence: The *compile time* version information needs to be preserved. The platform module provide *run-time* information, but doesn't give access to the compile time information. We do have distutils to read the full compile time information, but it's not always available, since it often requires installing development packages. -- ___ 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'
Éric Araujo mer...@netwok.org added the comment: We do have distutils to read the full compile time information We have sysconfig in the stdlib in 2.7 and 3.2+. -- ___ 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
[issue12682] Meaning of 'accepted' resolution as documented in devguide
Antoine Pitrou pit...@free.fr added the comment: I would say I find accepted little useful in practice. Removing it would avoid the confusion with its various (intended or not) meanings. -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12682] Meaning of 'accepted' resolution as documented in devguide
Ezio Melotti ezio.melo...@gmail.com added the comment: +1 Martin, should we convert all the accepted to fixed before removing it? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12682 ___ ___ 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'
Marc-Andre Lemburg m...@egenix.com added the comment: Éric Araujo wrote: Éric Araujo mer...@netwok.org added the comment: We do have distutils to read the full compile time information We have sysconfig in the stdlib in 2.7 and 3.2+. Right (it originated in distutils), but it has the same problem: without the Makefile and pyconfig.h files installed, it cannot do its magic. In addition to that it has the same problem as the platform module: getting the information can be time and resource consuming. -- ___ 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
[issue12784] Concatenation of strings returns the wrong string
New submission from Kåre Krig karek...@gmail.com:
When I concatenate two strings, with the one on the right hand side being
large, the resulting string is almost correct but has a few chars substituted.
The following code (with (...) added on the print statement for 3.1) prints
False on both Python 2.6.5 3.1. The file I read is a 20Mb file of text.
inbuff = open('top.test.in')
full_file = inbuff.readlines()
inbuff.close()
data_string = ''.join(full_file)
buff_A = ' ' + data_string
buff_B = ' ' + data_string
print buff_A == buff_B
I have only been able to test this on one computer, running SUSE. Ram seems
fine as it passed 15h of memtest.
Python versions are:
Python 2.6.5 (r265:79063, May 6 2011, 17:25:59)
[GCC 4.5.0 20100604 [gcc-4_5-branch revision 160292]] on linux2
Python 3.1 (r31:73572, Jul 5 2010, 13:31:53)
[GCC 4.5.0 20100604 [gcc-4_5-branch revision 160292]] on linux2
--
components: None
messages: 142445
nosy: Kåre.Krig
priority: normal
severity: normal
status: open
title: Concatenation of strings returns the wrong string
type: behavior
versions: Python 2.6, Python 3.1
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12784
___
___
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: Please reread the quoted sentence: The *compile time* version information needs to be preserved. Then please give it a very explicit name, such as sys.build_platform or sys.compile_time_version_info. We don't want people to be misled by yet another platform identification attribute. -- ___ 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
[issue12784] Concatenation of strings returns the wrong string
Antoine Pitrou pit...@free.fr added the comment: Have you tried with other large files? Or on another system? -- nosy: +pitrou ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12784] Concatenation of strings returns the wrong string
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12784] Concatenation of strings returns the wrong string
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12409] Moving Documenting Python to Devguide
Éric Araujo mer...@netwok.org added the comment: From IRC: fdrake After last being pressed on this, I got to thinking about it more. Back in the day, that's all the doc there was about the tool-chain. With Sphinx standing as a successful independent project, the tool documentation need no longer be part of any of the python.org docs; what's left probably can be moved. fdrake (Yes, I'm withdrawing my objection.) So, I am in favor of moving the Python-specific parts of Doc/documenting (if any) to the devguide and just link to the upstream Sphinx docs (which are a subset of our Doc/documenting) for the markup and suchlike. -- resolution: rejected - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12409 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12784] Concatenation of strings returns the wrong string
STINNER Victor victor.stin...@haypocalc.com added the comment: Try hash(buff_A) == hash(buff_B). Are you able to identify which bytes/characters are differents? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12784 ___ ___ 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'
Marc-Andre Lemburg m...@egenix.com added the comment:
Antoine Pitrou wrote:
Antoine Pitrou pit...@free.fr added the comment:
Please reread the quoted sentence:
The *compile time* version information needs to be preserved.
Then please give it a very explicit name, such as sys.build_platform
or sys.compile_time_version_info. We don't want people to be misled by
yet another platform identification attribute.
Good idea.
We could simply write `uname -s -r -m` into the new attribute:
sys.build_platform = ('Linux', '2.6.34.8-0.2-desktop', 'x86_64')
and then have
sys.platform = 'linux'
for quick general platform checks.
--
___
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: YAGNI. Nobody has needed sys.build_platform yet. (And no, sys.platform isn't it, since that's been fixed at linux2 approximately forever). Why do you think people would suddenly start needing to know the build-time kernel version now? -- ___ 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
[issue12409] Moving Documenting Python to Devguide
Ezio Melotti ezio.melo...@gmail.com added the comment: +1 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12409 ___ ___ 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'
Marc-Andre Lemburg m...@egenix.com added the comment: James Y Knight wrote: YAGNI. Nobody has needed sys.build_platform yet. (And no, sys.platform isn't it, since that's been fixed at linux2 approximately forever). Why do you think people would suddenly start needing to know the build-time kernel version now? Because it's been integrated to sys.platform for years and on many platforms. If we now plan to remove it, the information has to be available from somewhere else, hence the new attribute. Note that I'm talking about removing it for all platforms, not just Linux, which has had the major version 2 number for 15 years, but also for FreeBSD which releases new major versions far more frequently. The new attribute also helps on Mac OS X and Linux, since it includes the minor version as well. BTW: Your forever is a rather short time period - Python predates Linux :-) -- ___ 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
[issue12784] Concatenation of strings returns the wrong string
Kåre Krig karek...@gmail.com added the comment: I tried it again with another file. This time I used the dictionary from www.math.sjsu.edu/~foster/dictionary.txt (~3Mb) hash(buff_A) == hash(buff_B) returns False just like the direct comparison. I ran the program on dictionary.txt and printed buff_A buff_B to two different files. When running diff on those files the reported differences where: 149668c149668 intraisland --- intrqisland 150052c150052 invernacular --- ynvernacular 230933c230933 perwitsky --- perwitski For my first run, then immediatly running the same script and doing diff again produced another set of differences 253803c253803 recrown --- recrow~ 254213c254213 redisseise --- bedisseise 254656c254656 reflectors --- beflectors 255083c255083 regrating --- regratinw Note how the ascii codes for the faulty characters only differ by one bit, and only the 5th least significant bit. This is consistent with my previous tests. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12784 ___ ___ 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
Antoine Pitrou pit...@free.fr added the comment: 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... The encoder doesn't have to be turned into an iterator. It would just need to call a given callable (fp.write) at regular intervals and that would be enough to C-accelerate dump(). My patch actually provides a good foundation for this. -- ___ 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
[issue12784] Concatenation of strings returns the wrong string
Antoine Pitrou pit...@free.fr added the comment: Note how the ascii codes for the faulty characters only differ by one bit, and only the 5th least significant bit. This looks very much like a hardware issue. Python usually does nothing special with the 5th bit of characters. Also, the IO system and string objects are different in 2.6 and 3.1, so witnessing the same behaviour under both versions points to a likely external cause. Could you try on another system? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12784 ___ ___ 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: It's really hard to follow this issue. I'm trying to sum up, please comment my message if I'm wrong. -- If I understood correctly, this issue has 3 remaining points: (1) Python 2.7 and 3.2: force sys.platform to 'linux2'? Votes: Antoine Pitrou: -1 Victor Stinner: +0 Martin von Gagern: +1 Barry A. Warsaw: +1 Martin v. Löwis: +1 Marc-Andre Lemburg: +1 = total=+3 (6 votes) (2) Python 3.3: change sys.platform to 'linux'? Votes: Martin v. Löwis: +1 Charles-François Natali: -1 Amaury Forgeot d'Arc: -1 Antoine Pitrou: -0 ? Victor Stinner: +1 = total=0 (5 votes) (3) Python 3.3: if point (2) is accepted, add a new variable providing more information about the build platform -- For the first point, it looks like most people agree to keep 'linux2' on Linux 3 for Python 2.7 and 3.2. I converted Matthias Klose's patch (msg140061) into a patch for Python 3.2: configure_linux2.python3.2.patch. If this patch is accepted, changesets 69dd70e70cc8 (2.7) and 9e3b28a7898f (3.2) have to be reverted (issue #12571). I prefer to do nothing for (1), but users usually prefer software that just work. Example: see Arch Linux fiasco when they chose to use Python 3 for /usr/bin/python. Some distro (Debian and Ubuntu?) will anyway use this approach. -- For the second point, there is no consensus. I changed my vote from -1 to +1 because... I would like to close the issue (!) and I agree that I will easier to manipulate 'linux' instead of 'linux2' or 'linux3' or 'linux4' or ... (we have such problem today with freebsd2..freebsd8). -- For the last point, point (3): I think that it would be easier to wait until the point (2) is decided, because the point (3) depends on point (2). @Marc-Andre Lemburg: you might open a different issue (when point 2 will be deciced)? I consider that it is a different topic because sysconfig already contains requested informations and so it's more a new feature. -- Added file: http://bugs.python.org/file22946/configure_linux2.python3.2.patch ___ 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
[issue12657] Cannot override JSON encoding of basic type subclasses
Niko Wilbert m...@nikowilbert.de added the comment: This issue is also a real pain when using namedtuple. In many situations a namedtuple should be serialized as a dict, but there is no reasonable way to get this behavior. Earlier solutions (e.g., see http://stackoverflow.com/questions/5906831/serializing-a-python-namedtuple-to-json) are now broken in Python 2.7. -- nosy: +nikow versions: +Python 2.7 -Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12657 ___ ___ 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'
R. David Murray rdmur...@bitdance.com added the comment: MAL wrote: As already mentioned, the diff between Linux 2.x and 3.x will grow over time and while there may not be much to see now, things will change in the coming years. The only way I can read this argument that makes any sense to me is that you are arguing for a precise build-time OS string. If it is supposed to be an argument in favor of keeping 'linux3' it makes no sense, since '2' vs '3' is in no way a useful line of demarcation when it comes to linux. So, if you think there is a *run time* need to know the precise *build time* OS version number, can you point to any specific use cases? -- ___ 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 19, 2011, at 02:23 PM, STINNER Victor wrote: (2) Python 3.3: change sys.platform to 'linux'? Votes: Martin v. Löwis: +1 Charles-François Natali: -1 Amaury Forgeot d'Arc: -1 Antoine Pitrou: -0 ? Victor Stinner: +1 = total=0 (5 votes) Please add my +1 to this tally. (3) Python 3.3: if point (2) is accepted, add a new variable providing more information about the build platform I'm -0 on this. I think we either have enough information already, or YAGNI. For the second point, there is no consensus. Maybe I tipped it over. :) -- ___ 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: configure_linux2.python3.2.patch It would probably be more future-proof to use linux*), not linux3) in the case expression. -- ___ 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
[issue12784] Concatenation of strings returns the wrong string
STINNER Victor victor.stin...@haypocalc.com added the comment: You should retry memtest86+: http://www.memtest.org/#downiso I had also memory errors recently. After 10 minutes, memtest86+ listed me 4 errors. After 30 minutes, there were 30 errors. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12784 ___ ___ 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'
Éric Araujo mer...@netwok.org added the comment: Python 2.7 and 3.2: force sys.platform to 'linux2'? -0. I dislike this change for stable releases, but it’s a small change that would help a lot of users. I think the release managers would need to approve such a change. Python 3.3: change sys.platform to 'linux'? +1! Python 3.3: if point (2) is accepted, add a new variable providing more information about the build platform -0. BTW, your tallies are wrong: a +0 is more supportive than a -0, but your additions don’t show that. :) -- nosy: +benjamin.peterson, georg.brandl ___ 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
[issue12784] Concatenation of strings returns the wrong string
Kåre Krig karek...@gmail.com added the comment: I managed to get access to another two systems to test this on. One running ubuntu python 2.7.1 and the other suse python 2.6. I could not reproduce the bug on either of those systems. This all points to the issue not really being a bug in python but something on my system. The fact that I could predictably produce this bug using 20Mb of data, then pass 15 hours of memtest86+ and finally produce the bug again makes me think it's not the ram system, but there are of course layers between python and the ram that might be broken. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12784 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12784] Concatenation of strings returns the wrong string
STINNER Victor victor.stin...@haypocalc.com added the comment: It's an hardware problem, not a Python problem, so I close this issue. Check your RAM and the temperature of your mother board and of the CPU using your tests (e.g. try lm-sensors on Linux). -- resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12784 ___ ___ 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
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 40f4a3d6a532 by Éric Araujo in branch 'default': Restore $HOME after test has run (should fix #12765) http://hg.python.org/cpython/rev/40f4a3d6a532 -- nosy: +python-dev ___ 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
[issue12765] test_packaging failure under Snow Leopard
Éric Araujo mer...@netwok.org added the comment: Thank you sir! How did you find it? -- resolution: - fixed stage: needs patch - commit review status: open - pending ___ 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
[issue9200] Make str methods work with non-BMP chars on narrow builds
Ezio Melotti ezio.melo...@gmail.com added the comment:
Here's a new version of the patch.
I decided to leave the prefix anyway, for consistency with what I'll commit to
3.3 and because without the prefix NEXT() looks ambiguous (and it's not
entirely clear if it's private or not).
I rewrote the macro as Victor suggested and tested that it still works (I also
added a test with surrogates).
The macros are now called _Py_UNICODE_IS_{LOW|HIGH}_SURROGATE, with '_'s. I
also tried the implementation proposed in #12751 and benchmarked with:
$ ./python -m timeit -s 's = \uD800\uD8000\uDFFF\uDFFF\uDFFF*1000'
's.islower()'
and got 1000 loops, best of 3: 345 usec per loop on both, so I left the old
version because I think it's more readable.
Finally, I rewrote the comment about the macro, adding a note about its side
effects.
--
stage: patch review - commit review
versions: +Python 2.7, Python 3.3
Added file: http://bugs.python.org/file22947/issue9200-2.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
[issue12785] list_distinfo_file is wrong
New submission from Éric Araujo mer...@netwok.org: The list_distinfo_files method does not fulfills its mission. I changed the test file to be more stupid (and therefore not use high-level functions that we can’t trust) when building the expected list and discovered that list_distinfo_files returned too many files! I would need someone to test the attached patch on Windows to see if I need to replace '/' in self.path or not (the code before the XXX comment). -- assignee: eric.araujo components: Distutils2 messages: 142469 nosy: alexis, eric.araujo, higery, michael.mulich priority: high severity: normal stage: patch review status: open title: list_distinfo_file is wrong type: behavior versions: Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12785] list_distinfo_file is wrong
Changes by Éric Araujo mer...@netwok.org: -- keywords: +patch Added file: http://bugs.python.org/file22948/fix-list_distinfo_files.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12785 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12678] test_packaging and test_distutils failures under Windows
Changes by Éric Araujo mer...@netwok.org: -- dependencies: +list_distinfo_file is wrong ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12678 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12678] test_packaging and test_distutils failures under Windows
Éric Araujo mer...@netwok.org added the comment: I don’t understand this part: Traceback (most recent call last): File distutils\tests\test_sdist.py, line 385, in test_manual_manifest archive = tarfile.open(archive_name) File tarfile.py, line 1736, in open return func(name, r, fileobj, **kwargs) File tarfile.py, line 1806, in gzopen fileobj.close() AttributeError: 'NoneType' object has no attribute 'close' The code is protected by a skipUnless(ZLIB_SUPPORT), so how can the tarfile object be None? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12678 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1492704] distinct error type from shutil.move()
Éric Araujo mer...@netwok.org added the comment: Thanks for the patch. I made a review on Rietveld; a mail should have been sent. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1492704 ___ ___ 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
Changes by Antoine Pitrou pit...@free.fr: -- resolution: - fixed stage: - committed/rejected status: open - closed ___ 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
[issue12778] JSON-serializing a large container takes too much memory
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 47176e8d7060 by Antoine Pitrou in branch 'default': Issue #12778: Reduce memory consumption when JSON-encoding a large container of many small objects. http://hg.python.org/cpython/rev/47176e8d7060 -- nosy: +python-dev ___ 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
[issue12659] Add tests for packaging.tests.support
Éric Araujo mer...@netwok.org added the comment: I made a review on Rietveld; a mail should have been sent. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12659 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12765] test_packaging failure under Snow Leopard
Ned Deily n...@acm.org added the comment: I found it by patching the appropriate unittest test runner to check before and after each test case. It would be nice if there were a standard option to do that. -- status: pending - open ___ 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
[issue12786] subprocess wait() hangs when stdin is closed
New submission from Idan Kamara idank...@gmail.com: The following program hangs on Debian, Python 2.6.6: import subprocess proc1 = subprocess.Popen(['cat'], stdin=subprocess.PIPE) proc2 = subprocess.Popen(['cat'], stdin=subprocess.PIPE) proc1.stdin.close() proc1.wait() Changing the last two lines to: proc2.stdin.close() proc2.wait() Doesn't hang. The guys at #python-dev confirmed the same happens on 2.7 but not on 3.x. -- components: Library (Lib) messages: 142475 nosy: Idan.Kamara priority: normal severity: normal status: open title: subprocess wait() hangs when stdin is closed type: resource usage versions: Python 2.6, Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12786 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12786] subprocess wait() hangs when stdin is closed
Changes by Antoine Pitrou pit...@free.fr: -- nosy: +neologix type: resource usage - behavior ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12786 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11564] pickle not 64-bit ready
Nadeem Vawda nadeem.va...@gmail.com added the comment: D'oh. I just realized why the -M option wasn't being recognized - I had passed it after the actual test name, so it was being treated as another test instead of an option. Sorry for the confusion :/ As for the actual test results, test_huge_bytes_(32|64)b both pass, but test_huge_str fails with this traceback: == FAIL: test_huge_str (test.test_pickle.InMemoryPickleTests) -- Traceback (most recent call last): File /usr/local/google/home/nadeemvawda/code/cpython/3.2/Lib/test/support.py, line 1108, in wrapper return f(self, maxsize) File /usr/local/google/home/nadeemvawda/code/cpython/3.2/Lib/test/pickletester.py, line 1151, in test_huge_str self.dumps(data, protocol=proto) AssertionError: (class 'ValueError', class 'OverflowError') not raised The same error occurs on the default branch. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11564 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11564] pickle not 64-bit ready
Antoine Pitrou pit...@free.fr added the comment: D'oh. I just realized why the -M option wasn't being recognized - I had passed it after the actual test name, so it was being treated as another test instead of an option. Sorry for the confusion :/ As for the actual test results, test_huge_bytes_(32|64)b both pass, but test_huge_str fails with this traceback: Can you replace _2G with _4G in the decorator for that test? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11564 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12781] Mention SO_REUSEADDR near socket doc examples
Sandro Tosi sandro.t...@gmail.com added the comment: Sure it could be a solution, but I didn't go that way since it *may* complicate the example (which I see a something to get quick ready to test some code, there's always time for improvements later). I'm fine either way. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12781 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12213] BufferedRandom, BufferedRWPair: issues with interlaced read-write
Antoine Pitrou pit...@free.fr added the comment: I think your expectations for BufferedRWPair are wrong. You should not use BufferedRWPair with the same underlying stream (that's the whole point of BufferedRWPair). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12213 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12191] Add shutil.chown to allow to use user and group name (and not only uid/gid)
Sandro Tosi sandro.t...@gmail.com added the comment: version 7 here we come :) I've addressed Eric's commenta on rietveld (all but one, I need input from him) and also updated the tests for new helper functions. -- Added file: http://bugs.python.org/file22949/shutil_chown-default-v7.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12191 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11564] pickle not 64-bit ready
Nadeem Vawda nadeem.va...@gmail.com added the comment: Can you replace _2G with _4G in the decorator for that test? I'm not at work any more, but I'll try that out on Monday. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11564 ___ ___ 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'
Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: STINNER Victor victor.stin...@haypocalc.com added the comment: It's really hard to follow this issue. I'm trying to sum up, please comment my message if I'm wrong. -- If I understood correctly, this issue has 3 remaining points: (1) Python 2.7 and 3.2: force sys.platform to 'linux2'? Votes: Antoine Pitrou: -1 Victor Stinner: +0 Martin von Gagern: +1 Barry A. Warsaw: +1 Martin v. Löwis: +1 Marc-Andre Lemburg: +1 I voted -1 on this, not +1. For existing releases, we cannot change the value of the sys variable and as explained this is not needed either. IMHO, it's better to fix the few cases in Python that use 'linux2' to also include 'linux3' (either literally or via .startswith()) and also add a plat-linux3/ dir. = total=+3 (6 votes) (2) Python 3.3: change sys.platform to 'linux'? Votes: Martin v. Löwis: +1 Charles-François Natali: -1 Amaury Forgeot d'Arc: -1 Antoine Pitrou: -0 ? Victor Stinner: +1 I voted +1 on this one. I also suggested to apply the version removal to all platforms, not just Linux. = total=0 (5 votes) (3) Python 3.3: if point (2) is accepted, add a new variable providing more information about the build platform -- For the first point, it looks like most people agree to keep 'linux2' on Linux 3 for Python 2.7 and 3.2. I converted Matthias Klose's patch (msg140061) into a patch for Python 3.2: configure_linux2.python3.2.patch. If this patch is accepted, changesets 69dd70e70cc8 (2.7) and 9e3b28a7898f (3.2) have to be reverted (issue #12571). I prefer to do nothing for (1), but users usually prefer software that just work. Example: see Arch Linux fiasco when they chose to use Python 3 for /usr/bin/python. Some distro (Debian and Ubuntu?) will anyway use this approach. -- For the second point, there is no consensus. I changed my vote from -1 to +1 because... I would like to close the issue (!) and I agree that I will easier to manipulate 'linux' instead of 'linux2' or 'linux3' or 'linux4' or ... (we have such problem today with freebsd2..freebsd8). -- For the last point, point (3): I think that it would be easier to wait until the point (2) is decided, because the point (3) depends on point (2). @Marc-Andre Lemburg: you might open a different issue (when point 2 will be deciced)? I consider that it is a different topic because sysconfig already contains requested informations and so it's more a new feature. That would make sense, except that I view the removal of the version and the addition of the compile time information as one feature request. Moving this off to the sysconfig is not realistic as mentioned before and the new variable doesn't really cost much in terms maintenance, since it can be auto-generated by configure. -- ___ 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
[issue12786] subprocess wait() hangs when stdin is closed
Ben Wolfson wolf...@gmail.com added the comment: The guys at #python-dev confirmed the same happens on 2.7 but not on 3.x. Really? This is on gentoo, not debian, admittedly: coelacanth ~ 11:12:36 $ python3 Python 3.1.3 (r313:86834, May 1 2011, 09:41:48) [GCC 4.4.4] on linux2 Type help, copyright, credits or license for more information. import subprocess proc1 = subprocess.Popen(['cat'], stdin=subprocess.PIPE) proc2 = subprocess.Popen(['cat'], stdin=subprocess.PIPE) proc2.stdin.close() proc2.wait() 0 coelacanth ~ 11:12:13 $ python3.1 Python 3.1.3 (r313:86834, May 1 2011, 09:41:48) [GCC 4.4.4] on linux2 Type help, copyright, credits or license for more information. import subprocess proc1 = subprocess.Popen(['cat'], stdin=subprocess.PIPE) proc2 = subprocess.Popen(['cat'], stdin=subprocess.PIPE) proc1.stdin.close() proc1.wait() [hangs] -- nosy: +Ben.Wolfson ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12786 ___ ___ 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: It would just need to call a given callable (fp.write) at regular intervals and that would be enough to C-accelerate dump(). True, but that would just special case dump(), just like dumps() is special-cased now. Ideally JSONEncoder.iterencode() would be accelerated, so you wouldn't need any special cases. Or deprecate iterencode() and replace it with a callback interface... -- ___ 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
[issue12786] subprocess wait() hangs when stdin is closed
Charles-François Natali neolo...@free.fr added the comment: Hello Idan, The following program hangs on Debian Debian is a good choice :-) Concerning your example, it hangs is because the file descriptor used to communicate with proc1 is inherited when proc2 is created (FDs are inherited upon fork by default): thus, when you call proc1.stdin.close(), `cat` doesn't receive EOF on read(0), and remains stuck. If you close proc2's stdin and wait it first, then you don't have this problem: - because it's been created after proc1, its stdin FD has not been inherited - when you call proc2.stdin.close(), `cat` receives EOF from read(0), and exits There are two reasons while it doesn't hang on Python 3.x: 1) it uses close_fds=True by default 2) it sets the pipe FDs CLOEXEC, so that they're closed when cat is `executed` Try with proc1 = subprocess.Popen(['cat'], stdin=subprocess.PIPE) proc2 = subprocess.Popen(['cat'], stdin=subprocess.PIPE, close_fds=True) proc1.stdin.close() proc1.wait() And you'll be fine. We can't make the change 1) in 2.7, because that's a behavior change. We could however set the FDs used to communicate with the children CLOEXEC. I'll work on a patch for 2.7 (but it won't be thread-safe, because pipe2 is not exposed and there's no _posixsubprocess.c like in 3.x). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12786 ___ ___ 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
Antoine Pitrou pit...@free.fr added the comment: It would just need to call a given callable (fp.write) at regular intervals and that would be enough to C-accelerate dump(). True, but that would just special case dump(), just like dumps() is special-cased now. Ideally JSONEncoder.iterencode() would be accelerated, so you wouldn't need any special cases. Or deprecate iterencode() and replace it with a callback interface... Is iterencode() used much? I would think dump() and dumps() see the most use. -- ___ 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
[issue12213] BufferedRandom, BufferedRWPair: issues with interlaced read-write
Antoine Pitrou pit...@free.fr added the comment: Here is a patch. -- stage: - patch review Added file: http://bugs.python.org/file22950/bufrandom.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12213 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1626300] 'Installing Python Modules' does not work for Windows
Terry J. Reedy tjre...@udel.edu added the comment: On my fresh install, double clicking *does* run the file as it should, but the window disappears immediately, erasing output and error tracebacks, unless one adds something like ``input(Hit Enter to quit) at the end of the script so the user can see any output. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1626300 ___ ___ 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: Is iterencode() used much? I would think dump() and dumps() see the most use. Of course. I'd just prefer an elegant complete solution. But I agree accelerating just dump() would already be much better than the current situation. -- ___ 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
[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'
Dave Malcolm dmalc...@redhat.com added the comment: Note that PyPy is also affected by this issue; see https://bugs.pypy.org/issue832 For CPython, I'm of the opinion that: - the final digit of sys.platform as-is for linux* is effectively meaningless - that no code should be relying on the final digit of sys.platform (thankfully this is now recommended by: http://docs.python.org/library/sys.html#sys.platform ) - unfortunately there is code out there that checks against linux2 and thus does rely on this value - patching CPython to force this to read linux2 may be necessary for some downstream distributors of Python, to maximize compatibility with such broken code. For CPython, sys.platform currently reports on the difference between whether uname reported linux2 or linux3 at build time, which is currently meaningless (see msg142219 above about our chroot-ed build environment). For example, in RHEL we may at some future time upgrade our build farm to linux 3, but still provision our build trees within it for linux 2; this may mean that our build farm starts reporting linux3 when rebuilding security updates for python 2.2, 2.3, 2.4 or 2.6, even when building against kernel-2.*'s user-space. If this happens, I'd be inclined to patch those builds of Python back to linux2. It would be entirely meaningless and only damaging for one of our security updates of, say, Python 2.2 to shift sys.platform from linux2 to linux3 simply because of the kernel that was running in the build environment (as opposed to the kernel headers exposed to the compiler, and other such aspects of the kernel exposed in user-space). FWIW, my opinion is currently: - in 3.3, sys.platform on linux should be simply linux - for 2.7 and 3.2, sys.platform should be forced to linux2 (and indeed, I anticipate doing this for earlier releases that I still maintain downstream) - existing documentation should say that on linux, sys.platform begins with linux, and that programmers should avoid relying upon the suffix - I don't see the need for more adding access to more details of the build platform (and I can poke holes in any such plan, if anyone wants me to: what would it contain? what about the case where the user-space files e.g. headers aren't the same as the uname? 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
[issue12682] Meaning of 'accepted' resolution as documented in devguide
Terry J. Reedy tjre...@udel.edu added the comment: Only if the issue is closed, so that it actually means 'fixed'. Otherwise, just delete it. The following data suggests to me that 'accepted' is a de facto synonym for 'fixed' and therefore useless and might as well be removed. N Issue category 3290 fixed 68 open 3219 closed 354 feature request (and closed) 302 behavior 126 other type 2437 type not specified 346 documentation component (and type not specified) 679 library component The type field has been, at least in the past, greatly underused. But of the last 679, only 27 were in the last 3 years. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12713] argparse: allow abbreviation of sub commands by users
Christian Ziemski cz...@gmx.de added the comment: I just made such a change to Python 2.7's argparse. If there is interest I'll post a patch here. Unfortunately I can't find the description how to produce a proper patch. The link I found (http://www.python.org/dev/patches/) gives an error 404. -- nosy: +chriz ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12713 ___ ___ 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'
Marc-Andre Lemburg m...@egenix.com added the comment: R. David Murray wrote: R. David Murray rdmur...@bitdance.com added the comment: MAL wrote: As already mentioned, the diff between Linux 2.x and 3.x will grow over time and while there may not be much to see now, things will change in the coming years. The only way I can read this argument that makes any sense to me is that you are arguing for a precise build-time OS string. If it is supposed to be an argument in favor of keeping 'linux3' it makes no sense, since '2' vs '3' is in no way a useful line of demarcation when it comes to linux. Indeed. See the sys.build_platform attribute we discussed. So, if you think there is a *run time* need to know the precise *build time* OS version number, can you point to any specific use cases? I already mentioned those use cases. Please see the ticket discussion. -- ___ 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
[issue12745] Python2 or Python3 page
Terry J. Reedy tjre...@udel.edu added the comment: I agree with your sentiments about Python 2 while being aware that not all agree yet and that the current Wiki page was the result of some heated discussion and compromise. I also agree that the page could use tweaking/updating/rewriting. For one thing the supposed 2010 date in inconsistent with 3.2 being released. Python 3 is the future of the language. kind of implies that it is not the current version of the language. I would change that to Python 3 is the present and future of the language I might start with discussion of 3 rather that 2. I am closing this simply because it is not about changing the CPython repository, which is what the tracker tracks. There is no way to attach and review a wiki diff here. -- nosy: +terry.reedy resolution: - invalid status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12745 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12786] subprocess wait() hangs when stdin is closed
Changes by Mads Kiilerich m...@kiilerich.com: -- nosy: +kiilerix ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12786 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12682] Meaning of 'accepted' resolution as documented in devguide
Martin v. Löwis mar...@v.loewis.de added the comment: Martin, should we convert all the accepted to fixed before removing it? That's not strictly necessary. It would only be retired (roundup does not support true removal), and as such would then still show up in issues that currently use it, but not show up elsewhere anymore. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12678] test_packaging and test_distutils failures under Windows
Georg Brandl ge...@python.org added the comment: This failure needs to be gone in time for 3.2.2. Please find an appropriate way to fix it, even if it is the temporary disabling of a faulty test. -- nosy: +benjamin.peterson, georg.brandl priority: high - release blocker ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12678 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12682] Meaning of 'accepted' resolution as documented in devguide
Ezio Melotti ezio.melo...@gmail.com added the comment: OK, I removed the resolution and its documentation from the devguide in 3f4710b6baf9. -- resolution: - fixed stage: needs patch - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12682 ___ ___ 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 only way I can read this argument that makes any sense to me is that you are arguing for a precise build-time OS string. If it is supposed to be an argument in favor of keeping 'linux3' it makes no sense, since '2' vs '3' is in no way a useful line of demarcation when it comes to linux. The build time Linux kernel has no effect on Python's build procedure whatsoever. Python does not use the kernel at all for building; it only uses the C library headers, and the kernel headers that happen to be incorporated into the version of the C library installed. That affects what features get selected during build time. Notice that the proposed fix to keep os.platform to linux2 actually means that there is *no change*, as os.platform always was linux2 on the system. It is a bug that it reports linux3 in some cases, and that bug is being fixed. -- ___ 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'
Matthias Klose d...@debian.org added the comment: The build time Linux kernel has no effect on Python's build procedure whatsoever. Python does not use the kernel at all for building; it only uses the C library headers, and the kernel headers that happen to be incorporated into the version of the C library installed. That affects what features get selected during build time. would be very nice, but unfortunately this is not true; the multiprocessing behavior depends on configure checks testing the running kernel. -- ___ 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'
Marc-Andre Lemburg m...@egenix.com added the comment: Martin v. Löwis wrote: Martin v. Löwis mar...@v.loewis.de added the comment: The only way I can read this argument that makes any sense to me is that you are arguing for a precise build-time OS string. If it is supposed to be an argument in favor of keeping 'linux3' it makes no sense, since '2' vs '3' is in no way a useful line of demarcation when it comes to linux. The build time Linux kernel has no effect on Python's build procedure whatsoever. Python does not use the kernel at all for building; it only uses the C library headers, and the kernel headers that happen to be incorporated into the version of the C library installed. That affects what features get selected during build time. That last sentence contradicts the first one. In any case, you're right: the OS build version does affect the Python build. And not only on Linux, but on all OSes Python runs on. That said, the changes on Linux that affect Python are minimal compared to what other vendors do for even minor OS releases, e.g. Apple with Mac OS X. Notice that the proposed fix to keep os.platform to linux2 actually means that there is *no change*, as os.platform always was linux2 on the system. It is a bug that it reports linux3 in some cases, and that bug is being fixed. There are Linux 2.x systems out there that report sys.platform == 'linux3' ? :-) -- ___ 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
[issue12786] subprocess wait() hangs when stdin is closed
Charles-François Natali neolo...@free.fr added the comment: Here's a patch + test for 2.7. Really? This is on gentoo, not debian, admittedly: That's because the change of close_fds to True by default and the CLOEXEC flag were added in 3.2. Since 3.1 is in security-fix mode only, this patch is only relevant to 2.7. -- keywords: +needs review, patch nosy: +haypo stage: - patch review versions: -Python 2.6 Added file: http://bugs.python.org/file22951/subprocess_cloexec.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12786 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12753] \N{...} neglects formal aliases and named sequences from Unicode charnames namespace
Terry J. Reedy tjre...@udel.edu added the comment:
I verified that the test file raises the quoted SyntaxError on 3.2 on Win7.
This:
\N{LATIN CAPITAL LETTER GHA}
SyntaxError: (unicode error) 'unicodeescape' codec can't decode bytes in
position 0-27: unknown Unicode character name
is most likely a result of this:
unicodedata.lookup(LATIN CAPITAL LETTER GHA)
Traceback (most recent call last):
File pyshell#1, line 1, in module
unicodedata.lookup(LATIN CAPITAL LETTER GHA)
KeyError: undefined character name 'LATIN CAPITAL LETTER GHA'
Although the lookup comes first in nametests.py, it is never executed because
of the later SyntaxError.
The Reference for string literals says
\N{name} Character named name in the Unicode database
The doc for unicodedata says
This module provides access to the Unicode Character Database (UCD) which
defines character properties for all Unicode characters. The data contained in
this database is compiled from the UCD version 6.0.0.
The module uses the same names and symbols as defined by Unicode Standard Annex
#44, “Unicode Character Database”.
http://www.unicode.org/reports/tr44/tr44-6.html
So the question is, what are the 'names' therein defined?
All such should be valid inputs to
unicodedata.lookup(name) Look up character by name.
The annex refers to http://www.unicode.org/Public/6.0.0/ucd/
This contains NamesList.txt, derived from UnicodeData.txt. Unicodedata must be
using just the latter. The ucd directory also contains NameAliases.txt,
NamedSequences.txt, and the file of provisional named sequences.
As best I can tell, the annex plus files are a bit ambiguous as to 'Unicode
character name'. The following quote seems neutral: the Unicode Character
Database (UCD), a collection of data files which contain the Unicode character
code points and character names. The following: Unicode character names
constitute a special case. Formally, they are values of the Name property.
points toward UnicodeData.txt, which lists the Name property along with others.
However, Unicode character name, as published in the Unicode names list,
indirectly points toward including aliases. NamesList.txt says it contains the
Final Unicode 6.0 names list. (but one which should not be parsed for
machine-readable information. It includes all 11 aliases in NameAliases.txt.
My current opinion is that adding the aliases might be done in current
releases. It certainly would serve the any user who does not know to misspell
'FTHORA' as 'FHTORA' for just one of the 17 'FTHORA' chars.
Adding named sequences is definitely a feature request. The definition of
.lookup(name) would be enlarged to Look up character by name, alias, or named
sequence with reference to the specific files. The meaning of \N{} would also
have to be enlarged.
Minimal test code might be:
from unicodedata import lookup
AssertEqual(lookup(LATIN CAPITAL LETTER GHA)), \u01a2)
AssertEqual(lookup(LATIN CAPITAL LETTER A WITH MACRON AND GRAVE),
\u0100\u0300)
plus a test that \N{LATIN CAPITAL LETTER GHA} and
\N{LATIN CAPITAL LETTER A WITH MACRON AND GRAVE} compile without error (I
have no idea how to write that).
---
If you look at the ICU UCharacter class, you can see that they provide a
more
More what ;-)
I presume ICU =International Components for Unicode, icu-project.org/
Offers a portable set of C/C++ and Java libraries for Unicode support,
software internationalization (I18N) and globalization (G11N).
[appears to be free, open source, and possibly usable within Python]
--
nosy: +terry.reedy
stage: test needed - needs patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12753
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12772] fractional day attribute in datetime class
Alexander Belopolsky alexander.belopol...@gmail.com added the comment: You can easily get the fractional day value using existing functionality: from datetime import * (datetime(2011,8,15,18,30) - datetime(2011,8,13,12,0)) / timedelta(1) 2.27083335 (datetime(2011,8,15,18,30) - datetime(1970,1,1)) / timedelta(1) 15201.77083334 In some sense this request is a duplicate of issue2736. -- assignee: - belopolsky nosy: +belopolsky resolution: - rejected stage: - committed/rejected status: open - pending ___ 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
