[issue12821] test_fcntl failed on OpenBSD 5.x

New submission from Remi Pointel : Hello, test_fcntl failed on OpenBSD 5.0. It's ok when we add openbsd5 in the tuple of sys.platform (patch attached). Thanks a lot, Remi. -- files: patch-Lib_test_test_fcntl_py messages: 142784 nosy: rpointel priority: normal severity: normal status:

[issue12678] test_packaging and test_distutils failures under Windows

Éric Araujo added the comment: I’m in CEST too (France), but I’m not sure I’ll have Internet access this evening. Would tomorrow afternoon work for you? I don’t want you to have to dive in distutils more than you should :) -- ___ Python tracker

[issue12678] test_packaging and test_distutils failures under Windows

Nadeem Vawda added the comment: > I’ll commit the tmp-debug patch so that we can get info from the buildbot, > unless Jeremy or someone can investigate. If you can wait until this evening (CEST), I'll run the tests with that patch applied locally. It might be easier to get to the bottom of this

[issue12785] list_distinfo_file is wrong

Nadeem Vawda added the comment: > These are unrelated, I’m only interested in test_database for this patch. I see. I'll re-run the tests this evening, and see whether that failure crops up. -- ___ Python tracker

[issue6560] socket sendmsg(), recvmsg() methods

Nick Coghlan added the comment: Attached patch (ssl_fixes_v1) makes the presence of the sendmsg/recvmsg methods in the ssl module conditional on their being present in the underlying socket module. However, in doing this, I noticed that these methods will, at best, work during the time betwe

[issue12820] Tests for Lib/xml/dom/minicompat.py

New submission from John Chandler : The Lib/xml/dom/minicompat.py module doesn't appear to have any test coverage, probably because it's not the largest or most exciting of modules! :-) I therefore attach a patch to add test coverage for the EmptyNodeList and NodeList classes. I can add tests

[issue6560] socket sendmsg(), recvmsg() methods

Nick Coghlan added the comment: Reopening to track buildbot failures (at least on Windows) - at a glance, it looks like the SSL socket wrapper is still adding (and trying to test) the send/receivemsg methods even when they're missing from the socket object on the current platform. --

[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis

Changes by Nick Coghlan : -- assignee: rhettinger -> ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue12678] test_packaging and test_distutils failures under Windows

Changes by Antoine Pitrou : -- nosy: -pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pytho

[issue9893] Removing the Misc/Vim/ files

Changes by Antoine Pitrou : -- nosy: -pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python

[issue8668] Packaging: add a 'develop' command

Changes by Éric Araujo : Added file: http://bugs.python.org/file23009/5359c895f841.diff ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue12394] packaging: generate scripts from callable (dotted paths)

Changes by Éric Araujo : Added file: http://bugs.python.org/file23008/7099110c8f14.diff ___ Python tracker ___ ___ Python-bugs-list mailing li

[issue12409] Moving "Documenting Python" to Devguide

Éric Araujo added the comment: My comment was ambiguous, let me rephrase it: I am in favor of moving cpython/Doc/documenting to the devguide. Then, in the devguide, I would like to remove all the doc that’s just duplicating the upstream Sphinx docs, keeping only links and Python-specific par

[issue12721] Chaotic use of helper functions in test_shutil for reading and writing files

Éric Araujo added the comment: > While writing my tests I realized, it would be really useful to make > write_file() return the path it wrote to. Sure, please open another 3.3 report for this. -- ___ Python tracker

[issue12785] list_distinfo_file is wrong

Éric Araujo added the comment: Ahem, I read your message too fast. > With the patch applied, I still get failures in test_old_record_extensions > and test_record_basic, so it doesn't seem to work. These are unrelated, I’m only interested in test_database for this patch. -- ___

[issue12808] Coverage of codecs.py

Tennessee Leeuwenburg added the comment: Thanks for the review. Here is a patch incorporating the two comments being to move some comments. -- Added file: http://bugs.python.org/file23007/codecs.diff ___ Python tracker

[issue12785] list_distinfo_file is wrong

Éric Araujo added the comment: Thanks. Can you test again after removing these two lines: # XXX see first if we need to convert at all prefix = self.path -- ___ Python tracker ___

[issue12678] test_packaging and test_distutils failures under Windows

Éric Araujo added the comment: >> Looks like the patch is not enough: > That's a 3.2 builder. You only committed Jeremy's fix to default. *puts on the stupid hat* > I also tried backporting Jeremy's fix to 2.7, but that doesn't seem to > have worked; the sdist tests is still failing there. I’ll

[issue9893] Removing the Misc/Vim/ files

Changes by Éric Araujo : -- components: +None -Demos and Tools title: Usefulness of the Misc/Vim/ files? -> Removing the Misc/Vim/ files versions: +Python 3.3 -Python 3.2 ___ Python tracker _

[issue9893] Usefulness of the Misc/Vim/ files?

Éric Araujo added the comment: > To download the current release of python.vim, which is an enhanced > version of the python syntax highlighting script that conforms with > PEP 8, and is actively maintained by the Vim community. s/python/Python/ I think the bit about “enhanced version” could be

[issue12191] Add shutil.chown to allow to use user and group name (and not only uid/gid)

Roundup Robot added the comment: New changeset f2cb733c9a37 by Sandro Tosi in branch 'default': #12191: added entry in What's New (+ small editing on shutil section) http://hg.python.org/cpython/rev/f2cb733c9a37 -- ___ Python tracker

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

Ezio Melotti added the comment: I think the doc patch should mention that: 1) it's 'linux2' also on Linux 3; 2) why it's not 'linux3'; The why can be done in a footnote and explain that Linux 3 doesn't introduce new major features and that changing the string to 'linux3' would have just brok

[issue12713] argparse: allow abbreviation of sub commands by users

Éric Araujo added the comment: Reviewed. Steven: the patch is complete, pending a few doc editions. -- ___ Python tracker ___ ___ Py

[issue6484] No unit test for mailcap module

Roundup Robot 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

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

STINNER Victor 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 co

[issue9993] shutil.move fails on symlink source

Éric Araujo 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 ___

[issue12191] Add shutil.chown to allow to use user and group name (and not only uid/gid)

Éric Araujo 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

[issue11715] Building Python on multiarch Debian and Ubuntu

Barry A. Warsaw 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. Wo

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

Georg Brandl 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. -- _

[issue12409] Moving "Documenting Python" to Devguide

Sandro Tosi 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 y

[issue11564] pickle not 64-bit ready

Nadeem Vawda 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

[issue11564] pickle not 64-bit ready

Antoine Pitrou 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

[issue12792] Document the "type" field of the tracker in the devguide

Ezio Melotti 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

[issue12191] Add shutil.chown to allow to use user and group name (and not only uid/gid)

Roundup Robot 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

[issue11564] pickle not 64-bit ready

Nadeem Vawda 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

[issue12817] test_multiprocessing: io.BytesIO() requires bytearray buffers

Antoine Pitrou 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

[issue12409] Moving "Documenting Python" to Devguide

Changes by Sandro Tosi : Removed file: http://bugs.python.org/file23005/unnamed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue12191] Add shutil.chown to allow to use user and group name (and not only uid/gid)

Ezio Melotti 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

[issue10730] add .svgz to mimetypes.suffix_map and .svg to types_map

Changes by Éric Araujo : -- resolution: accepted -> fixed stage: commit review -> committed/rejected ___ Python tracker ___ ___ Python

[issue12191] Add shutil.chown to allow to use user and group name (and not only uid/gid)

STINNER Victor 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 __

[issue12191] Add shutil.chown to allow to use user and group name (and not only uid/gid)

Sandro Tosi 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

[issue12191] Add shutil.chown to allow to use user and group name (and not only uid/gid)

Roundup Robot 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

[issue12729] Python lib re cannot handle Unicode properly due to narrow/wide bug

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue12782] Multiple context expressions do not support parentheses for continuation across lines

Julian Berman 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

[issue12729] Python lib re cannot handle Unicode properly due to narrow/wide bug

Changes by Terry J. Reedy : Removed file: http://bugs.python.org/file22900/utf16.py ___ Python tracker ___ ___ Python-bugs-list mailing list U

[issue12729] Python lib re cannot handle Unicode properly due to narrow/wide bug

Terry J. Reedy 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. -

[issue9200] Make the str.is* methods work with non-BMP chars on narrow builds

Ezio Melotti 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 ___

[issue9200] Make the str.is* methods work with non-BMP chars on narrow builds

Ezio Melotti 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

[issue9200] Make the str.is* methods work with non-BMP chars on narrow builds

Roundup Robot 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

[issue9200] Make the str.is* methods work with non-BMP chars on narrow builds

STINNER Victor 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 ___ _

[issue9200] Make the str.is* methods work with non-BMP chars on narrow builds

Amaury Forgeot d'Arc 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

[issue12819] PEP 393 - Flexible Unicode String Representation

Changes by STINNER Victor : -- hgrepos: +62 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue12589] test_long.test_nan_inf() failed on OpenBSD (powerpc)

Remi Pointel added the comment: Hi, what information do you need to advance on this bug? Cheers, Remi. -- ___ Python tracker ___ ___

[issue12819] PEP 393 - Flexible Unicode String Representation

Changes by Ezio Melotti : -- nosy: +ezio.melotti, haypo, lemburg, loewis stage: -> patch review ___ Python tracker ___ ___ Python-bug

[issue12819] PEP 393 - Flexible Unicode String Representation

New submission from Torsten Becker : 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 benchmark

[issue12409] Moving "Documenting Python" to Devguide

Brett Cannon added the comment: +1 -- Added file: http://bugs.python.org/file23005/unnamed ___ Python tracker ___+1 ___ Python-bugs-l

[issue12795] Remove the major version from sys.platform

STINNER Victor 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

[issue12795] Remove the major version from sys.platform

Marc-Andre Lemburg added the comment: STINNER Victor wrote: > > STINNER Victor 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

[issue9200] Make the str.is* methods work with non-BMP chars on narrow builds

Roundup Robot 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

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Roundup Robot 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/77171f

[issue9993] shutil.move fails on symlink source

Jonathan Niehof 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

[issue12713] argparse: allow abbreviation of sub commands by users

Christian Ziemski 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_t

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Marc-Andre Lemburg added the comment: Ezio Melotti wrote: > > Ezio Melotti 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_

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Ezio Melotti 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 sti

[issue12795] Remove the major version from sys.platform

STINNER Victor 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. Fre

[issue12816] smtpd uses library outside of the standard libraries

Barry A. Warsaw 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 __

[issue12818] email.utils.formataddr incorrectly quotes parens inside quoted strings

R. David Murray 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:

[issue12817] test_multiprocessing: io.BytesIO() requires bytearray buffers

Stefan Krah 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 shou

[issue12795] Remove the major version from sys.platform

Marc-Andre Lemburg added the comment: STINNER Victor wrote: > > STINNER Victor 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

[issue12794] platform: add a function to get the system version as tuple

Changes by Arfrever Frehtes Taifersar Arahesis : -- 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 _

[issue9253] argparse: optional subparsers

Changes by Zsolt Cserna : -- nosy: +csernazs ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.

[issue12818] email.utils.formataddr incorrectly quotes parens inside quoted strings

New submission from R. David Murray : 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 p

[issue12794] platform: add a function to get the system version as tuple

STINNER Victor 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

[issue12795] Remove the major version from sys.platform

STINNER Victor 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 che

[issue12808] Coverage of codecs.py

Marc-Andre Lemburg added the comment: Tennessee Leeuwenburg wrote: > > Tennessee Leeuwenburg 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 ev

[issue12816] smtpd uses library outside of the standard libraries

R. David Murray 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-remov

[issue9200] Make the str.is* methods work with non-BMP chars on narrow builds

Ezio Melotti 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 build

[issue12794] platform: add a function to get the system version as tuple

Marc-Andre Lemburg 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 added the comment: > >>> No, it doesn't (except for a bug that Matthias Klose pointed out). >>> The

[issue11816] Refactor the dis module to provide better building blocks for bytecode analysis

Changes by Ryan Kelly : -- nosy: +rfk ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/ma

[issue11682] PEP 380 reference implementation for 3.3

Changes by Ryan Kelly : -- nosy: +rfk ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/ma

[issue12817] test_multiprocessing: io.BytesIO() requires bytearray buffers

New submission from Stefan Krah : 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 =

[issue9200] Make str methods work with non-BMP chars on narrow builds

Changes by Ezio Melotti : -- assignee: belopolsky -> ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue12794] platform: add a function to get the system version as tuple

Martin v. Löwis 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 fea

[issue12808] Coverage of codecs.py

Tennessee Leeuwenburg 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... -- Adde

[issue12794] platform: add a function to get the system version as tuple

Marc-Andre Lemburg added the comment: Martin v. Löwis wrote: > > Martin v. Löwis 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 fo

[issue12768] docstrings for the threading module

Eli Bendersky 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. --

[issue12794] platform: add a function to get the system version as tuple

Martin v. Löwis 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 *

[issue12795] Remove the major version from sys.platform

Marc-Andre Lemburg added the comment: STINNER Victor wrote: > > STINNER Victor 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.

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

Martin v. Löwis 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 oth

[issue12808] Coverage of codecs.py

Marc-Andre Lemburg 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 > presen

[issue12795] Remove the major version from sys.platform

STINNER Victor 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.

[issue12794] platform: add a function to get the system version as tuple

Marc-Andre Lemburg 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 wou

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

Marc-Andre Lemburg added the comment: STINNER Victor wrote: > > STINNER Victor 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 a

[issue12795] Remove the major version from sys.platform

Marc-Andre Lemburg 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", "f

[issue12794] platform: add a major function to get the system major version

STINNER Victor 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

[issue12795] Remove the major version from sys.platform

Ezio Melotti 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 elsewhe

[issue10042] total_ordering

Nick Coghlan 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

[issue12796] total_ordering goes into infinite recursion when NotImplemented is returned

Nick Coghlan added the comment: This is a dupe of #10042 -- resolution: -> duplicate status: open -> closed superseder: -> total_ordering ___ Python tracker ___ __

[issue12816] smtpd uses library outside of the standard libraries

New submission from Tennessee Leeuwenburg : 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 s

[issue12326] Linux 3: code should avoid using sys.platform == 'linux2'

STINNER Victor 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 :-) -- ___

  1   2   >