[issue11715] Building Python on multiarch Debian and Ubuntu

Nick Coghlan added the comment: I'm not sure this is 100% fixed. After dist-upgrading the Kubuntu VM on my netbook and updating to the latest Py3k code, I got a lot of test errors, even after a make distclean and ./configure. The errors went away after manually tweaking LDFLAGS as Christian d

[issue12775] immense performance problems related to the garbage collector

New submission from Daniel Svensson : I've noticed problems with the GC in two applications. In one case the application did not respond to SOAP-requests for 9 seconds, every couple of minutes, when it really shouldn't have taken more than 20ms. In another case we had one operation executed by

[issue12772] fractional day attribute in datetime class

Changes by Daniel Urban : -- nosy: +durban versions: +Python 3.3 -Python 2.7 ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue12775] immense performance problems related to the garbage collector

Changes by Daniel Urban : -- nosy: +durban ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

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

New submission from Arnaud Fontaine : When specifying a function to be called in type keyword argument of add_argument(), the function is actually called twice (when a default value is set and then when the argument is given). While this may not be a problem in most cases (such as converting t

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

Changes by Arnaud Fontaine : -- keywords: +patch Added file: http://bugs.python.org/file22927/py2.7-argparse-call-type-function-once.patch ___ Python tracker ___ ___

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

Changes by Arnaud Fontaine : Added file: http://bugs.python.org/file22928/py3k-argparse-call-type-function-once.patch ___ Python tracker ___

[issue12767] document threading.Condition.notify

Antoine Pitrou added the comment: > I asked the user who reported this documentation omission what he's > using the 'n' argument for. His reply: > > "Yes I am using the n parameter, it is mainly to implement a > subclass of Queue that supports "bulk" get and put operations. This > enhances

[issue3871] cross and native build of python for mingw32 with distutils

Changes by Kalev Lember : -- nosy: +kalev ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue3754] cross-compilation support for python build

Changes by Kalev Lember : -- nosy: +kalev ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org

[issue12760] Add create mode to open()

Antoine Pitrou added the comment: The "#ifdef O_EXCL" in the source code is probably very old. Copying a message I posted on python-ideas: O_EXCL is a POSIX standard. It is also supported under Windows by the _open/_wopen compatibility functions (which we use for file I/O). Probably there are

[issue12760] Add create mode to open()

David Townshend added the comment: My aim isn't to add all the commonly used flags, that would be pointless since its already possible using os.open. The aim is to add a missing feature to the builtin open(), i.e. file creation. At the moment open() implements read, write, and append, and c

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

Oleg Oshmyan added the comment: I fully agree with Ronald’s proposal. And for a start, here is a trivial patch that fixes macpath.join('', ...) [at the moment it just returns its last argument]. By the way, this fix is probably eligible for inclusion in Python 2.7 too. I also have ‘implement

[issue12775] immense performance problems related to the garbage collector

Amaury Forgeot d'Arc added the comment: Which version of Python did you test with? Can you try with version 3.2? -- nosy: +amaury.forgeotdarc ___ Python tracker ___

[issue12775] immense performance problems related to the garbage collector

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

[issue12775] immense performance problems related to the garbage collector

STINNER Victor added the comment: Can you try to write a short example to reproduce the problem? -- ___ Python tracker ___ ___ Python

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

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. > The point is precisely that we don't change anything: applications checking against sys.platform are a

[issue12760] Add create mode to open()

Charles-François Natali added the comment: > The "#ifdef O_EXCL" in the source code is probably very old. Copying a > message I posted on python-ideas: > > O_EXCL is a POSIX standard. It is also supported > under Windows by the _open/_wopen compatibility functions (which we use > for file I/O).

[issue12760] Add create mode to open()

David Townshend added the comment: Changing form 'c' to 'x' is easy enough, and if there is already a convention it makes sense to stick to it. I thought I had done a mercurial diff! I'll try again and resubmit. -- ___ Python tracker

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

Ezio Melotti added the comment: The attached patch fixes all the str.is* methods and makes them work on narrow builds with non-BMP chars. It also includes the _Py_UNICODE_NEXT macro proposed in #10542. -- Added file: http://bugs.python.org/file22930/issue9200.diff __

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

Ezio Melotti added the comment: I attached a patch to fix the str.is* methods on #9200 that also includes the macro. Since they are not public there, I don't see a reason to do 2 separate commits on 2.7/3.2 (one for the feature and one for the fix). -- __

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

Ezio Melotti added the comment: (Note: I copied the macros from the other patch without changing the name. If the approach is good I'll get rid of the prefixes and separate the words in IS{HIGH|LOW}SURROGATE with an _.) -- ___ Python tracker

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

Changes by Ezio Melotti : Removed file: http://bugs.python.org/file22930/issue9200.diff ___ Python tracker ___ ___ Python-bugs-list mailing lis

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

Changes by Ezio Melotti : Added file: http://bugs.python.org/file22931/issue9200.diff ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue12775] immense performance problems related to the garbage collector

Charles-François Natali added the comment: There's been some work done on the GC some time ago to address this type of pattern (I think to reduce from quadratic complexity to amortized linear complexity). I'm adding Antoine and Martin who were involved in this. > Here is a short python script

[issue12760] Add create mode to open()

Julian Berman added the comment: A minor documentation error in io.rst line 475 which was changed to: + The *mode* can be ``'c'``, ``'r'``, ``'w'`` or ``'a'`` for reading + (default), writing, or appending. and should have "creating" at the front I assume, like you have it later.

[issue12760] Add create mode to open()

Antoine Pitrou added the comment: > Well, I'd rather have this flag called 'x', to be consistent with > glibc's fopen(): > > """ >c (since glibc 2.3.3) > Do not make the open operation, or subsequent read and write > operations, thread cancellation points. >

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

higery added the comment: >>IIUC the support for setup.py is transitional, i.e. "legacy support", for >>existing packages transitioning from distutils/setuptools/Distribute to >>packaging. New features should not rely on the existence of setup.py. I know, the implementation way of scripts has

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

higery added the comment: >>BTW higery, did you use any of the build-scripts functionality I developed in >>the pythonv branch? NO. I removed the 'copy_scripts' function, so I did not use your developed functionality. After this change, Packaging module now just builds new-style scripts and

[issue12775] immense performance problems related to the garbage collector

Antoine Pitrou added the comment: As Charles-François said: it would be nice to know which Python version you are using. Also, if you could test with 2.7 or 3.2 and the standard json module (or the latest simplejson if you prefer). Also, while Python's performance is not always excellent, it

[issue8668] Packaging: add a 'develop' command

Changes by higery : Added file: http://bugs.python.org/file22932/af7d14ff129b.diff ___ Python tracker ___ ___ Python-bugs-list mailing list Uns

[issue12777] Inconsistent use of VOLUME_NAME_* with GetFinalPathNameByHandle

New submission from Antoine Pitrou : In the implementation of nt._getfinalpathname() (in posixmodule.c) we have: /* We have a good handle to the target, use it to determine the target path name. */ buf_size = Py_GetFinalPathNameByHandleW(hFile, 0, 0, VOLUME_NAME_NT); [...] r

[issue12777] Inconsistent use of VOLUME_NAME_* with GetFinalPathNameByHandle

Brian Curtin added the comment: Adding Jason - I'll dig around for it, but I think I brought this up in the past and I seem to remember him having a justification for it. (apologies if I'm thinking of something else) -- nosy: +jason.coombs ___ Pyth

[issue12775] immense performance problems related to the garbage collector

Daniel Svensson added the comment: The bug note contains a test script. You just have to generate a huge JSON-blob, or allocate 1 GB or so and pickle it down to file and replace the cjson.decode to pickle.loads, pickle is about 20 times faster without GC. -- _

[issue12775] immense performance problems related to the garbage collector

Daniel Svensson added the comment: "Or you could disable the GC only when decoding JSON data and reenable it afterwards." JSON was just an example, and disabling/enabling the GC is not safe in a multithreaded environment? -- ___ Python tracker

[issue8668] Packaging: add a 'develop' command

higery added the comment: Through discussing inside or outside the mailing list on this bug tracker, current 'develop' has been made a kind of command other than an action. But there still isn't a consensus of the concrete implemention way, so I keep this command name as 'develop' and the sim

[issue12777] Inconsistent use of VOLUME_NAME_* with GetFinalPathNameByHandle

Jason R. Coombs added the comment: I agree the two calls should probably be consistent, though I also suspect that VOLUME_NAME_NT is always longer than VOLUME_NAME_DOS. My justification for using VOLUME_NAME_NT is that the final name might not be located on a DOS-accessible name. My suspicion

[issue12775] immense performance problems related to the garbage collector

Antoine Pitrou added the comment: > The bug note contains a test script. You just have to generate a huge > JSON-blob, or allocate 1 GB or so and pickle it down to file and > replace the cjson.decode to pickle.loads, pickle is about 20 times > faster without GC. You can't say that any "huge JSO

[issue12760] Add create mode to open()

Charles-François Natali added the comment: > Yeah, but I think "exclusively" is quite misleading since it does not > perform any locking of any kind. It might be misleading, but I find it clear enough, and this name has been endorsed by POSIX. Furthermore, there's an added bonus: actually, wi

[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

[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. -- _

[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 ___ ___

[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 __

[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

[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

[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:

[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

[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 :

[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

[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. >

[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'

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

[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

[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

[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

[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 >

[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 __

[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

[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

[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 '

[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.

[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'

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 __

[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: 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

[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:/

[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

[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

[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

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

[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

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

[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

[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

[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 ___ __

[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 _

[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

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

[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. --

[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

[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

[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

[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 ___

[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

[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

[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

[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 __

[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

[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

[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

[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)

É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

[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

[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

[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

[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

[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: > 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'

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

[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

  1   2   >