[issue10713] re module doesn't describe string boundaries for \b
Martin Pool m...@sourcefrog.net added the comment: Note, 366 above confirms it's never true for an empty string. The documentation states that \B is just the opposite of \b yet re.match(r'\b', '') returns None and so does \B so \B isn't the opposite of \b in all cases. This is also a bit strange if you follow the Perl line of reasoning of imagining there are non-word characters outside the string. And, indeed, in Perl, =~ /\B/ is true. So this patch adds some tests for \b behaviour and some docs. I think possible \B should actually change, but that would be a bigger (perhaps impossible?) change. -- keywords: +patch nosy: +poolie Added file: http://bugs.python.org/file22991/20110822-1604-re-docs.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10713 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6484] No unit test for mailcap module
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 69cb66ab61cc by Nick Coghlan in branch 'default': Add unit tests for the mailcap module. Patch by Gregory Nofi (closes #6484) http://hg.python.org/cpython/rev/69cb66ab61cc -- nosy: +python-dev resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6484 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12811] Tabnanny doesn't close its tokenize files properly
New submission from Anthony Briggs anthony.bri...@gmail.com: Unlike Python 2, Python 3 warns when files aren't closed properly, which raises lots of warnings when running tabnanny: ~/devinabox/cpython$ ./python -m tabnanny Lib/ /home/anthony/devinabox/cpython/Lib/tabnanny.py:93: ResourceWarning: unclosed file _io.TextIOWrapper name='Lib/sunau.py' mode='r' encoding='utf-8' check(fullname) /home/anthony/devinabox/cpython/Lib/tabnanny.py:93: ResourceWarning: unclosed file _io.TextIOWrapper name='Lib/sre_compile.py' mode='r' encoding='utf-8' check(fullname) /home/anthony/devinabox/cpython/Lib/tabnanny.py:93: ResourceWarning: unclosed file _io.TextIOWrapper name='Lib/this.py' mode='r' encoding='utf-8' check(fullname) /home/anthony/devinabox/cpython/Lib/tabnanny.py:93: ResourceWarning: unclosed file _io.TextIOWrapper name='Lib/difflib.py' mode='r' encoding='utf-8' check(fullname) The attached patch fixes the problem. -- components: Library (Lib) files: tabnanny_close_file.patch keywords: patch messages: 142681 nosy: anthonyb, ncoghlan priority: normal severity: normal status: open title: Tabnanny doesn't close its tokenize files properly type: resource usage versions: Python 3.3 Added file: http://bugs.python.org/file22992/tabnanny_close_file.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12811 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10951] gcc 4.6 warnings
Martin Pool m...@sourcefrog.net added the comment: My patch above fixes all the messages so that you get a clean build with the current makefile. -Wuninitialized and 'offset outside constant string' would be worth fixing but I can't reproduce them in Python. I'm personally not so keen on fixing all the signed/unsigned comparisons unless they're checked by the default build, because in my experience that has a pretty low payoff and some chance of introducing errors. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10951 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12811] Tabnanny doesn't close its tokenize files properly
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset c5cb0aa5bed6 by Nick Coghlan in branch 'default': Fix #12811 by closing files promptly in tabnanny.check. Patch by Anthony Briggs. http://hg.python.org/cpython/rev/c5cb0aa5bed6 -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12811 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11657] multiprocessing_{send,recv}fd fail with fds 256
Nick Coghlan ncogh...@gmail.com added the comment: For 3.3, it may be relevant that send/recvmsg are now available via the socket API (see #6560) -- nosy: +ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11657 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6560] socket sendmsg(), recvmsg() methods
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 37721ee145a2 by Nick Coghlan in branch 'default': Credit patch authors in NEWS for #6560 http://hg.python.org/cpython/rev/37721ee145a2 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6560 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12812] libffi does not build with clang on amd64
New submission from Joel j...@jms.id.au: tl;dr libffi needs to be updated so Python will build with clang on Linux on amd64 libffi, part of ctypes, has a test for PC relative relocations. It assembles a assembler file with CC, and looks for the string warning in the output. clang produces harmless warning unrelated to the assembly operation, but the test causes HAVE_AS_X86_PCREL to be left unset. When trying to assemble Modules/_ctypes/libffi/src/x86/unix64.S, the compiler finds invalid syntax and the build fails. This was raised on the libffi mailing list, with a proposed patch http://sourceware.org/ml/libffi-discuss/2011/msg00024.html The patch appears to be part of upstream libffi: https://github.com/atgreen/libffi/blob/master/configure.ac#L296 So perhaps the best fix would be to update the version of libffi in the tree. -- components: Build messages: 142686 nosy: shenki priority: normal severity: normal status: open title: libffi does not build with clang on amd64 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12812 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue7584] datetime.rfcformat() for Date and Time on the Internet
Martin Pool m...@sourcefrog.net added the comment: Z is well established as meaning UTC time http://en.wikipedia.org/wiki/Coordinated_Universal_Time#Time_zones so shouldn't be used for zone not known. rfc 3393 is clear that it's equivalent to +00:00. So the questions seem to be: * should there be an included battery to do this format at all? * should it represent utc as '+00:00' or as 'Z' by default - applications should have the choice. It's probably reasonable to assume correct Python application code using datetime objects will know whether they have a local, utc, or unknown time. The current patch does not seem to have any way to format an object with a declared UTC tzinfo as having a 'Z' prefix, which would be useful. -- nosy: +poolie ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue7584 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12813] uuid4 is not tested if a uuid4 system routine isn't present
New submission from Matt Joiner anacro...@gmail.com: The uuid.uuid4 function is not tested if a C system routine is not present, despite that uuid4 has several fallback clauses. This patch will test at least the first fallback. -- components: Library (Lib) files: uuid4-test-no-system-routine-fallback.patch keywords: patch messages: 142688 nosy: anacrolix priority: normal severity: normal status: open title: uuid4 is not tested if a uuid4 system routine isn't present type: behavior versions: Python 3.3 Added file: http://bugs.python.org/file22993/uuid4-test-no-system-routine-fallback.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12813 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12814] Possible intermittent bug in test_array
New submission from Nick Coghlan ncogh...@gmail.com: Had a weird bug in test_array.test_tofromstring failing on Gentoo by generating too few warning messages: http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%20Non-Debug%203.x/builds/568/steps/test/logs/stdio http://www.python.org/dev/buildbot/all/builders/AMD64%20Gentoo%20Wide%203.x/builds/2262/steps/test/logs/stdio Can't see anything obvious as to why that might fail sometimes or only on specific platforms (note that the subsequent build of the x86 Gentoo box worked OK). None of my checkins today should have affected anything like this. -- messages: 142689 nosy: ncoghlan priority: normal severity: normal status: open title: Possible intermittent bug in test_array ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12814 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6560] socket sendmsg(), recvmsg() methods
Charles-François Natali neolo...@free.fr added the comment: New changeset c64216addd7f by Nick Coghlan in branch 'default': Add support for the send/recvmsg API to the socket module. Patch by David Watson and Heiko Wundram. (Closes #6560) http://hg.python.org/cpython/rev/c64216addd7f I had actually started doing a review, I should have said so... There was nothing spectacular though, so I'll just make some updates later. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6560 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11657] multiprocessing_{send,recv}fd fail with fds 256
Charles-François Natali neolo...@free.fr added the comment: I'm fine if you fix it, as I'm currently really short on time myself. OK, I'll go ahead. For 3.3, it may be relevant that send/recvmsg are now available via the socket API (see #6560). Indeed. We might still need C code for the Windows part (I won't be able to help much with Windows, I'm blissfully ignorant). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11657 ___ ___ 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
Martin v. Löwis mar...@v.loewis.de added the comment: For the record, the speed improvement in 2.7 likely results from 79276316b94b. GC used to be quadratic with the number of objects, and is now only linear. -- ___ 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
[issue12780] Clean up tests for pyc/pyo in __file__
Barry A. Warsaw ba...@python.org added the comment: Seems reasonable to me. When did/does unicodedata ever have a __file__ attribute? -- ___ 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'
STINNER Victor victor.stin...@haypocalc.com added the comment: Where's the doc updates for the stable branches? I don't know how to update this documentation. Can someone update the doc, or suggest a patch? Also, we might think about removing this version number everywhere. Please, see my issue http://bugs.python.org/issue12795 for this topic. -- ___ 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
[issue6560] socket sendmsg(), recvmsg() methods
Nick Coghlan ncogh...@gmail.com added the comment: Someone here at the sprints pointed out a redundant unsigned comparison to 0 that I missed, so a second set of eyes to double-check things like that would be good. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6560 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12811] Tabnanny doesn't close its tokenize files properly
Changes by Nick Coghlan ncogh...@gmail.com: -- nosy: -python-dev resolution: - fixed stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12811 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12815] Coverage of smtpd.py
New submission from Tennessee Leeuwenburg tleeuwenb...@gmail.com: Okay, I really don't know if I'm doing the right things to test meaningfully here. However, 100% coverage of the PureProxy class has been achieved. I also slightly changed smtpd.py in a way that I'm not confident is what people would want. I pushed one print statement into the debug stream, and raised an exception in a place where it looked like the expected behaviour wasn't properly defined, but it's probably not a good place to fail if you're using the code. I'm also not an SMTP expert... yes there's an RFC but I was going for coverage with just enough correctness. I'm more than happy to revisit this work if anyone has any comments or issues, so just let me know. -- files: PureProxy.diff keywords: patch messages: 142696 nosy: giampaolo.rodola, ncoghlan, tleeuwenburg priority: normal severity: normal status: open title: Coverage of smtpd.py Added file: http://bugs.python.org/file22994/PureProxy.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12815 ___ ___ 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: Georg Brandl wrote: Also, we might think about removing this version number everywhere. +1 -- ___ 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: So what about doing the same for FreeBSD, SunOS, and Windows? I agree that's definitely out of scope of this issue. We could change the title of the ticket :-) If we're changing linux2 / linux3 to just linux, we should be consistent and do it for everybody. I propose sys.platform under 3.3 should contain things like linux, freebsd, openbsd, darwin, and windows. Definitely not. The reasoning that applies to Linux doesn't necessarily apply to the other systems. My understanding that it definitely does not apply to HP-UX, where major version number changes really indicate major changes (unlike in Linux). Actually, with that reasoning we would need to reintroduce the version for Mac OS, and even go a step further and add the minor version number as well, since since major changes have happened on Mac OS with every single minor release for the last couple of years. IMO, a better approach is to split the information in two parts: * sys.platform, which only specifies the platform name on which Python was built (uname -s) * sys.platform_build_version, which provides the full platform version (uname -r; either as string or as tuple or both - that would have to be hashed out) -- ___ 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
[issue12794] platform: add a major function to get the system major version
Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: STINNER Victor victor.stin...@haypocalc.com added the comment: I'm not sure I understand why platform.release() isn't sufficient for this purpose. Note that some systems return alphanumeric values for platform.release(), e.g. for Windows you get 'NT' or 'XP'. It's not easy to get 2 (int) from '2.6.38-8-generic' (str). For Windows, there *is* a major version: * Windows 3.1 : 3 * Windows 95/98, NT 4 : 4 * Windows XP, 2003 : 5 * Vista, Seven : 6 The major version is maybe less revelant for Windows. For Windows and Mac OS X, the minor version is relevant as well: Windows 7 has the version number 6.1. For Mac OS X, there are major changes happening for minor releases, e.g. see the architecture changes between 10.4, 10.5 and 10.6. Anyway... platform.major() will be needed if we remove the major version for all platforms from sys.platform (issue #12795). I just closed the issue #12795, and so I don't think that this issue is still needed and so I close it. Reopen it if you still see an use case. -- title: platform: add a major function to get the system major version - platform: add a major function to get the system major version ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12794 ___ ___ 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: We could change the title of the ticket :-) No please, move the discussion to #12795 which has a well defined title. This issue is closed. (#12795 has also a patch) Well, #12795 is also close but you can reopen it if you explain why :-) -- ___ 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
[issue12816] smtpd uses library outside of the standard libraries
New submission from Tennessee Leeuwenburg tleeuwenb...@gmail.com: Hi, I was writing some coverage tests, and started on a class called MailmanProxy inside of smtpd.py. It imports Mailman, which isn't in the standard library. I've attached a failing test to demonstrate the problem, but I didn't want to delete the section from smtpd.py as a beginner. Thanks, -Tennessee -- components: Library (Lib) files: MailmanProxy.diff keywords: patch messages: 142701 nosy: barry, ncoghlan, tleeuwenburg priority: normal severity: normal status: open title: smtpd uses library outside of the standard libraries Added file: http://bugs.python.org/file22995/MailmanProxy.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12816 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12796] total_ordering goes into infinite recursion when NotImplemented is returned
Nick Coghlan ncogh...@gmail.com added the comment: This is a dupe of #10042 -- resolution: - duplicate status: open - closed superseder: - total_ordering ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12796 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10042] total_ordering
Nick Coghlan ncogh...@gmail.com added the comment: Changed stage and resolution to reflect the fact that none of the existing patches adequately address the problem. -- resolution: fixed - stage: committed/rejected - needs patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10042 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12795] Remove the major version from sys.platform
Ezio Melotti ezio.melo...@gmail.com added the comment: Having the major version in sys.platform only for a few selected platforms doesn't seem too consistent for me. If linux 4 will introduce major changes, will we have to look for the major version of freebsd in sys.platform and for the linux major version elsewhere? That said, removing the major version for the other platforms might introduce unnecessary breakage, but if it's ever going to happen, I think it's better to do it now for all the platforms and not waiting for the experts to speak and change it in later versions, adding even more inconsistency. -- nosy: +ezio.melotti stage: - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12795 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12794] platform: add a major function to get the system major version
STINNER Victor victor.stin...@haypocalc.com added the comment: Le 20/08/2011 21:25, Marc-Andre Lemburg a écrit : I'm not sure I understand why platform.release() isn't sufficient for this purpose. You cannot write platform.release() = (2, 28) (Linux = 2.28) or platform.release() = 7 (FreeBSD 7 or later). You may use int(platform.release()[0]) but it will fail after the major version 10, and I'm not sure that release() always starts with a digit. What we could do is add a function that tries to find out the true version number of the OS, e.g. for Windows 7 that would be (6, 1, 7601) instead of the marketing name '7' returned by platform.release(). Yes, it would be more pratical than release() and it would be possible to compare it using a tuple, like sys.version_info. Still, this won't help with the OS version used for the Python build. I don't care of the OS version used to build. See my patch attached to #12795: only the version at runtime is important. The common use case is to check if the OS has a feature using its version, so the version at runtime. When Tarek was working on separating sysconfig from distutils, we briefly discussed parsing the Makefile and pyconfig.h files into a Python module. This is now an issue: #9878. But it doesn't help if I need the version at runtime. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12795] Remove the major version from sys.platform
Marc-Andre Lemburg m...@egenix.com added the comment: Moved the discussion here from issue12326: [Larry Hastings] If we're changing linux2 / linux3 to just linux, we should be consistent and do it for everybody. I propose sys.platform under 3.3 should contain things like linux, freebsd, openbsd, darwin, and windows. [Martin v. Löwis] Definitely not. The reasoning that applies to Linux doesn't necessarily apply to the other systems. My understanding that it definitely does not apply to HP-UX, where major version number changes really indicate major changes (unlike in Linux). Actually, with that reasoning we would need to reintroduce the version for Mac OS, and even go a step further and add the minor version number as well, since since major changes have happened on Mac OS with every single minor release for the last couple of years. IMO, a better approach is to split the information in two parts: * sys.platform, which only specifies the platform name on which Python was built (uname -s) * sys.platform_build_version, which provides the full platform version (uname -r; either as string or as tuple or both - that would have to be hashed out) It is obvious that the version number in sys.platform often doesn't really get used (see Victor's example). In such cases, having access to just the build platform name is better. In other cases, where you do need to know the version (e.g. on Mac OS X), you can then easily get if from the new attribute, and including the minor and even patch level release version details (e.g. to determine whether Python was compiled with a Windows specific service pack in place or not). -- nosy: +lemburg resolution: invalid - status: closed - open ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12795 ___ ___ 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: We could change the title of the ticket :-) No please, move the discussion to #12795 which has a well defined title. This issue is closed. (#12795 has also a patch) Well, #12795 is also close but you can reopen it if you explain why :-) Ok, I moved the discussion there. -- ___ 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
[issue12794] platform: add a function to get the system version as tuple
Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: What we could do is add a function that tries to find out the true version number of the OS, e.g. for Windows 7 that would be (6, 1, 7601) instead of the marketing name '7' returned by platform.release(). Yes, it would be more pratical than release() and it would be possible to compare it using a tuple, like sys.version_info. Ok, changed the title accordingly. Still, this won't help with the OS version used for the Python build. I don't care of the OS version used to build. See my patch attached to #12795: only the version at runtime is important. The common use case is to check if the OS has a feature using its version, so the version at runtime. Well, it is important to somehow get the build information for Python, since that tells us which OS features were available at the time of compilation. When Tarek was working on separating sysconfig from distutils, we briefly discussed parsing the Makefile and pyconfig.h files into a Python module. This is now an issue: #9878. But it doesn't help if I need the version at runtime. True, those two data points are different. -- title: platform: add a major function to get the system major version - platform: add a function to get the system version as tuple ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12795] Remove the major version from sys.platform
STINNER Victor victor.stin...@haypocalc.com added the comment: FreeBSD or OpenBSD release major version frequently, something like one per year, or one per two years. FreeBSD and OpenBSD developers knows that for years, and Python programs use sys.platform.startswith() for these OSes. For Linux, it's different. Linux 2.0 was released in 1997 and 3.0 in 2011: it took 14 years to change the major version. It don't think that any program working on Linux was prepared for this change: see #12326 history to have an idea on the problem. It looks like sys.platform=='linux3' breaks most programs testing sys.platform (including Python itself because of Lib/plat-linux2/ directory). If you want the OS name, use platform.system() or os.uname()[0]. If you want the OS version, use platform.release(). If you want the OS version as a tuple, hum... see the issue #12794. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12795 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12808] Coverage of codecs.py
Marc-Andre Lemburg m...@egenix.com added the comment: Nick Coghlan wrote: As a separate, but related point, IncrementalDecoder.getstate() includes an explanation on how to save arbitrary state as an integer, but no such explanation (not even a reference to the IncrementalDecoder version) is present in the IncrementalEncoder.getstate() docs. Adding MAL, since I'd like an expert opinion. Is the API less stringent than the docs state, or should BufferedIncrementalEncoder be fixed to always return the state as an integer? [1] http://docs.python.org/dev/library/codecs#codecs.IncrementalEncoder.getstate I'm not sure how that description got into the docs. It must have been added in the 3.x branch, since the 2.7 version of the docs doesn't document those method at all. FWIW: The .getstate() and .setstate() don't restrict the type of data used for storing the state. The only requirement is that the data returned by .getstate() can be passed to .setstate() in order to recreate the internal state used by the codec: def getstate(self): Return the current state of the encoder. return 0 def setstate(self, state): Set the current state of the encoder. state must have been returned by getstate(). For practical reasons, the used data should be pickleable. The interface is very similar to the __getstate__/__setstate__ interface used by pickle. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12808 ___ ___ 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 agree that's definitely out of scope of this issue. We could change the title of the ticket :-) Please keep the issue closed... The issue at hand was that Linux 3 is released, and broke several applications. This issue has been resolved. For the other platforms, I don't see any issue to be fixed (except for achieving foolish consistency). If something is *actually* broken, it needs to be 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
[issue12795] Remove the major version from sys.platform
Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: STINNER Victor victor.stin...@haypocalc.com added the comment: FreeBSD or OpenBSD release major version frequently, something like one per year, or one per two years. FreeBSD and OpenBSD developers knows that for years, and Python programs use sys.platform.startswith() for these OSes. For Linux, it's different. Linux 2.0 was released in 1997 and 3.0 in 2011: it took 14 years to change the major version. It don't think that any program working on Linux was prepared for this change: see #12326 history to have an idea on the problem. It looks like sys.platform=='linux3' breaks most programs testing sys.platform (including Python itself because of Lib/plat-linux2/ directory). If you want the OS name, use platform.system() or os.uname()[0]. If you want the OS version, use platform.release(). If you want the OS version as a tuple, hum... see the issue #12794. Victor, you are constantly mixing build time information with runtime information. Those are two different types of information and we should regard them as such. sys.platform refers to build time information, so the platform module won't help. The version of the build platform is important to know, but adding it to sys.platform is not necessarily the right thing to do, since adding just the major version is often not enough (see Mac OS X) and can sometimes lead to breakage due to frequent new releases of OSes (see FreeBSD). Given that the various OSes use different schemes for versioning and backwards compatibility, a single string cannot possibly cover all aspects. Separating the information into OS name and version is a much more future proof approach. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12795 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12794] platform: add a function to get the system version as tuple
Martin v. Löwis mar...@v.loewis.de added the comment: Well, it is important to somehow get the build information for Python, since that tells us which OS features were available at the time of compilation. No, it doesn't (except for a bug that Matthias Klose pointed out). The OS kernel version should have *zero* impact on the resulting Python binary. What matters it the C compiler and the version of the C library. The C library may or may not have features; features of the kernel used to build Python are completely irrelevant. (I think you misunderstood an earlier statement of me as self-contradicting. It was not: The kernel *headers* may have an impact during autoconf, not the running kernel. For Linux, the kernel headers are part of the C library, and typically bear no relationship with the running kernel - i.e. they may be either older or newer than the running kernel). Since there is no chance that we get the build environment captured in a reasonable way (in particular not the version of the C library, in a cross-platform manner), I strongly recommend to let this aspect rest. -- title: platform: add a function to get the system version as tuple - platform: add a function to get the system version as tuple ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12768] docstrings for the threading module
Eli Bendersky eli...@gmail.com added the comment: The usual procedure for committing to both 3.2 and 3.3 is to apply a patch to 3.2 and then merge it to 3.3 - could you check if the patch also works for 3.2 and if not, generate a patch for 3.2? I will do the merge when committing. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12768 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12794] platform: add a function to get the system version as tuple
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: Well, it is important to somehow get the build information for Python, since that tells us which OS features were available at the time of compilation. No, it doesn't (except for a bug that Matthias Klose pointed out). The OS kernel version should have *zero* impact on the resulting Python binary. What matters it the C compiler and the version of the C library. The C library may or may not have features; features of the kernel used to build Python are completely irrelevant. We are now discussing the general case, not limited to Linux. But even for Linux, the header information gets dumped into the plat-linuxN directory files, and those change over time as well. The kernel version also has an impact on certain features such as real time clocks, timers or other kernel subsystems, which autoconf then picks up at compile time. Of course, you can check whether those features are available one by one, but a version check is often a better way to see whether your application has a chance of running on the Python build in question. For other OSes, the build version is much more important due to the significant changes they make between releases, e.g. Mac OS X. (I think you misunderstood an earlier statement of me as self-contradicting. It was not: The kernel *headers* may have an impact during autoconf, not the running kernel. For Linux, the kernel headers are part of the C library, and typically bear no relationship with the running kernel - i.e. they may be either older or newer than the running kernel). I'm not talking about the runtime information. I'm talking about the compile time build information which is available via the Makefile and pyconfig.h file normally stored in the Python installation and which is used by distutils. The problem with those is that some distros choose to only include those files in -dev packages and parsing them via sysconfig just to get a quick look at the platform build version is really a bit too much processing. Since there is no chance that we get the build environment captured in a reasonable way (in particular not the version of the C library, in a cross-platform manner), I strongly recommend to let this aspect rest. We already do capture the build environment. This doesn't include the C library version, but we could add that as well, if needed, in a more direct way. The platform module provides a way to determine the lib C version required by the running Python binary on Linux (and perhaps other OSes as well), but it's slow. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12808] Coverage of codecs.py
Tennessee Leeuwenburg tleeuwenb...@gmail.com added the comment: Some more tests, updated initial state of BufferedIncrementalEncoder to be the correct type, updated rst file. Bit tired, hope I got it right! Thanks for the feedback everyone, helps me to get it done, even if it's more work for you... -- Added file: http://bugs.python.org/file22996/codecs.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12808 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12794] platform: add a function to get the system version as tuple
Martin v. Löwis mar...@v.loewis.de added the comment: No, it doesn't (except for a bug that Matthias Klose pointed out). The OS kernel version should have *zero* impact on the resulting Python binary. What matters it the C compiler and the version of the C library. The C library may or may not have features; features of the kernel used to build Python are completely irrelevant. We are now discussing the general case, not limited to Linux. And so was I. Read my statement as applying to the general case. But even for Linux, the header information gets dumped into the plat-linuxN directory files, Not in the build process, though... and those change over time as well. What exactly changes over time? The plat-linuxN directory files? Only if a developer updates them. For systems where the major version indicates feature changes, the plat-OSn directory should never change, since OS won't see any header changes until OSn+1 is released. The kernel version also has an impact on certain features such as real time clocks, timers or other kernel subsystems, which autoconf then picks up at compile time. Which operating system specifically are you referring to here? This should not happen. Of course, you can check whether those features are available one by one, but a version check is often a better way to see whether your application has a chance of running on the Python build in question. That's a fragile approach, though. If the feature presence varies with the OS kernel, you should rather check the version of the kernel you are running on - it may be that support was compiled in, but the system it runs on doesn't have that support. (I think you misunderstood an earlier statement of me as self-contradicting. It was not: The kernel *headers* may have an impact during autoconf, not the running kernel. For Linux, the kernel headers are part of the C library, and typically bear no relationship with the running kernel - i.e. they may be either older or newer than the running kernel). I'm not talking about the runtime information. I'm talking about the compile time build information which is available via the Makefile and pyconfig.h file normally stored in the Python installation and which is used by distutils. And so am I. running kernel above refers to the kernel running on the build system (i.e. what uname(1) gives you in autoconf, and what currently gets into sys.platform). We already do capture the build environment. This doesn't include the C library version, but we could add that as well, if needed, in a more direct way. No, we can't - that's impossible to implement in the general case. Some systems may use static linking, or use a fixed version number even as the library changes. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12794 ___ ___ 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: -- assignee: belopolsky - ezio.melotti ___ 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
[issue12817] test_multiprocessing: io.BytesIO() requires bytearray buffers
New submission from Stefan Krah stefan-use...@bytereef.org:
Hello,
in my private repo I've changed memoryview's getbufferproc to be PEP-3118
compliant. test_multiprocessing does the equivalent of the following sequence,
which is not allowed by PEP-3118:
import array, io
a = array.array('i', [1,2,3,4,5])
m = memoryview(a)
m.format
'i'
buf = io.BytesIO(bytearray(5))
buf.readinto(m)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: expected an object with a writable buffer interface
The error occurs in Objects/abstract.c:315:
((*pb-bf_getbuffer)(obj, view, PyBUF_WRITABLE) != 0))
Here, PyObject_AsWriteBuffer() requests a simple writable buffer of unsigned
bytes *without format information* from the memoryview. The memoryview's
getbufferproc is required to return an error:
If format is not explicitly requested then the format must be returned
as NULL (which means B, or unsigned bytes).
But the underlying buffer has format 'i' and not 'B', hence the error.
Antoine, is it correct that io.BytesIO should only be used with bytearray
buffers?
If so, this is a bug in the tests (patch attached).
--
components: Tests
files: test_multiprocessing_use_bytearray.diff
keywords: needs review, patch
messages: 142718
nosy: ncoghlan, pitrou, skrah
priority: normal
severity: normal
stage: patch review
status: open
title: test_multiprocessing: io.BytesIO() requires bytearray buffers
type: behavior
versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3
Added file:
http://bugs.python.org/file22997/test_multiprocessing_use_bytearray.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12817
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11682] PEP 380 reference implementation for 3.3
Changes by Ryan Kelly r...@rfk.id.au: -- nosy: +rfk ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11682 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis
Changes by Ryan Kelly r...@rfk.id.au: -- nosy: +rfk ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue11816 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12794] platform: add a function to get the system version as tuple
Marc-Andre Lemburg m...@egenix.com added the comment: [This discussion is really off-topic for this issue, it should either be moved to issue12795 or a new ticket] Martin v. Löwis wrote: Martin v. Löwis mar...@v.loewis.de added the comment: No, it doesn't (except for a bug that Matthias Klose pointed out). The OS kernel version should have *zero* impact on the resulting Python binary. What matters it the C compiler and the version of the C library. The C library may or may not have features; features of the kernel used to build Python are completely irrelevant. We are now discussing the general case, not limited to Linux. And so was I. Read my statement as applying to the general case. But even for Linux, the header information gets dumped into the plat-linuxN directory files, Not in the build process, though... and those change over time as well. What exactly changes over time? The plat-linuxN directory files? Only if a developer updates them. For systems where the major version indicates feature changes, the plat-OSn directory should never change, since OS won't see any header changes until OSn+1 is released. I meant that the OS platform directories change over time, i.e. new plat-osversion directories get created to hold the updated OS information. Since Python was build on a specific OS version, it will only see the APIs available on that OS version. The OS build version provides a quick way to check whether a certain set of feature is available or not. The kernel version also has an impact on certain features such as real time clocks, timers or other kernel subsystems, which autoconf then picks up at compile time. Which operating system specifically are you referring to here? This should not happen. This is meant to happen. The whole purpose of autoconf/configure is to try to figure out which features are available on a platform and those features change with the OS version. See e.g. these documents on the incremental Linux kernel changes between 2.2 and 3.0: http://www.kniggit.net/wwol22.html http://www.kniggit.net/wwol24.html http://www.kniggit.net/wwol26.html http://jpranevich.tripod.com/wwol30/wonderful-world-of-linux-3.0.html Here's a similar list for FreeBSD: http://ivoras.net/freebsd/freebsd9.html http://ivoras.net/freebsd/freebsd8.html http://ivoras.net/freebsd/freebsd7.html On Mac OS X the situations is a little different: older Python binaries simply won't run on newer OS versions at all due to the architecture changes, so there's nothing much to check. Of course, you can check whether those features are available one by one, but a version check is often a better way to see whether your application has a chance of running on the Python build in question. That's a fragile approach, though. If the feature presence varies with the OS kernel, you should rather check the version of the kernel you are running on - it may be that support was compiled in, but the system it runs on doesn't have that support. True, the feature may still not work in the runtime OS environment, but at least the Python binary knows about the feature set you're interested in, so you can actively check whether it works or not, since the APIs will be available. (I think you misunderstood an earlier statement of me as self-contradicting. It was not: The kernel *headers* may have an impact during autoconf, not the running kernel. For Linux, the kernel headers are part of the C library, and typically bear no relationship with the running kernel - i.e. they may be either older or newer than the running kernel). I'm not talking about the runtime information. I'm talking about the compile time build information which is available via the Makefile and pyconfig.h file normally stored in the Python installation and which is used by distutils. And so am I. running kernel above refers to the kernel running on the build system (i.e. what uname(1) gives you in autoconf, and what currently gets into sys.platform). Please don't mix up the build time environment with the runtime environment. Using running kernel to refer to the build time kernel is a rather confusing way of naming things when discussing build time vs. runtime. We already do capture the build environment. This doesn't include the C library version, but we could add that as well, if needed, in a more direct way. No, we can't - that's impossible to implement in the general case. Some systems may use static linking, or use a fixed version number even as the library changes. The platform API libc_ver() actually checks the linker references in the binary and also allows using a different binary for the check in case the Python binary is not a suitable candidate. It is mainly meant to identify the minimum lib C requirement for a binary. Adding the lib C version constants would make this information more directly accessible: __GLIBC__ and __GLIBC_MINOR__ for glibc. Regardless, the
[issue9200] Make the str.is* methods work with non-BMP chars on narrow builds
Ezio Melotti ezio.melo...@gmail.com added the comment: It turned out that this can't be fixed in 2.7 unless we backport the patch in #5127 (it's in 3.2/3.3 but not in 2.7). IIUC the macro works fine and joins surrogate pairs to a Py_UCS4 char, but since the Py_UNICODE_IS* macros still expect Py_UCS2 on narrow builds on 2.7, the higher bits gets truncated and the macros return wrong results. So, for example u'\ud800\udc42'.isupper() True because \ud800 + \udc42 = \U000100429 → \U000100429 gets truncated to \u0429 → \u0429 is the CYRILLIC CAPITAL LETTER SHCHA → .isupper() returns True. The current behavior is instead broken in another way, because it checks that u'\ud800'.isupper() and u'\udc42'.isupper() separately. Would it make sense to backport #5127 or should I just give up and leave it broken? -- title: Make str methods work with non-BMP chars on narrow builds - Make the str.is* methods work with non-BMP chars on narrow builds ___ 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
[issue12816] smtpd uses library outside of the standard libraries
R. David Murray rdmur...@bitdance.com added the comment: That was a correct decision :) It certainly shouldn't be simply deleted, since that would break backward compatibility. Barry, is this something we (ie: you, in this case :) wish to continue to maintain? If not, we have the options of deprecation-and-removal, or deprecation-in-place (in the latter case we just stick a comment in the file...) -- nosy: +r.david.murray ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12816 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12808] Coverage of codecs.py
Marc-Andre Lemburg m...@egenix.com added the comment: Tennessee Leeuwenburg wrote: Tennessee Leeuwenburg tleeuwenb...@gmail.com added the comment: Some more tests, updated initial state of BufferedIncrementalEncoder to be the correct type, updated rst file. Bit tired, hope I got it right! Thanks for the feedback everyone, helps me to get it done, even if it's more work for you... I think you should simply drop this whole part: The implementation should make sure that ``0`` is the most common state. (States that are more complicated than integers can be converted into an integer by marshaling/pickling the state and encoding the bytes of the resulting string into an integer). or, better, rephrase it so that it becomes clear that the codec implementation may use any type of pickleable object to represent the internal state. The only requirement is that .setstate() has to be able to read back the state returned by .getstate(). We have codecs in the stdlib that return integers, bytes/string and even tuples (see the io module and the UTF-16 codec as example), so the documentation is clearly wrong. Thanks, -- Marc-Andre Lemburg eGenix.com 2011-10-04: PyCon DE 2011, Leipzig, Germany43 days to go ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12808 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12795] Remove the major version from sys.platform
STINNER Victor victor.stin...@haypocalc.com added the comment: sys.platform refers to build time information, so the platform module won't help. When I wrote my patch, I realized that sys.platform is used to get the runtime information, which is wrong. See the tests in Lib/test/test_*.py: they use sys.platform to check features of the running OS (kernel). It is mostly to test FreeBSD major version, and it looks like Python is build on the same FreeBSD major version that it is running on. Maybe because on FreeBSD, most programs are compiled instead of using prebuild packages (pkgadd). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12795 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12794] platform: add a function to get the system version as tuple
STINNER Victor victor.stin...@haypocalc.com added the comment: The whole purpose of autoconf/configure is to try to figure out which features are available on a platform and those features change with the OS version. Hum, not exactly. autoconf checks if a function exists or if a constant exists in the C headers and in the C library. You have to check it or your program (C file) will not compile (missing function/constant). But it's not enough. The GNU libc provides functions which are only available on some recent Linux kernels. Depending on the running kernel, the function may fail with something like not implemented error. See for example the discussion about accept4(): http://bugs.python.org/issue10115 At Python level, you need to know the running kernel version to check if accept4() if available or not. Knowing if the kernel used to compile Python has accept4() or not doesn't help. (If you use the compiled Python on an older libc (e.g. on another computer), you have another problem, but it's the problem of OS vendors, not of Python.) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12818] email.utils.formataddr incorrectly quotes parens inside quoted strings
New submission from R. David Murray rdmur...@bitdance.com: The attached test case fails. -- assignee: r.david.murray files: formataddr_paren_test.patch keywords: easy, patch messages: 142725 nosy: r.david.murray priority: normal severity: normal status: open title: email.utils.formataddr incorrectly quotes parens inside quoted strings versions: Python 2.7, Python 3.2, Python 3.3 Added file: http://bugs.python.org/file22998/formataddr_paren_test.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12818 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9253] argparse: optional subparsers
Changes by Zsolt Cserna zsolt.cse...@morganstanley.com: -- nosy: +csernazs ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9253 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12794] platform: add a function to get the system version as tuple
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com: -- title: platform: add a function to get the system version as tuple - platform: add a function to get the system version as tuple ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12794 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12795] Remove the major version from sys.platform
Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: STINNER Victor victor.stin...@haypocalc.com added the comment: sys.platform refers to build time information, so the platform module won't help. When I wrote my patch, I realized that sys.platform is used to get the runtime information, which is wrong. See the tests in Lib/test/test_*.py: they use sys.platform to check features of the running OS (kernel). It is mostly to test FreeBSD major version, and it looks like Python is build on the same FreeBSD major version that it is running on. Maybe because on FreeBSD, most programs are compiled instead of using prebuild packages (pkgadd). Right. FreeBSD doesn't ship prebuilt binaries for packages - it uses a very elegant ports collection, where everything gets compiled on the target machine: http://www.freebsd.org/ports/ So you don't really run into the issue of using a older Python build on the system, unless you have an application which ships Python along with the application package. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12795 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12817] test_multiprocessing: io.BytesIO() requires bytearray buffers
Stefan Krah stefan-use...@bytereef.org added the comment:
Of course, there is another interpretation:
[PyBUF_FORMAT]
The returned buffer must have true format information if this flag is
provided. This would be used when the consumer is going to be checking for what
'kind' of data is actually stored. An exporter should always be able to provide
this information if requested. If format is not explicitly requested then the
format must be returned as NULL (which means B, or unsigned bytes)
So, the returned buffer may have false format information ('B' vs. 'i'
in this case) if this flag is not provided.
Do you agree with this? I'll then make it explicit in the documentation.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12817
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12818] email.utils.formataddr incorrectly quotes parens inside quoted strings
R. David Murray rdmur...@bitdance.com added the comment: Hmm. The output of formataddr is not actually incorrect, it just overquotes compared to what is required by the RFC. Attached is a fix, but since this isn't technically an RFC bug, I'm removing 3.2 and 2.7 from versions. -- keywords: -easy stage: - patch review type: - behavior versions: -Python 2.7, Python 3.2 Added file: http://bugs.python.org/file22999/formataddr_paren_quote.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12818 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12816] smtpd uses library outside of the standard libraries
Barry A. Warsaw ba...@python.org added the comment: I think it should be deprecated and eventually removed. I don't remember why I put it in this file, and besides Mailman 3 won't use it. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12816 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12795] Remove the major version from sys.platform
STINNER Victor victor.stin...@haypocalc.com added the comment: It is mostly to test FreeBSD major version, and it looks like Python is build on the same FreeBSD major version that it is running on. Maybe because on FreeBSD, most programs are compiled instead of using prebuild packages (pkgadd). Right. FreeBSD doesn't ship prebuilt binaries for packages FreeBSD does ship prebuild Python packages. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12795 ___ ___ 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: The attached patch adds the following 4 public macros to unicodeobjects.h: Py_UNICODE_IS_SURROGATE(ch) Py_UNICODE_IS_HIGH_SURROGATE(ch) Py_UNICODE_IS_LOW_SURROGATE(ch) Py_UNICODE_JOIN_SURROGATES(high, low) and documents them. Since _Py_UNICODE_NEXT is still private, I'll commit it later as part as #9200. -- Added file: http://bugs.python.org/file23000/issue10542b.diff ___ 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
[issue10542] Py_UNICODE_NEXT and other macros for surrogates
Marc-Andre Lemburg m...@egenix.com added the comment: Ezio Melotti wrote: Ezio Melotti ezio.melo...@gmail.com added the comment: The attached patch adds the following 4 public macros to unicodeobjects.h: Py_UNICODE_IS_SURROGATE(ch) Py_UNICODE_IS_HIGH_SURROGATE(ch) Py_UNICODE_IS_LOW_SURROGATE(ch) Py_UNICODE_JOIN_SURROGATES(high, low) and documents them. Since _Py_UNICODE_NEXT is still private, I'll commit it later as part as #9200. Looks good. -- ___ 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
[issue12713] argparse: allow abbreviation of sub commands by users
Christian Ziemski cz...@gmx.de added the comment: After some interesting hours of work (learning about tests) I created a new patch, including my original code changes as in the former patch and the new additional tests as well. -- Added file: http://bugs.python.org/file23001/abbrev_subcmds_plus_tests_3.3.patch ___ 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
[issue9993] shutil.move fails on symlink source
Jonathan Niehof jnie...@lanl.gov added the comment: Éric, here's a quick docs-only patch against current default...does this do the job? -- Added file: http://bugs.python.org/file23002/shutil_move_doc.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9993 ___ ___ 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
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 77171f993bf2 by Ezio Melotti in branch 'default': #10542: Add 4 macros to work with surrogates: Py_UNICODE_IS_SURROGATE, Py_UNICODE_IS_HIGH_SURROGATE, Py_UNICODE_IS_LOW_SURROGATE, Py_UNICODE_JOIN_SURROGATES. http://hg.python.org/cpython/rev/77171f993bf2 -- nosy: +python-dev ___ 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 the str.is* methods work with non-BMP chars on narrow builds
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 06b30c5bcc3d by Ezio Melotti in branch '3.2': #9200: The str.is* methods now work with strings that contain non-BMP characters even in narrow Unicode builds. http://hg.python.org/cpython/rev/06b30c5bcc3d New changeset e3be2941c834 by Ezio Melotti in branch 'default': #9200: merge with 3.2. http://hg.python.org/cpython/rev/e3be2941c834 -- nosy: +python-dev ___ 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
[issue12795] Remove the major version from sys.platform
Marc-Andre Lemburg m...@egenix.com added the comment: STINNER Victor wrote: STINNER Victor victor.stin...@haypocalc.com added the comment: It is mostly to test FreeBSD major version, and it looks like Python is build on the same FreeBSD major version that it is running on. Maybe because on FreeBSD, most programs are compiled instead of using prebuild packages (pkgadd). Right. FreeBSD doesn't ship prebuilt binaries for packages FreeBSD does ship prebuild Python packages. The FreeBSD base distribution (which has the binaries and, AFAIK, the only binaries that ship with FreeBSD) doesn't include Python. It's in the ports collection, though, and for those you have the option of installing prebuilt binaries of the packages via pkg_add. Still, that's not exactly the FreeBSD way of doing things :) See the big warning in the pkg_add man page, various discussions on the net and the pros/cons in the handbook: http://www.freebsd.org/doc/handbook/ports-overview.html But in general you are right: if you use system provided Python packages, chances are that your runtime OS version will be identical or very close to the build time OS version. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12795 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12795] Remove the major version from sys.platform
STINNER Victor victor.stin...@haypocalc.com added the comment: But in general you are right: if you use system provided Python packages, chances are that your runtime OS version will be identical or very close to the build time OS version. I asked on #freebsd-fr: even with pkg_add, the installed Python is compiled on the same major version than the running major version. So the problem is hidden (it doesn't affect) on FreeBSD. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12795 ___ ___ 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
Brett Cannon br...@python.org added the comment: +1 -- Added file: http://bugs.python.org/file23005/unnamed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12409 ___+1br ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12819] PEP 393 - Flexible Unicode String Representation
New submission from Torsten Becker torsten.bec...@gmail.com: I have started an implementation of PEP 393 -- Flexible String Representation [1] on bitbucket [2]. Not all code is ported to use the new API yet, but the interpreter starts with the new unicode representation, all unit tests pass, and some micro benchmarks show potential. Please see the related wiki page [3] for details of my implementation. [1]: http://www.python.org/dev/peps/pep-0393/ [2]: https://bitbucket.org/t0rsten/pep-393 [2]: http://wiki.python.org/moin/SummerOfCode/2011/PEP393 -- components: Unicode files: pep-393-aug22.diff keywords: patch messages: 142741 nosy: torsten.becker priority: normal severity: normal status: open title: PEP 393 - Flexible Unicode String Representation type: feature request versions: Python 3.3 Added file: http://bugs.python.org/file23004/pep-393-aug22.diff ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12819] PEP 393 - Flexible Unicode String Representation
Changes by Ezio Melotti ezio.melo...@gmail.com: -- nosy: +ezio.melotti, haypo, lemburg, loewis stage: - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)
Remi Pointel pyt...@xiri.fr added the comment: Hi, what information do you need to advance on this bug? Cheers, Remi. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12589 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12819] PEP 393 - Flexible Unicode String Representation
Changes by STINNER Victor victor.stin...@haypocalc.com: -- hgrepos: +62 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12819 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9200] Make the str.is* methods work with non-BMP chars on narrow builds
Amaury Forgeot d'Arc amaur...@gmail.com added the comment: This issue and #5127 should not be backported to 2.7: narrow builds don't even accept unichar(0x1). Only python 3 can slowly pretend to implement utf-16 features. -- ___ 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 the str.is* methods work with non-BMP chars on narrow builds
STINNER Victor victor.stin...@haypocalc.com added the comment: This issue and #5127 should not be backported to 2.7: narrow builds don't even accept unichar(0x1). I agee. -- ___ 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 the str.is* methods work with non-BMP chars on narrow builds
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 75a4941d4d61 by Ezio Melotti in branch '2.7': #9200: backport tests but run them on wide builds only. http://hg.python.org/cpython/rev/75a4941d4d61 -- ___ 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 the str.is* methods work with non-BMP chars on narrow builds
Ezio Melotti ezio.melo...@gmail.com added the comment: Backporting #5127 is not possible anyway, because it would be necessary to recompile. I backported only the tests, skipping them on wide builds. -- dependencies: -Py_UNICODE_NEXT and other macros for surrogates resolution: - fixed stage: commit review - committed/rejected status: open - closed versions: -Python 2.7 ___ 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 the str.is* methods work with non-BMP chars on narrow builds
Ezio Melotti ezio.melo...@gmail.com added the comment: s/skipping them on wide builds/skipping them on narrow builds/ On wide builds they work fine, on narrow builds they don't work and they can't be fixed. -- ___ 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
[issue12729] Python lib re cannot handle Unicode properly due to narrow/wide bug
Terry J. Reedy tjre...@udel.edu added the comment: I improved UTF16.__getitem__ to handle negative indexes and slices. The later uses the same adjustment as for indexes. An __iter__ method is not needed as str.__iter__ used __getitem__. I will take further discussion of this prototype to python-ideas list. -- Added file: http://bugs.python.org/file23006/utf16.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12729 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12729] Python lib re cannot handle Unicode properly due to narrow/wide bug
Changes by Terry J. Reedy tjre...@udel.edu: Removed file: http://bugs.python.org/file22900/utf16.py ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12729 ___ ___ 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
Julian Berman julian+python@grayvines.com added the comment: we explicitly advise against importing too many modules in a single import statement, but importing multiple names from a single location is often a useful thing to do. Cool. I imagined this had to do with it. there may be a grammar ambiguity problem in this case, since (unlike from-import) with statements allow arbitrary subexpressions. Sorry, can you possibly clarify where the ambiguity might come in? -- ___ 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
[issue12729] Python lib re cannot handle Unicode properly due to narrow/wide bug
Changes by STINNER Victor victor.stin...@haypocalc.com: -- nosy: +haypo ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12729 ___ ___ 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)
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset d1fd0f0f8e68 by Sandro Tosi in branch 'default': #12191: add shutil.chown() to change user and/or group owner of a given path also specifying their names. http://hg.python.org/cpython/rev/d1fd0f0f8e68 -- nosy: +python-dev ___ 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
[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: At last, it's in :) thanks a lot to all the people that helped me in the process! -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ 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
[issue12191] Add shutil.chown to allow to use user and group name (and not only uid/gid)
STINNER Victor victor.stin...@haypocalc.com added the comment: New changeset d1fd0f0f8e68 by Sandro Tosi in branch 'default' You may add shutil.chmod to the What's New in Python 3.3? document. -- ___ 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
[issue10730] add .svgz to mimetypes.suffix_map and .svg to types_map
Changes by Éric Araujo mer...@netwok.org: -- resolution: accepted - fixed stage: commit review - committed/rejected ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue10730 ___ ___ 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)
Ezio Melotti ezio.melo...@gmail.com added the comment: Raymond, are you still taking care of the whatsnew? Do you want people to update it when they add something new? -- nosy: +rhettinger ___ 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
[issue12409] Moving Documenting Python to Devguide
Changes by Sandro Tosi sandro.t...@gmail.com: Removed file: http://bugs.python.org/file23005/unnamed ___ 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
[issue12817] test_multiprocessing: io.BytesIO() requires bytearray buffers
Antoine Pitrou pit...@free.fr added the comment: Antoine, is it correct that io.BytesIO should only be used with bytearray buffers? BytesIO does a copy of the original object, it does not touch the original buffer. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12817 ___ ___ 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? When I do that, it pushes the memory usage for the test up to 16GB, which is beyond what the machine can handle. When I tried with 2.5G (_2G * 5 // 4), that was enough to make it swap heavily (and in the end the test still failed). As an aside, it turns out the problem with -M being ignored wasn't due to me being stupid; it seems that -j doesn't pass the memlimit on to subprocesses. I'll open a separate issue for this. -- ___ 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
[issue12191] Add shutil.chown to allow to use user and group name (and not only uid/gid)
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset 5d317e38da44 by Sandro Tosi in branch 'default': #12191: fix build failures, explicitly passing group argument when I want to test it http://hg.python.org/cpython/rev/5d317e38da44 -- ___ 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
[issue12792] Document the type field of the tracker in the devguide
Ezio Melotti ezio.melo...@gmail.com added the comment: Fixed in aa627513fb23. I also moved the 'behavior' at the beginning of the list. -- resolution: - fixed stage: patch review - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue12792 ___ ___ 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: Can you replace _2G with _4G in the decorator for that test? When I do that, it pushes the memory usage for the test up to 16GB, which is beyond what the machine can handle. When I tried with 2.5G (_2G * 5 // 4), that was enough to make it swap heavily (and in the end the test still failed). Uh, does it? With 4G it should raise OverflowError, and not try to do anything else. Could I ask you to try to take a look? :S As an aside, it turns out the problem with -M being ignored wasn't due to me being stupid; it seems that -j doesn't pass the memlimit on to subprocesses. I'll open a separate issue for this. Running bigmem tests in parallel doesn't make much sense IMO. You want to run as many of them as you can, which requires that you allocate all memory to *one* test process. -- ___ 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
Nadeem Vawda nadeem.va...@gmail.com added the comment: Uh, does it? With 4G it should raise OverflowError, and not try to do anything else. Could I ask you to try to take a look? :S Sure; I'll see what I can figure out tomorrow. Running bigmem tests in parallel doesn't make much sense IMO. You want to run as many of them as you can, which requires that you allocate all memory to *one* test process. Yeah, actually running them in parallel isn't a sensible use. But it bit me because I was just using make test EXTRATESTOPTS='-uall -M11G test_pickle'. It would be nice to have a warning so other people don't get confused by the same problem. I guess that shouldn't be too hard to arrange. -- ___ 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
[issue12409] Moving Documenting Python to Devguide
Sandro Tosi sandro.t...@gmail.com added the comment: @Fred: thanks about it :) @Éric: I just want to have clear in mind what you mean; my original proposal was to move completely, the whole section Documenting python to devguide since it contains building instructions and how's the markup works for python. Is your proposal different and so, as I can read, to just move the building part to devguide and the rest of it be left in python documentation with links to sphinx upstream documentation? But one aspect I think it needs to be done as a prerequisite to this migration is: standardizing the sphinx/tools versions used to build the doc. devguide is version-agnostic, so we can talk about (without convoluted sentences) only about one way to build the doc. This was raised several times, even recently, on python-dev so I'm going to resurrect that thread so we can discuss there the pros/cons and then see from the outcome how we can move forward. -- stage: - needs patch ___ 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'
Georg Brandl ge...@python.org added the comment: I don't know how to update this documentation. Can someone update the doc, or suggest a patch? This is a strange statement. You changed the implementation, so you should be able to change the documentation accordingly. -- ___ 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
[issue11715] Building Python on multiarch Debian and Ubuntu
Barry A. Warsaw ba...@python.org added the comment: On Aug 18, 2011, at 07:09 AM, Nick Coghlan wrote: 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. Hi Nick. Would this be Kubuntu 11.04 or some other release? -- ___ 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
[issue12191] Add shutil.chown to allow to use user and group name (and not only uid/gid)
Éric Araujo mer...@netwok.org added the comment: Ezio: I think that Raymond is in charge of the 3.3 whatsnew too. The rules in a comment at the top of the file still apply: there are already around 30 notes to the file. -- ___ 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
[issue9993] shutil.move fails on symlink source
Éric Araujo mer...@netwok.org added the comment: Thanks for the doc patch, which looks good. I have one question: if a relative symlink is copied, should the resulting symlink be relative too? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9993 ___ ___ 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:
Something like:
diff --git a/Doc/library/sys.rst b/Doc/library/sys.rst
--- a/Doc/library/sys.rst
+++ b/Doc/library/sys.rst
@@ -699,20 +699,21 @@ always available.
This string contains a platform identifier that can be used to append
platform-specific components to :data:`sys.path`, for instance.
- For Unix systems, this is the lowercased OS name as returned by ``uname -s``
- with the first part of the version as returned by ``uname -r`` appended,
- e.g. ``'sunos5'`` or ``'linux2'``, *at the time when Python was built*.
- Unless you want to test for a specific system version, it is therefore
- recommended to use the following idiom::
+ For Unix systems, except on Linux, this is the lowercased OS name as
+ returned by ``uname -s`` with the first part of the version as returned by
+ ``uname -r`` appended, e.g. ``'sunos5'`` or ``'linux2'``, *at the time when
+ Python was built*. Unless you want to test for a specific system version,
+ it is therefore recommended to use the following idiom::
- if sys.platform.startswith('linux'):
- # Linux-specific code here...
+ if sys.platform.startswith('freebsd'):
+ # Freebsd-specific code here...
For other systems, the values are:
===
System :data:`platform` value
===
+ Linux``'linux2'``
Windows ``'win32'``
Windows/Cygwin ``'cygwin'``
Mac OS X ``'darwin'``
?
I don't think that I need a :versionchanged:`2.7.3`.
--
___
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
[issue6484] No unit test for mailcap module
Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset a1bb07d67a24 by Ezio Melotti in branch 'default': #6484: refactor a bit the tests. http://hg.python.org/cpython/rev/a1bb07d67a24 -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6484 ___ ___ 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
Éric Araujo mer...@netwok.org added the comment: Reviewed. Steven: the patch is complete, pending a few doc editions. -- ___ 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
