[issue12780] Clean up tests for pyc/pyo in __file__

Roundup Robot added the comment: New changeset 98d13885a574 by Vinay Sajip in branch '3.2': Issue #12780: Removed checks in logging for .pyc/.pyo in __file__. http://hg.python.org/cpython/rev/98d13885a574 New changeset ac0c04d8eafb by Vinay Sajip in branch 'default': Issue #12780: Merged fix fr

[issue11564] pickle not 64-bit ready

Nadeem Vawda added the comment: I have tried running the tests on a machine with 12GB of RAM, but when I do so, the new tests get skipped saying "not enough memory", even when I specify "-M 11G" on the command-line. The problem seems to be the change to the precisionbigmemtest decorator in tes

[issue12781] Mention SO_REUSEADDR near socket doc examples

Eli Bendersky added the comment: Wouldn't it be better to just add the flag to the example and then explain it in a few sentences? -- nosy: +eli.bendersky ___ Python tracker __

[issue12672] Some problems in documentation extending/newtypes.html

Changes by Eli Bendersky : -- resolution: -> fixed status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Un

[issue12672] Some problems in documentation extending/newtypes.html

Roundup Robot added the comment: New changeset 893f858c600e by Eli Bendersky in branch '2.7': Issue #12672: remove confusing part of sentence in documentation http://hg.python.org/cpython/rev/893f858c600e -- ___ Python tracker

[issue12672] Some problems in documentation extending/newtypes.html

Roundup Robot added the comment: New changeset d062d482642c by Eli Bendersky in branch '3.2': Issue #12672: remove confusing part of sentence in documentation http://hg.python.org/cpython/rev/d062d482642c New changeset 558f2270cba8 by Eli Bendersky in branch 'default': Merge from 3.2 http://hg.

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

New submission from Julian Berman : Using multiple `with` statements across multiple lines does not support using parens to break them up: with (open("a_really_long_foo") as foo, open("a_really_long_bar") as bar): pass Traceback (most recent call last): File "", line 1, in File

[issue2651] Strings passed to KeyError do not round trip

Changes by Julian Berman : -- nosy: +Julian ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue7433] MemoryView memory_getbuf causes segfaults, double call to tp_releasebuffer

Changes by Meador Inge : -- stage: -> needs patch ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue2651] Strings passed to KeyError do not round trip

Changes by Meador Inge : -- stage: needs patch -> patch review ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: h

[issue8743] set() operators don't work with collections.Set instances

Changes by Meador Inge : -- resolution: accepted -> stage: needs patch -> patch review ___ Python tracker ___ ___ Python-bugs-list mai

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

James Y Knight added the comment: > Sure, you can compile and run Python on both versions of Linux, but > what if your application uses features that are only present in Linux > 3.0 and later ? This comment is making me think you've missed just how irrelevant kernel version 3.0 really is. To a

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

Marc-Andre Lemburg added the comment: Barry A. Warsaw wrote: > > Barry A. Warsaw added the comment: > > On Aug 18, 2011, at 05:54 PM, Martin v. Löwis wrote: > >> As for the cases where "linux3" is reported: I don't care that >> they break. Python 2.6 and Python 2.7.2 is incompatible with >>

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

Marc-Andre Lemburg added the comment: James Y Knight wrote: > > James Y Knight added the comment: > > M.A., your comments do not make sense in the context of Linux. It does not > actually require porting -- Linux 2.6.39 to Linux 3.0 is no more disruptive > than Linux 2.6.38 to Linux 2.6.39.

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

Barry A. Warsaw added the comment: On Aug 18, 2011, at 05:54 PM, Martin v. Löwis wrote: >As for the cases where "linux3" is reported: I don't care that >they break. Python 2.6 and Python 2.7.2 is incompatible with >Linux 3. Users should be advised to a) not upgrade to Linux 3, or >b) simultaneo

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

James Y Knight added the comment: M.A., your comments do not make sense in the context of Linux. It does not actually require porting -- Linux 2.6.39 to Linux 3.0 is no more disruptive than Linux 2.6.38 to Linux 2.6.39. *Except* that python ill-advisedly exported a "platform" string which inc

[issue12650] Subprocess leaks fd upon kill()

Charles-François Natali added the comment: > This means that the child process didn't get reaped by _cleanup(). The most likely cause is that when _cleanup() calls waitpid(pid, WNOHANG), the child process hasn't exited yet. Since I had already set a rather high timeout to avoid this problem an

[issue12650] Subprocess leaks fd upon kill()

Roundup Robot added the comment: New changeset 122f952add3c by Charles-François Natali in branch '3.2': Issue #12650: fix failures on some buildbots, when a subprocess takes a long http://hg.python.org/cpython/rev/122f952add3c New changeset a32ae2749cd1 by Charles-François Natali in branch 'def

[issue12781] Mention SO_REUSEADDR near socket doc examples

New submission from Sandro Tosi : Following up http://mail.python.org/pipermail/docs/2011-April/004025.html here's a patch to add a notice about SO_REUSEADDR after the examples, so even re-running several times and getting that error, wont scare anyone. -- assignee: docs@python compone

[issue12650] Subprocess leaks fd upon kill()

Charles-François Natali added the comment: Reopening. The new tests are failing on solaris and Debian parallel buildbots: http://www.python.org/dev/buildbot/all/builders/x86 debian parallel 3.x/builds/2734/steps/test/logs/stdio http://www.python.org/dev/buildbot/all/builders/sparc solaris10 gcc

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

Marc-Andre Lemburg added the comment: Some thoughts: * We can't change the value of a system variable in a patch level release. It's not a bug and the change is not motivated by Python, but by the OS vendor. So changes to released versions are not possible. They are also not necessary

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

Vinay Sajip added the comment: Just to clarify: I'm -1 on heuristics too; it's better to have some way of explicitly declaring the intention. I've no problem with e.g. the [scripts] section being used just for generated scripts, as long as there is a clear way of designating arbitrary .py/.py

[issue12765] test_packaging failure under Snow Leopard

Ned Deily added the comment: The culrpit is test_custom_pydistutils (packaging.tests.test_dist.MetadataTestCase) Lib/packaging/tests/test_dist.py:379 & 386 -- ___ Python tracker _

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

Martin v. Löwis added the comment: >>> Really, it's not difficult to understand that code testing for "linux2" >>> will stop working when "linux3" gets released. >> >> This doesn't matter. People will still complain. And, as there is an >> obvious work-around, why not make people's lives easier?

[issue12720] Expose linux extended filesystem attributes

Changes by Antoine Pitrou : -- nosy: +neologix ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue9850] obsolete macpath module dangerously broken and should be removed

Oleg Oshmyan added the comment: It is already tested but here is a new version of the patch that expands the existing test to cover the situation that was broken (plus another one). -- Added file: http://bugs.python.org/file22943/macpath_join_fix_with_test.patch __

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

Martin v. Löwis added the comment: > You just said that "we" already had the same problem when Linux 2 was > released. So hopefully "people want better backwards compatibility" > would have learnt from that experience, and stopped hard-coding version > numbers. No, when Linux 2 was released (19

[issue5845] rlcompleter should be enabled automatically

Antoine Pitrou added the comment: > Updated patch (not using Mercurial, looks like I haven’t enough > bandwidth to push all those changesets). I think there's a bug in the way you are detecting interactive mode: $ ./python -c "import sys; print(sys.stdin.isatty())" True -- __

[issue7105] weak dict iterators are fragile because of unpredictable GC runs

Matthew Schwickerath added the comment: Any plans on actually patching this in 2.7 any time soon? This is affecting our software and hanging it on random occasions. -- nosy: +qelan ___ Python tracker

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

Antoine Pitrou added the comment: > > Really, it's not difficult to understand that code testing for "linux2" > > will stop working when "linux3" gets released. > > This doesn't matter. People will still complain. And, as there is an > obvious work-around, why not make people's lives easier? A

[issue5845] rlcompleter should be enabled automatically

Antoine Pitrou added the comment: Interestingly, there's already the following code in Modules/main.c: if ((Py_InspectFlag || (command == NULL && filename == NULL && module == NULL)) && isatty(fileno(stdin))) { PyObject *v; v = PyImport_ImportModule("readline");

[issue12650] Subprocess leaks fd upon kill()

Charles-François Natali added the comment: Patch committed. This should also fix the original problem. Gabriele, thanks for the report. -- resolution: -> fixed stage: -> committed/rejected status: open -> closed ___ Python tracker

[issue12778] JSON-serializing a large container takes too much memory

Antoine Pitrou added the comment: This patch does the trick. -- keywords: +patch Added file: http://bugs.python.org/file22942/jsonacc.patch ___ Python tracker ___ __

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

Antoine Pitrou added the comment: > > Then, let's just advise that all code follow the same path and use > > sys.platform.startswith() (which is really not a difficult change to > > make). > > Antoine, please accept that people want better backwards compatibility > than just recommendations how

[issue12765] test_packaging failure under Snow Leopard

Éric Araujo added the comment: Thanks. I’m not sure if it’s possible to use for example -vvG to stop regrtest right after the test that fails to restore HOME; when I fixed similar environ changes, I had to edit regrtest to make it fail early. The culprit may be packaging.tests.test_database.

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

Martin v. Löwis added the comment: > Then, let's just advise that all code follow the same path and use > sys.platform.startswith() (which is really not a difficult change to > make). Antoine, please accept that people want better backwards compatibility than just recommendations how to rewrite

[issue12765] test_packaging failure under Snow Leopard

Ned Deily added the comment: I can reproduce this. With -vv, the only difference in os.environ is HOME: Before: 'HOME': '/Users/nad' After: 'HOME': '/tmp/tmpqryo48/tmpt_mcrw' Also, Warning -- threading._dangling was modified by test_packaging Before: <_weakrefset.WeakSet object at 0x101

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

Antoine Pitrou added the comment: > > It means someone upgrading from 2.6 to 2.7 will see sys.platform change > > from "linux3" to "linux2". That breaks compatibility. > > No, it doesn't. Code that works on 2.6 and Linux 3 will likely support > both linux2 and linux3, so it will continue just f

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

Martin v. Löwis added the comment: > - "linux3" on Python <= 2.7.2 or Python <= 3.2.1 > - "linux2" on 2.7.3 <= Python or 3.2.2 <= Python < 3.3 > - "linux" on Python >= 3.3 > > I don't see how it will help backward or forward compatibility... It's very easy to see. In the long term (ten years)

[issue8668] Packaging: add a 'develop' command

Éric Araujo added the comment: > [...] so I keep this command name as 'develop' and the simple usage > of this command is : > pysetup run develop So far, so good. > BTW, most developers in this list have agreed that 'develop' is a > kind of install command, so I also add an entry funtion > 'ins

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

James Y Knight added the comment: > Well, except maybe if you plan to write applications working only on Python > >= 2.7.3? ... this version is not released yet. No, of course I don't plan on writing new code that checks sys.platform == 'linux2'. That's ridiculous. I plan to use *already wri

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

Martin v. Löwis added the comment: > It means someone upgrading from 2.6 to 2.7 will see sys.platform change > from "linux3" to "linux2". That breaks compatibility. No, it doesn't. Code that works on 2.6 and Linux 3 will likely support both linux2 and linux3, so it will continue just fine on 2.

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

Martin v. Löwis added the comment: > I don't understand why do you want to have a special case for Linux. > sys.platform is already different for each major version of: That's because Linux uses major version numbers in an entirely different way than these systems. There is a traditional usage

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

Martin v. Löwis added the comment: > The point is precisely that we don't change anything: applications > checking against sys.platform are already broken, there's no reason to > comfort them into using this defective check. You grossly misunderstand the concept of "backwards compatibility". At

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

Éric Araujo added the comment: Heh, I messed up my example: unit2-tk = unittest2.gui.main gui -- ___ Python tracker ___ ___ Python-b

[issue12780] Clean up tests for pyc/pyo in __file__

Changes by Éric Araujo : Added file: http://bugs.python.org/file22941/__file__-cant-contain-pyc-in-3.2.diff ___ Python tracker ___ ___ Python

[issue12780] Clean up tests for pyc/pyo in __file__

Changes by Éric Araujo : Removed file: http://bugs.python.org/file22940/fix-11599.diff ___ Python tracker ___ ___ Python-bugs-list mailing lis

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

Éric Araujo added the comment: > scripts = >foo = a.b.c.main >foowin = a.b.c.winmain -window This is great. About -window: I don’t think using a fake option style (leading -) is useful, and I’d reuse the setuptools name, “gui”. I also think this good idea of yours can solve our oth

[issue12765] test_packaging failure under Snow Leopard

Antoine Pitrou added the comment: Bill is the owner of that buildbot. -- nosy: +janssen ___ Python tracker ___ ___ Python-bugs-list m

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

Changes by Éric Araujo : Removed file: http://bugs.python.org/file22934/unnamed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

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

Changes by Éric Araujo : Removed file: http://bugs.python.org/file22933/unnamed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue12780] Clean up tests for pyc/pyo in __file__

New submission from Éric Araujo : After PEP 3147, __file__ always points to the py file, not pyc/pyo. I found two instances of obsolete code. -- files: fix-11599.diff keywords: patch messages: 142375 nosy: benjamin.peterson, eric.araujo, vinay.sajip priority: normal severity: normal st

[issue8286] distutils: path '[...]' cannot end with '/' -- need better error message

Éric Araujo added the comment: Can you test with this patch? -- keywords: +patch versions: -Python 3.1 Added file: http://bugs.python.org/file22939/sdist-no-traceback-3.2.diff ___ Python tracker __

[issue12650] Subprocess leaks fd upon kill()

Roundup Robot added the comment: New changeset 148d75d106f1 by Charles-François Natali in branch 'default': Issue #12650: Fix a race condition where a subprocess.Popen could leak http://hg.python.org/cpython/rev/148d75d106f1 -- ___ Python tracker

[issue11599] Useless error message when distutils fails compiling

Changes by Éric Araujo : Added file: http://bugs.python.org/file22938/fix-11599.diff ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue11599] Useless error message when distutils fails compiling

Changes by Éric Araujo : Removed file: http://bugs.python.org/file21316/fix-compile-error-messages.diff ___ Python tracker ___ ___ Python-bugs

[issue12720] Expose linux extended filesystem attributes

Benjamin Peterson added the comment: Here is a new patch, implementing Antoine's suggestions. -- Added file: http://bugs.python.org/file22937/xattrs.patch ___ Python tracker ___

[issue5845] rlcompleter should be enabled automatically

Éric Araujo added the comment: Updated patch (not using Mercurial, looks like I haven’t enough bandwidth to push all those changesets). -- Added file: http://bugs.python.org/file22936/fix-5845.diff ___ Python tracker

[issue5845] rlcompleter should be enabled automatically

Changes by Éric Araujo : Removed file: http://bugs.python.org/file21399/fix-5845.diff ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue12761] Typo in Doc/license.rst

Sandro Tosi added the comment: After a closer look (thanks Ezio), the proper patch should be something like: diff --git a/Doc/license.rst b/Doc/license.rst --- a/Doc/license.rst +++ b/Doc/license.rst @@ -874,9 +874,8 @@ zlib -The :mod:`zlib` extension is built using an included copy o

[issue11553] Docs for: import, packages, site.py, .pth files

Éric Araujo added the comment: FYI, I have updated the site module and distutils/packaging docs to document the PEP 370 features. There has been no feedback, so I will backport to 2.7 and close the reports. See linked bugs to read the changesets. --

[issue12779] Update packaging documentation

New submission from Éric Araujo : The documentation for packaging is outdated: it refers to setup.py instead of setup.cfg or pysetup, it talks about removed parts like compress (.Z) archives or bdist_rpm, and needs a good read-through. I have started to work on this, so I’m opening this repor

[issue12650] Subprocess leaks fd upon kill()

Roundup Robot added the comment: New changeset 8ca7f109ce79 by Charles-François Natali in branch '3.2': Issue #12650: Fix a race condition where a subprocess.Popen could leak http://hg.python.org/cpython/rev/8ca7f109ce79 -- ___ Python tracker

[issue12779] Update packaging documentation

Éric Araujo added the comment: (Replying to myself so that this report doesn’t show up in the “Issues without reply” section of the weekly email) -- nosy: +docs@python ___ Python tracker _

[issue9850] obsolete macpath module dangerously broken and should be removed

Éric Araujo added the comment: Thanks for the patch. Is the function already tested or does someone need to add a test? -- ___ Python tracker ___ __

[issue12765] test_packaging failure under Snow Leopard

Éric Araujo added the comment: Is it possible to run the test suite with -vv on the buildbot to see the changes made to os.environ? On a related note, is it possible to get SSH access to a similar machine? If not, I will add debugging info in a commit and watch the buildbot; it will be more

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

Marc-Andre Lemburg added the comment: STINNER Victor wrote: > > STINNER Victor added the comment: > > I don't think that macros specific to unicodeobject.c should get the > _PY_UNICODE_ prefix. "_Py_" prefix is reserved to exported symbols, but > symbols reserved for the Python interprefer

[issue12775] immense performance problems related to the garbage collector

Antoine Pitrou added the comment: > So overall it looks like it's less of a problem in newer versions of > Python. We are phasing out the software that is deployed on Debian > Lenny so it's a problem that will go away. I don't think I have any > objections with closing this ticket again. Thanks

[issue12778] JSON-serializing a large container takes too much memory

poq added the comment: I think this is because dumps() uses the C encoder. Making the C encoder incremental (i.e. iterator-based) like the Python encoder would solve this. I actually looked into doing this for issue #12134, but it didn't seem so simple; Since C has no yield, I think the itera

[issue12775] immense performance problems related to the garbage collector

Daniel Svensson added the comment: Yes, but this ticket was only opened due to time delta between no-gc and gc, not as much absolute time, but that's a nice improvement. -- ___ Python tracker

[issue12775] immense performance problems related to the garbage collector

Ezio Melotti added the comment: IIRC the C acceleration for json were added in 2.7/3.2, and are used automatically when you import json. In the previous releases the json module was implemented in pure Python. That explains why it's much slower on Python 2.5/6. -- nosy: +ezio.melot

[issue12775] immense performance problems related to the garbage collector

Changes by Daniel Svensson : -- versions: -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4 ___ Python tracker ___ ___ Pyth

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

STINNER Victor added the comment: I don't think that macros specific to unicodeobject.c should get the _PY_UNICODE_ prefix. "_Py_" prefix is reserved to exported symbols, but symbols reserved for the Python interprefer itself. For _Py_UNICODE_NEXT, you can call it NEXT_CHARACTER(). _Py_UNICO

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

Changes by Charles-François Natali : -- nosy: -neologix ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:/

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

STINNER Victor added the comment: If we change Python 2.7.3 and 3.2.2 to force sys.platform to linux2 (instead of linux3) and use "linux" in Python 3.3, we will have 3 differents values of sys.platform if Python is built on Linux 3: - "linux3" on Python <= 2.7.2 or Python <= 3.2.1 - "linux2

[issue12775] immense performance problems related to the garbage collector

Daniel Svensson added the comment: using: (except in python2.5 case where simplejson is used, which ought to be the same thing right?) import time, gc, json, sys def read_json_blob(): t0 = time.time() fd = open("datatest1.json") data = fd.read() fd.close()

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

STINNER Victor added the comment: > For Python 3.3, (...) In parallel we can change the stdlib > tests to use .startswith() done, see my changeset 50f1922bc1d5 -- ___ Python tracker __

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

Antoine Pitrou added the comment: > Correct. We can't touch Python 3.1, 2.6, or earlier because those are all in > security-only mode, and unless a specific security related issue is > identified, the change should not be made there. That's just life (a recent > similar example is support for

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

Barry A. Warsaw added the comment: On Aug 18, 2011, at 03:58 PM, STINNER Victor wrote: > >STINNER Victor added the comment: > >> I'm just suggesting one more special case for linux* > >You suggest to have a special case in Python 2.7 and 3.2, but not in Python >3.3 (3.1, 2.6, etc.)? Correct.

[issue12760] Add create mode to open()

David Townshend added the comment: I hope this patch suits you better :-) I've updated the documentation typo (thanks for pointing that out). I've also changed 'c' to 'x', since I think that if there is a convention we should stick to it. I don't think that it matters if the glibc docs say '

[issue8668] Packaging: add a 'develop' command

Alexis Metaireau added the comment: On 08/18/2011 05:54 PM, higery wrote: > Then do you also mean support that for setuptools install is also not > necessary in packaging core? setuptools install is only supported in packaging because it's a widely used thing, and many python distributions ar

[issue12776] argparse: type conversion function should be called only once

Changes by Ned Deily : -- nosy: +bethard ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

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

STINNER Victor added the comment: > I'm just suggesting one more special case for linux* You suggest to have a special case in Python 2.7 and 3.2, but not in Python 3.3 (3.1, 2.6, etc.)? -- ___ Python tracker __

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

Vinay Sajip added the comment: > >NO. I removed the 'copy_scripts' function, so I did not use your developed >functionality. After this change, Packaging module now just builds new-style >scripts and old-style scripts will be built by distutils/setuptools. To >

[issue12650] Subprocess leaks fd upon kill()

Roundup Robot added the comment: New changeset 7d358379c5fb by Charles-François Natali in branch '2.7': Issue #12650: only run the tests on Unix. http://hg.python.org/cpython/rev/7d358379c5fb -- ___ Python tracker

[issue8668] Packaging: add a 'develop' command

higery added the comment: >>IOW, in my opinion, support for setuptools develop command is not needed in >>packaging core Then do you also mean support that for setuptools install is also not necessary in packaging core? >>and still be taken care directly be the users wanting to run python se

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

Barry A. Warsaw added the comment: On Aug 18, 2011, at 03:45 PM, STINNER Victor wrote: >I don't understand why do you want to have a special case for >Linux. sys.platform is already different for each major version of: We already have special cases for cygwin, darwin, and irix (okay, the latte

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

STINNER Victor added the comment: > I still think that sys.platform for the stable releases should > never report 'linux3' I don't understand why do you want to have a special case for Linux. sys.platform is already different for each major version of: * FreeBSD * OpenBSD * NetBSD * unix

[issue12775] immense performance problems related to the garbage collector

Daniel Svensson added the comment: Working on getting a reasonable large file to test with on my laptop where I have 2.6, 2.7, 3.2. The Python version where the problem became apparent was 2.5.2 as the software is deployed on Debian Lenny. -- ___ P

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

Barry A. Warsaw added the comment: On Aug 18, 2011, at 01:15 PM, Charles-François Natali wrote: >Charles-François Natali added the comment: > >> My question too!  I would say that stable releases should probably not get >> this change, but should force sys.platform to linux2 on 3.x kernels. >

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

Vinay Sajip added the comment: There are two kinds of configuration files supported in Packaging, and you can say it maybe a transition consideration from  distutils/setuptools to Packaging, but if you look into the documents of Packaging(you can generate it from the /Doc directory), you will

[issue8668] Packaging: add a 'develop' command

Alexis Metaireau added the comment: Yep, packaging is not keeping the .egginfo directories, or at least does not plan to keep them (It should be the case currently but I haven't checked recently) in the upcoming release, so I would go on removing support for setuptools' develop command here :

[issue8668] Packaging: add a 'develop' command

higery added the comment: Alexis Metaireau added the comment: >>I'm not sure why you're talking about it in the context of develop, can you >>clarify this? My consideration is : if in Packaging we always convert .egg-info directory to .dist-info directory, then my two different kinds of ways

[issue12757] undefined name in doctest.py

Michele Orrù added the comment: It is possible to retrieve the current module using _normalize_module(None), or instead use the test name (dt_test.name) just like in DocTestCase.shortDescription. Since there is no doc about it, IMHO we should use unittest's standard as guideline, which is:

[issue12778] JSON-serializing a large container takes too much memory

New submission from Antoine Pitrou : On a 8GB RAM box (more than 6GB free), serializing many small objects can eat all memory, while the end result would take around 600MB on an UCS2 build: $ LANG=C time opt/python -c "import json; l = [1] * (100*1024*1024); encoded = json.dumps(l)" Traceback

[issue12650] Subprocess leaks fd upon kill()

Roundup Robot added the comment: New changeset 9ee802642d86 by Charles-François Natali in branch '2.7': Issue #12650: Fix a race condition where a subprocess.Popen could leak http://hg.python.org/cpython/rev/9ee802642d86 -- nosy: +python-dev ___ Pyth

[issue12777] Inconsistent use of VOLUME_NAME_* with GetFinalPathNameByHandle

Antoine Pitrou added the comment: That's slightly off-topic, but is it enough to strip the leading '\\?\' (and replace 'UNC' with '\'), or are there other things to watch out for? -- ___ Python tracker __

[issue12760] Add create mode to open()

STINNER Victor added the comment: > I don't know if it's documented behavior See #12103: it is not documented. -- ___ Python tracker ___ ___

[issue8668] Packaging: add a 'develop' command

Alexis Metaireau added the comment: IOW, in my opinion, support for setuptools develop command is not needed in packaging core, and still be taken care directly be the users wanting to run python setup.py develop: I don't see any reason to make it avaible on the stdlib. -- _

[issue8668] Packaging: add a 'develop' command

Alexis Metaireau added the comment: _run_setuptools_install is only intended to support setuptools setup.py, converting .egg-info to .dist-info, internally. IMO, you should not care about the differences between setuptools/distutils1/setuptools at this level, as it should be taken care at the

  1   2   >