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

[Roundup Robot]

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 from 3.2.
http://hg.python.org/cpython/rev/ac0c04d8eafb

--
nosy: +python-dev

___
Python tracker 

___
___
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 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 test.support. I don't understand what the purpose of the "dryrun"
flag is, but the modified condition for skipping doesn't look right to me.

(Now that I think about it, I should be able to get the tests to run by undoing
that one part of the change. I'll get back to you about the results later 
today.)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12781] Mention SO_REUSEADDR near socket doc examples

[Eli Bendersky]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Eli Bendersky]

Changes by Eli Bendersky :


--
resolution:  -> fixed
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Roundup Robot]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Roundup Robot]

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.python.org/cpython/rev/558f2270cba8

--

___
Python tracker 

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

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 "demo.py", line 19
with (open("a_really_long_foo") as foo,
^
SyntaxError: invalid syntax


Also, without convoluting things, import also does not support doing so, and is 
the only other example I can think of of a compound statement that forces you 
to either be redundant or bite your teeth and use \, despite the fact that PEP 
328 gave us parens for from imports.

(I did not find a discussion as to why import didn't grow it as well, so please 
correct me as I'm sure it must have been discussed before).

It's understandably a lot rarer to need multiple lines when importing, but it'd 
be nice if all compound statements uniformly allowed the same continuation 
syntax.

--
components: Interpreter Core
messages: 142411
nosy: Julian
priority: normal
severity: normal
status: open
title: Multiple context expressions do not support parentheses for continuation 
across lines
type: behavior
versions: Python 2.7, Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2651] Strings passed to KeyError do not round trip

[Julian Berman]

Changes by Julian Berman :


--
nosy: +Julian

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Meador Inge]

Changes by Meador Inge :


--
stage:  -> needs patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2651] Strings passed to KeyError do not round trip

[Meador Inge]

Changes by Meador Inge :


--
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Meador Inge]

Changes by Meador Inge :


--
resolution: accepted -> 
stage: needs patch -> patch review

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[James Y Knight]

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 first approximation, it *has no new features*. Now, 
to be sure, there are a couple of things, sure. Just like there were a couple 
new features in 2.6.39 two months earlier, 2.6.38 two months before that, 
2.6.37 two months before that, and so on, every 2-3 months, back to the release 
of 2.6.7 or so in 2004.

> BTW: The new attribute should contain the complete version number,
> not just the major version. `uname -r` would provide a good start.

To be useful, that would have to be a runtime-computed thing, not the 
build-time value that sys.platform's trailing number is. But we already have 
that: os.uname(). It certainly doesn't need a second name.

--

___
Python tracker 

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

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
>> Linux 3. Users should be advised to a) not upgrade to Linux 3, or
>> b) simultaneously upgrade to a newer Python release, or
>> c) work-around in their applications.
>>
>> I expect that most users chose a) for some time to come (until
>> the Linux distributions ship the new kernels), and that the Linux
>> distributions chose b) and c).
> 
> In fact, for Debian and Ubuntu, we had several breakages due to sys.platform
> == 'linux3' so for all Pythons we still support, we're going to force it back
> to 'linux2'.  This fixed all those broken packages without any of them needing
> to be changed.

Ah, those lazy Debian/Ubuntu folks again ;-)

--

___
Python tracker 

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

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. *Except* that python ill-advisedly 
> exported a "platform" string which included a value which is completely 
> irrelevant on Linux, and has now changed.

That's a details of how Linux is managed. In terms of releases,
it's a new major release.

> The bug here that should be fixed in release branches is that Python put the 
> build-time linux major kernel version in sys.platform in the first place, 
> instead of making it just be "linux". If anyone had a time machine, the right 
> thing would be to go back in time and make Python never put the "2" there. 
> But, since they're hard to come by (rumors to the contrary aside...), the 
> best fix at this point is to retain consistency with earlier patch releases 
> and force it to remain "linux2" no matter what.
> 
> Again, the number provides literally *no* useful information. You can compile 
> Python on kernel version 2.x and then run it on a 3.x kernel (sys.platform 
> will be "linux2" in that case). You can also compile python on a 3.x kernel 
> and then run it on a 2.x kernel (sys.platform will be "linux3" in that case). 
> Other than the 2 vs 3 encoded into a bunch of places inside Python, the two 
> copies of python should be 100% identical.
> 
> So, there is also no need to provide this useless value under a different 
> variable name.
>
> BTW, all the above goes for everywhere Python uses "linux[23]" right now, 
> such as pathnames, not just literally the value of sys.platform.

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 ?

BTW: The new attribute should contain the complete version number,
not just the major version. `uname -r` would provide a good start.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Barry A. Warsaw]

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) simultaneously upgrade to a newer Python release, or
>c) work-around in their applications.
>
>I expect that most users chose a) for some time to come (until
>the Linux distributions ship the new kernels), and that the Linux
>distributions chose b) and c).

In fact, for Debian and Ubuntu, we had several breakages due to sys.platform
== 'linux3' so for all Pythons we still support, we're going to force it back
to 'linux2'.  This fixed all those broken packages without any of them needing
to be changed.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[James Y Knight]

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 included a value which is completely irrelevant on 
Linux, and has now changed.

The bug here that should be fixed in release branches is that Python put the 
build-time linux major kernel version in sys.platform in the first place, 
instead of making it just be "linux". If anyone had a time machine, the right 
thing would be to go back in time and make Python never put the "2" there. But, 
since they're hard to come by (rumors to the contrary aside...), the best fix 
at this point is to retain consistency with earlier patch releases and force it 
to remain "linux2" no matter what.

Again, the number provides literally *no* useful information. You can compile 
Python on kernel version 2.x and then run it on a 3.x kernel (sys.platform will 
be "linux2" in that case). You can also compile python on a 3.x kernel and then 
run it on a 2.x kernel (sys.platform will be "linux3" in that case). Other than 
the 2 vs 3 encoded into a bunch of places inside Python, the two copies of 
python should be 100% identical.

So, there is also no need to provide this useless value under a different 
variable name.

BTW, all the above goes for everywhere Python uses "linux[23]" right now, such 
as pathnames, not just literally the value of sys.platform.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12650] Subprocess leaks fd upon kill()

[Charles-François Natali]

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 and we're 
only interested in checking that the child is correctly added to the _active 
list, I've removed the part of test_zombie_fast_process_del which checked that 
the child got collected when the next Popen instance is allocated (I added this 
check in test_leak_fast_process_del_killed, which doesn't have this timeout 
problem because the process gets killed).
I'll watch the buildbots.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12650] Subprocess leaks fd upon kill()

[Roundup Robot]

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 'default':
Issue #12650: fix failures on some buildbots, when a subprocess takes a long
http://hg.python.org/cpython/rev/a32ae2749cd1

New changeset 5333ed548257 by Charles-François Natali in branch '2.7':
Issue #12650: fix failures on some buildbots, when a subprocess takes a long
http://hg.python.org/cpython/rev/5333ed548257

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12781] Mention SO_REUSEADDR near socket doc examples

[Sandro Tosi]

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
components: Documentation
files: socket_resueaddr.patch
keywords: patch
messages: 142403
nosy: docs@python, ezio.melotti, sandro.tosi
priority: normal
severity: normal
stage: patch review
status: open
title: Mention SO_REUSEADDR near socket doc examples
versions: Python 2.7, Python 3.2, Python 3.3
Added file: http://bugs.python.org/file22944/socket_resueaddr.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12650] Subprocess leaks fd upon kill()

[Charles-François Natali]

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 
3.x/builds/3528/steps/test/logs/stdio
"""
==
FAIL: test_zombie_fast_process_del (test.test_subprocess.POSIXProcessTestCase)
--
Traceback (most recent call last):
  File 
"/home2/buildbot2/slave/3.x.loewis-parallel/build/Lib/test/test_subprocess.py", 
line 1519, in test_zombie_fast_process_del
self.assertRaises(OSError, os.waitpid, pid, 0)
AssertionError: OSError not raised by waitpid
"""

I've no idea what's going on here...
This means that the child process didn't get reaped by _cleanup().
It could also maybe be due to the first child's PID being reused immediately by 
the second.

--
status: closed -> open

___
Python tracker 

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

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 - see the next bullet.

 * Porting to a new OS version is always an application level problem,
   not a programming language one; you cannot expect applications
   written for Linux 2.x to run without problems on 3.x - much like you
   cannot expect Python 2.x applications to run without problems
   on Python 3.x.

 * Removing the version number from the platform string should only
   be done in case a new variable gets introduced that provides the
   full version. Using the platform module would be possible, but
   can be expensive, so having this value as standard sys module
   variable is a better approach.

   Otherwise, removing the version is a good thing to do for
   Python 3.3 onwards.

 * The same change should be applied to *all* other platform strings,
   not only Linux, but the *BSDs and the others as well.

 * Application writers need to be made aware of the change, since
   sys.platform is not only used in Python programs, but also
   to build e.g. path names, file names, log ids, etc. etc.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Vinay Sajip]

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/.pyw files as scripts in the [resources] section, 
which would have the shebang line transmutation applied during installation.

Re. the unwanted attachments - sorry, I don't normally use HTML email - I need 
to change the settings I was using.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12765] test_packaging failure under Snow Leopard

[Ned Deily]

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 

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

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?
> 
> At the cost of some additional confusion, though.

As you can see, the compile-time nature of the current implementation
causes similar confusion (even to experienced users). With the proposed
solution, most people won't even notice that there is an issue, so they
won't be confused. When they migrate to 3.3, they notice the change, and
accept it as a new feature - and they notice the change regardless of
whether they run a 2.x or 3.x kernel.

With the alternative approach (linux3), people may continue to release
buggy applications for years and not even notice during testing as they
use a Python binary compiled on linux2.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12720] Expose linux extended filesystem attributes

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +neologix

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Oleg Oshmyan]

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

___
Python tracker 

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

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 (1996), Python didn't have the relevance
it has today. Most of the code referring to linux2 was probably written
after that date, and with the assumption that it may well be the final
major version Linux will ever get.

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5845] rlcompleter should be enabled automatically

[Antoine Pitrou]

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Matthew Schwickerath]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

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?

At the cost of some additional confusion, though.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5845] rlcompleter should be enabled automatically

[Antoine Pitrou]

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");
if (v == NULL)
PyErr_Clear();
else
Py_DECREF(v);
}


...meaning readline already gets imported automatically when desired. And 
indeed:

$ ./python -S
Python 3.3.0a0 (default:50f1922bc1d5, Aug 18 2011, 00:09:47) 
[GCC 4.5.2] on linux2
>>> import sys
>>> sys.modules['readline']



So perhaps we could simply change this code to import another, private module 
(e.g. "_setupinteractive.py") which would setup readline and rlcompleter?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12650] Subprocess leaks fd upon kill()

[Charles-François Natali]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

Antoine Pitrou  added the comment:

This patch does the trick.

--
keywords: +patch
Added file: http://bugs.python.org/file22942/jsonacc.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

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 to rewrite applications.

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.

Really, it's not difficult to understand that code testing for "linux2"
will stop working when "linux3" gets released. It's an obvious bug which
is also obvious to fix. Whether or not the Linux version numbering
scheme makes sense is a totally separate concern (which I agree may be
addressed by returning "linux" in 3.3).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12765] test_packaging failure under Snow Leopard

[Éric Araujo]

É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.TestDatabase.

--

___
Python tracker 

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

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 applications. They want the
code to continue to work *unmodified*.

The proposed mechanism achieves this for the bug fix releases.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12765] test_packaging failure under Snow Leopard

[Ned Deily]

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 0x1019f0610>
  After:  <_weakrefset.WeakSet object at 0x1019f05a0>

--
nosy: +ned.deily

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

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 fine on 2.7.

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

--

___
Python tracker 

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

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) Python 2 will
be gone, and so will be Linux 2. Linux 4 may be released.

If we continue with the current approach, we will have the same
problems again (as we already did when Linux 2 was released). If
we change to just "linux" now, it will have no effect when Linux 4
is released.

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) simultaneously upgrade to a newer Python release, or
c) work-around in their applications.

I expect that most users chose a) for some time to come (until
the Linux distributions ship the new kernels), and that the Linux
distributions chose b) and c).

> Well, except maybe if you plan to write applications working only on
> Python >= 2.7.3? ... this version is not released yet.

With Python 2.7.3, people don't have the change their applications at
all. They just have to wait for the Linux upgrade until Python 2.7.3
is released.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8668] Packaging: add a 'develop' command

[Éric Araujo]

É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
> 'install_editable' for it,
That can be useful.  On the other hand, pip uses subprocesses instead of 
calling Python functions, to make sure an error in the called code does not 
stop pip.  I still think it’s a nice function to have.  The name should be 
changed: “editable” is not used in our current terminology, so install_develop 
would be IMO better.

I also think that “pysetup install --develop path/to/project” would be a nice 
high-level way to use develop, in the future.

About supporting setup.py develop: I think too that it is not needed.  
Supporting setup.py install is a needed feature for *users*, as Alexis said; 
conversely, having a packaging-only develop feature can help seduce 
*developers* to use the new standards and tools.  My vote is for removing 
setup.py develop support.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[James Y Knight]

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 written* applications on Python<2.7.3 binaries that have 
already been built (and thus were built on a 2.x kernel and report linux2), on 
Python>=2.7.3 which will be fixed to continue reporting linux2, and on 
Python<2.7.3 which have had the same fix backported to them by distros, since 
Python upstream won't do it for earlier branches.

--

___
Python tracker 

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

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

I'd rather phrase this differently: Python 2.6 does not support Linux 3.
Tough luck, since Linux 3 was released long after Python 2.6.

--

___
Python tracker 

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

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 of major versions
(to indicate significant changes), and the systems you list follow this
practice. And then there are systems that break with that tradition, and
use the major version for marketing and other purposes, and Linux is one
of them.

--

___
Python tracker 

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

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 times, features get added to allow even buggy (or perceived-buggy)
applications to continue to work under a change.

> The applications that encountered the problem (chromium, matplotlib
> and probably others) already performed the change to
> sys.platform.startswith(), so it's really the only way to go.

I'm very certain that not all applications have been changed yet.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Éric Araujo]

Éric Araujo  added the comment:

Heh, I messed up my example:

unit2-tk = unittest2.gui.main gui

--

___
Python tracker 

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

[Éric Araujo]

Changes by Éric Araujo :


Added file: 
http://bugs.python.org/file22941/__file__-cant-contain-pyc-in-3.2.diff

___
Python tracker 

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

[Éric Araujo]

Changes by Éric Araujo :


Removed file: http://bugs.python.org/file22940/fix-11599.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Éric Araujo]

É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 other feature requests:

unit2 = unittest2.main.main
unit2-tk = unittest2.gui.main window
spamd = spamlib.daemon.main sbin

The first example is a regular script; the second one will use pythonw on 
Windows and Mac OS X; the third one would install to /usr/sbin instead of 
/usr/bin on POSIX.  What do you think?

> 'scripts' belongs to the 'files' section in setup.cfg, it's still ok
> now to place it in 'files'?
As I said in private email, I don’t think it’s a concern at all, but maybe 
other people disagree.  An alternate idea: using a new section:

[scripts]
sphinx-build = sphinx.build.main

You should ask on the fellowship ML.

About setup.cfg and setup.py.  In general, packaging totally ignores setup.py.  
However, one goal is to support generated setup.py that take all the info from 
the setup.cfg file, thanks to pysetup generate-setup.  In that case, there’s a 
compatibility question, as you said: what do we do with scripts as dotted 
paths?  It would be too much pain to use inspect.getsource to copy our 
functions that generate scripts into the setup.py file.  I think our 
documentation should just advise people to create an old-style script file and 
manually add it in their setup.py.

>> To support the old-style scripts generated by d*/s* in p*, we can use
>> the resource system.
> Not just as is, I believe. When scripts are installed (as opposed to
> other resources), it's not enough to copy them across to the
> configured destination: you also need to change their shebang lines
> to point to the appropriate Python executable.
That is true.  I see too possible solutions: tell people to use a hook, or have 
special handling for resources registered in the scripts category (IOW a 
built-in hook).  I prefer the second option.

> But how will we know which .py files mentioned in resources are data,
> and which are actually scripts?
Distutils scripts are not actually restricted to Python scripts.  The shebang 
updating only happens if a regex matches.  To answer your question: the 
resources system uses categories, one of which is “scripts”.

I’m -1 on using heuristics to handle both distutils-style files and 
packaging-style dotted paths (Vinay’s latest message).  It’s much cleaner to 
have separate fields or sections.

(BTW Vinay, remember that Roundup creates attachments when someone sends HTML 
email)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12765] test_packaging failure under Snow Leopard

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Bill is the owner of that buildbot.

--
nosy: +janssen

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Éric Araujo]

Changes by Éric Araujo :


Removed file: http://bugs.python.org/file22934/unnamed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Éric Araujo]

Changes by Éric Araujo :


Removed file: http://bugs.python.org/file22933/unnamed

___
Python tracker 

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

[Éric Araujo]

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
stage: commit review
status: open
title: Clean up tests for pyc/pyo in __file__
versions: Python 3.3
Added file: http://bugs.python.org/file22940/fix-11599.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Éric Araujo]

É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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12650] Subprocess leaks fd upon kill()

[Roundup Robot]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11599] Useless error message when distutils fails compiling

[Éric Araujo]

Changes by Éric Araujo :


Added file: http://bugs.python.org/file22938/fix-11599.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue11599] Useless error message when distutils fails compiling

[Éric Araujo]

Changes by Éric Araujo :


Removed file: http://bugs.python.org/file21316/fix-compile-error-messages.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12720] Expose linux extended filesystem attributes

[Benjamin Peterson]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5845] rlcompleter should be enabled automatically

[Éric Araujo]

É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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue5845] rlcompleter should be enabled automatically

[Éric Araujo]

Changes by Éric Araujo :


Removed file: http://bugs.python.org/file21399/fix-5845.diff

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12761] Typo in Doc/license.rst

[Sandro Tosi]

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 of the zlib
-sources if the zlib version found on the system is too old to be
-used for the build::
+The :mod:`zlib` extension is built using the zlib version found on the system,
+but an included copy of the zlib sources is shipped for the Windows build::
 
   Copyright (C) 1995-2011 Jean-loup Gailly and Mark Adler


because the embedded zlib is not used in the linux build (but always the system 
one, and if absent, no zlib module is built) while we have several references 
of Modules/zlib/ files in PC/VC* and PCbuild/*.vcproj (that I can't read); 
adding to nosy the windows expert to have their opinion.

--
nosy: +brian.curtin, tim.golden
resolution: fixed -> 
stage: committed/rejected -> patch review
status: closed -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Éric Araujo]

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12779] Update packaging documentation

[Éric Araujo]

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 report to prevent someone else from duplicating efforts.

--
assignee: eric.araujo
components: Distutils2, Documentation
messages: 142367
nosy: alexis, eric.araujo
priority: normal
severity: normal
status: open
title: Update packaging documentation
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12650] Subprocess leaks fd upon kill()

[Roundup Robot]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12779] Update packaging documentation

[Éric Araujo]

É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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Éric Araujo]

Éric Araujo  added the comment:

Thanks for the patch.  Is the function already tested or does someone need to 
add a test?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12765] test_packaging failure under Snow Leopard

[Éric Araujo]

É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 tedious and also make noise for 
python-checkins, but well.

--
components: +Distutils2, Macintosh -Library (Lib), Tests
nosy: +alexis

___
Python tracker 

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

[Marc-Andre Lemburg]

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 itself. For _Py_UNICODE_NEXT, you 
> can call it NEXT_CHARACTER().

Can we please stick to the things we discussed on issue10542.

The macros are intended to be public starting with 3.3, not private
and they are meant to be used outside the interpreter as well.
They will only be private for patch level release patches. For those
you don't need the Py-prefix, but it also doesn't hurt having it
there.

> _Py_UNICODE_ISHIGHSURROGATE,_Py_UNICODE_ISLOWSURROGATE and 
> _Py_UNICODE_JOIN_SURROGATES are only used once, I would prefer to see them 
> inlined in _Py_UNICODE_NEXT.
> 
> The first cast to Py_UCS4 in _Py_UNICODE_JOIN_SURROGATES is useless.
> 
> It looks like the macro can be simplified to something like:
> 
> #define _Py_UNICODE_NEXT(ptr, end)  \
> (_Py_UNICODE_ISHIGHSURROGATE(*(ptr)) && (ptr) < (end)) && 
> _Py_UNICODE_ISLOWSURROGATE((ptr)[1] ?   \
>  ((ptr) += 2,_Py_UNICODE_JOIN_SURROGATES((ptr)[-2], (ptr)[-1])) :  \
>  (Py_UCS4)*(ptr)++)
> 
> (you don't need two "a?b:c")
> 
> I would prefer to see _Py_UNICODE_NEXT as a function instead of a macro 
> because it has border effect (ptr++ or ptr += 2). You cannot write 
> Py_UNICODE_ISALNUM(_Py_UNICODE_NEXT(p, e)) for example, because 
> Py_UNICODE_ISALNUM is defined as:

> #define Py_UNICODE_ISALNUM(ch) (Py_UNICODE_ISALPHA(ch) || 
> Py_UNICODE_ISDECIMAL(ch) || Py_UNICODE_ISDIGIT(ch) || 
> Py_UNICODE_ISNUMERIC(ch))
> 
> And so _Py_UNICODE_NEXT is expanded 4 times. It is also horrible to debug a 
> program having such long macro. If you really want to keep it as a macro, 
> please add a least a big warning.

Having it as function would kill the performance advantage, so that's not
really an option. The use case you mention is also not really realistic.

Adding an extra warning to the macro version is still a good idea, though.

--

___
Python tracker 

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

[Antoine Pitrou]

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 for the comprehensive measurements. Indeed I think it doesn't
seem it is a problem in 2.7/3.2.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[poq]

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 iterator would need to maintain its 
own stack to keep track of where it is in the object tree it's encoding...

If there is interest though, I may be able to write a patch when I have some 
time off again...

--
nosy: +poq

___
Python tracker 

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

[Daniel Svensson]

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 

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

[Ezio Melotti]

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

___
Python tracker 

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

[Daniel Svensson]

Changes by Daniel Svensson :


--
versions:  -Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4

___
Python tracker 

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

[STINNER Victor]

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_UNICODE_ISHIGHSURROGATE,_Py_UNICODE_ISLOWSURROGATE and 
_Py_UNICODE_JOIN_SURROGATES are only used once, I would prefer to see them 
inlined in _Py_UNICODE_NEXT.

The first cast to Py_UCS4 in _Py_UNICODE_JOIN_SURROGATES is useless.

It looks like the macro can be simplified to something like:

#define _Py_UNICODE_NEXT(ptr, end)  \
(_Py_UNICODE_ISHIGHSURROGATE(*(ptr)) && (ptr) < (end)) && 
_Py_UNICODE_ISLOWSURROGATE((ptr)[1] ?   \
 ((ptr) += 2,_Py_UNICODE_JOIN_SURROGATES((ptr)[-2], (ptr)[-1])) :  \
 (Py_UCS4)*(ptr)++)

(you don't need two "a?b:c")

I would prefer to see _Py_UNICODE_NEXT as a function instead of a macro because 
it has border effect (ptr++ or ptr += 2). You cannot write 
Py_UNICODE_ISALNUM(_Py_UNICODE_NEXT(p, e)) for example, because 
Py_UNICODE_ISALNUM is defined as:

#define Py_UNICODE_ISALNUM(ch) (Py_UNICODE_ISALPHA(ch) || 
Py_UNICODE_ISDECIMAL(ch) || Py_UNICODE_ISDIGIT(ch) || Py_UNICODE_ISNUMERIC(ch))

And so _Py_UNICODE_NEXT is expanded 4 times. It is also horrible to debug a 
program having such long macro. If you really want to keep it as a macro, 
please add a least a big warning.

It's also confusing to have two attachments with the same name :-/

--
nosy: +haypo

___
Python tracker 

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

[Charles-François Natali]

Changes by Charles-François Natali :


--
nosy:  -neologix

___
Python tracker 

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

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" 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 exactly 
as the current state (sys.platform == 'linux3' on all Python versions): 
applications have to use sys.platform.startswith() to work correctly on any 
Linux version.

Well, except maybe if you plan to write applications working only on Python >= 
2.7.3? ... this version is not released yet.

--

___
Python tracker 

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

[Daniel Svensson]

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()
t1 = time.time()
parsed = json.loads(data)
t2 = time.time()
print("read file in %.2fs, parsed json in %.2fs, total of %.2fs" % 
(t1-t0, t2-t1, t2-t0))

if len(sys.argv) > 1 and sys.argv[1] == "nogc":
gc.disable()

read_json_blob()
print(gc.collect())

daniel@neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; 
python3.2 gc.py nogc
read file in 1.34s, parsed json in 2.74s, total of 4.07s
0
daniel@neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; 
python3.2 gc.py
read file in 1.33s, parsed json in 2.71s, total of 4.05s
0
daniel@neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; 
python2.6 gc.py
read file in 0.89s, parsed json in 56.03s, total of 56.92s
0
daniel@neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; 
python2.6 gc.py nogc
read file in 0.89s, parsed json in 56.38s, total of 57.27s
0
daniel@neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; 
python2.7 gc.py
read file in 0.89s, parsed json in 3.87s, total of 4.75s
0
daniel@neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; 
python2.7 gc.py nogc
read file in 0.89s, parsed json in 3.91s, total of 4.80s
0
daniel@aether:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.5 
gc.py
read file in 0.11s, parsed json in 53.00s, total of 53.11s
0
daniel@aether:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.5 
gc.py nogc
read file in 0.14s, parsed json in 53.13s, total of 53.28s
0

Everything is equally slow.. no weird things there, except that Python 3.2 
seems to take more time to load the file. Nice performance improvement of the 
json module in 3.2 compared to older Python versions.


Next up. Trying with cjson which decodes via a binary module:

import time, gc, cjson, sys

def read_json_blob():
t0 = time.time()
fd = open("datatest1.json")
data = fd.read()
fd.close()
t1 = time.time()
parsed = cjson.decode(data)
t2 = time.time()
print("read file in %.2fs, parsed json in %.2fs, total of %.2fs" % 
(t1-t0, t2-t1, t2-t0))

if len(sys.argv) > 1 and sys.argv[1] == "nogc":
gc.disable()

read_json_blob()
print(gc.collect())

daniel@neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; 
python2.6 gc.py
read file in 0.89s, parsed json in 2.58s, total of 3.46s
0
daniel@neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; 
python2.6 gc.py nogc
read file in 0.89s, parsed json in 1.44s, total of 2.33s
0
daniel@neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; 
python2.7 gc.py nogc
read file in 0.89s, parsed json in 1.53s, total of 2.42s
0
daniel@neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; 
python2.7 gc.py
read file in 0.89s, parsed json in 1.54s, total of 2.43s
0
daniel@neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; 
python2.6 gc.py nogc
read file in 0.89s, parsed json in 1.44s, total of 2.33s
0
daniel@neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; 
python2.6 gc.py
read file in 0.89s, parsed json in 2.58s, total of 3.47s
0
daniel@neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; 
python2.6 gc.py
read file in 0.89s, parsed json in 2.58s, total of 3.47s
0
daniel@neutronstar:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; 
python2.6 gc.py nogc
read file in 0.89s, parsed json in 1.43s, total of 2.32s
0
daniel@aether:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.5 
gc.py
read file in 0.14s, parsed json in 1.58s, total of 1.73s
0
daniel@aether:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.5 
gc.py nogc
read file in 0.16s, parsed json in 1.07s, total of 1.23s
0
daniel@aether:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.5 
gc.py
read file in 0.14s, parsed json in 1.58s, total of 1.72s
0
daniel@aether:~$ sudo bash -c "echo 3 > /proc/sys/vm/drop_caches"; python2.5 
gc.py nogc
read file in 0.14s, parsed json in 1.06s, total of 1.20s

The file is actually a bit too small for good measurement when using cjson, but 
interesting point here is obviously the huge difference between GC and no GC in 
Python 2.5, and quite a bit win in 2.6 too, which becomes a lot more apparent 
with larger files.

Another interesting thing is that Python 2.6 is consistently faster than 2.7 
when the GC is disabled in 2.6, compared to both enabled and disabled in 2.7. 
The cjson isn't compatible with Python 3.2 so I cannot verify how things work 
there.

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

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

[STINNER Victor]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

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 multiarch in newer Debian and Ubuntu releases -
> we just don't support that in security-only Pythons).
> 
> We can and should change Python 3.2 and 2.7 to only report 'linux2' for
> backward compatibility.

It means someone upgrading from 2.6 to 2.7 will see sys.platform change
from "linux3" to "linux2". That breaks compatibility.

> For Python 3.3, we should do the right thing, which IMO is to set sys.platform
> to 'linux' without the version number.  In parallel we can change the stdlib
> tests to use .startswith() and encourage third party developers to use
> .startswith() also.

The latter is already done in the documentation.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Barry A. Warsaw]

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.  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 multiarch in newer Debian and Ubuntu releases -
we just don't support that in security-only Pythons).

We can and should change Python 3.2 and 2.7 to only report 'linux2' for
backward compatibility.

For Python 3.3, we should do the right thing, which IMO is to set sys.platform
to 'linux' without the version number.  In parallel we can change the stdlib
tests to use .startswith() and encourage third party developers to use
.startswith() also.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12760] Add create mode to open()

[David Townshend]

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 'exclusive', as 
long it its clear in the python docs what it does, which I think it is. Having 
said that, I don't really have a strong opinion either way, so I'll happily 
change it back to 'c' if its preferred.

--
Added file: http://bugs.python.org/file22935/open_create_x-2.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8668] Packaging: add a 'develop' command

[Alexis Metaireau]

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 are currently packaged using 
setuptools features in their setup.py

 > I think the current implemention way of Packaging 'install' command 
just offers an executing router to run a proper 'install', which users 
doesn't need to know.

What packaging.install does is, if the project has been packaged using 
setuptools, relying on it to install the projects, while not letting it 
take care of the dependencies. Then, the .egginfo is converted to a 
.distinfo, so the way setuptools distributions are installed is *not* 
compatible with setuptools installation procedure.

It is important to note that setuptools will *not* be a dependency for 
packaging, but rather the end user will be prompted to install it if 
it's not present and he wants to install a setuptools based project (or 
if what he's trying to install relies on setuptools based projects).

The problem with the develop command seems different to my eyes: develop 
is used by developers, not by end users. Thus, proposing them to keep 
using the "old" setuptools develop command in packaging may seem like 
encouraging them to continue using setuptools.

Rather, I would prefer to say: "well, if you want to use setuptools' 
develop command, you can continue to do so, but the way to go would 
probably to repackage your project using shiny new standards". That's 
one of the handles we have to help the transition to packaging, so 
taking this occasion seems important to me.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ned Deily]

Changes by Ned Deily :


--
nosy: +bethard

___
Python tracker 

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

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Vinay Sajip]

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 
>support the old-style scripts generated by d*/s* in p*, we can use the 
>resource system.
>
>Not just as is, I believe. When scripts are installed (as opposed to other 
>resources), it's not enough to copy them across to the configured destination: 
>you also need to change their shebang lines to point to the appropriate Python 
>executable. This is particularly important in virtualenvs where there could be 
>any number of Python executables (of different versions) represented. But how 
>will we know which .py files mentioned in resources are data, and which are 
>actually scripts?

To me, it actually makes more sense to keep those scripts in the [scripts] 
section, and have some way of recognising which scripts need to be 
copied/amended and which ones need to be generated from callables.

--
Added file: http://bugs.python.org/file22934/unnamed

___
Python tracker 

___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 support the old-style scripts 
generated by d*/s* in p*, we can use the resource 
system.Not just as is, I believe. 
When scripts are installed (as opposed to other resources), it's not enough to 
copy them across to the configured destination: you also need to change their 
shebang lines to point to the appropriate Python executable. This is 
particularly important in virtualenvs where there could be any number of Python 
executables (of different versions) represented. But how will we know which .py 
files mentioned in resources are data, and which are actually 
scripts?To me, it actually makes more sense to keep those scripts in 
the [scripts] section, and have some way of recognising which scripts need to 
be copied/amended and which ones need to be generated from 
callables.___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12650] Subprocess leaks fd upon kill()

[Roundup Robot]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8668] Packaging: add a 'develop' command

[higery]

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 setup.py 
>>develop: I don't see any reason to make it avaible on the stdlib.

I think the current implemention way of Packaging 'install' command just offers 
an executing router to run a proper 'install', which users doesn't need to 
know. It also the same to 'develop'. BTW, I think it's ok if setuptools is 
already installed when a user try to run 'python setup.py develop', if not, 
python will report error. In addition, Packaging use a different way to issue 
commands - cd to the source directory, and use 'pysetup run develop' to do the 
job. Old setup.py will be supported only by issuing commands under the source 
directory containing the setup.py, and if setuptools exists, Packaging will 
dispatch the job to it.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Barry A. Warsaw]

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 latter
is dead too :).  I'm just suggesting one more special case for linux*

(see configure.in and search for MACHDEP)

--

___
Python tracker 

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

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
 * unixware
 * openunix
 * sco_sv
 * sunos
 * hp-ux

(Ok, some of them are dead and you cannot expect new major versions :-))

--

___
Python tracker 

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

[Daniel Svensson]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Barry A. Warsaw]

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.
>
>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.
>The applications that encountered the problem (chromium, matplotlib
>and probably others) already performed the change to
>sys.platform.startswith(), so it's really the only way to go.

I still think that sys.platform for the stable releases should never report
'linux3'.  Updating the various conditionals *probably* has low risk of
regression, but I think you have to check that very carefully.

>> BTW, does anybody think sys.platform should use a more dynamic approach for
>> calculating its value?  Well, maybe not necessary if Python 3.3 will just
>> say 'linux'.
>
>There's already platform.system() for that.

TOOWTDI

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Vinay Sajip]

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 get to know that Packaging has a more 
further and important consideration - setup.cfg and setup.py place different 
roles in a project, setup.py offers developers to set while setup.cfg offers 
users to edit in a cheap and easy way... Certainly you can set anyone of these 
two files to reach the same goal.
>
>I think I understand that much. The point of setup.cfg is to do away with the 
>completely ad-hoc nature of code that developers can put into setup.py, which 
>prevents playing nicely with distro package managers. I'm fairly sure I've 
>seen Tarek say that "for developers, no more setup.py" - in fact, I've just 
>found where he said it:

http://tarekziade.wordpress.com/2011/05/22/packaging-has-landed-in-the-stdlib/

and also

http://pycon.tv/#/video/57 (at around 6:55 into the video, and at 8:30 - "there 
is no more setup.py" - meaning in the new way of doing things)

So the role of setup.py is historical, and the way developers customise 
installations is through using hooks. These work well enough, and I am 
currently using them in the nemo project which is a companion to the pythonv 
branch - see http://www.red-dove.com/screencasts/pythonv/pythonv.html

--
Added file: http://bugs.python.org/file22933/unnamed

___
Python tracker 

___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 get to know that Packaging has a more 
further and important consideration - setup.cfg and setup.py place
 different roles in a project, setup.py offers developers to set while 
setup.cfg offers users to edit in a cheap and easy way... Certainly you can set 
anyone of these two files to reach the same 
goal.I think I understand that much. 
The point of setup.cfg is to do away with the completely ad-hoc nature of code 
that developers can put into setup.py, which prevents playing nicely with 
distro package managers. I'm fairly sure I've seen Tarek say that "for 
developers, no more setup.py" - in fact, I've just found where he said 
it:http://tarekziade.wordpress.com/2011/05/22/packaging-has-landed-in-the-stdlib/and alsohttp://pycon.tv/#/video/57 (at 
around 6:55
 into the video, and at 8:30 - "there is no more setup.py" - meaning in the new 
way of doing things)So the role of setup.py is 
historical, and the way developers customise installations is through using 
hooks. These work well enough, and I am currently using them in the nemo 
project which is a companion to the pythonv branch - see 
http://www.red-dove.com/screencasts/pythonv/pythonv.html___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8668] Packaging: add a 'develop' command

[Alexis Metaireau]

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

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8668] Packaging: add a 'develop' command

[higery]

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(setuptools' develop 
or packaging's develop) for the 'develop' command are unnecessary, we can just 
retain the new-style packaging's develop, which mean '_run_packaging_develop' 
function here.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12757] undefined name in doctest.py

[Michele Orrù]

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: 
shortDescription()
 Returns a description of the test, or None if no description has been   
 provided. The default implementation of this method returns the first 
 line of the test method’s docstring, if available, or None.
(i.e., DocTestCase._dt_test.name)

What's your opinion?

--
nosy: +maker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Antoine Pitrou]

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 (most recent call last):
  File "", line 1, in 
  File "/home/antoine/cpython/opt/Lib/json/__init__.py", line 224, in dumps
return _default_encoder.encode(obj)
  File "/home/antoine/cpython/opt/Lib/json/encoder.py", line 188, in encode
chunks = self.iterencode(o, _one_shot=True)
  File "/home/antoine/cpython/opt/Lib/json/encoder.py", line 246, in iterencode
return _iterencode(o, 0)
MemoryError
Command exited with non-zero status 1
11.25user 2.43system 0:13.72elapsed 99%CPU (0avgtext+0avgdata 
27820320maxresident)k
2920inputs+0outputs (12major+1261388minor)pagefaults 0swaps


I suppose the encoder internally builds a large list of very small unicode 
objects, and only joins them at the end. Probably we could join it by chunks so 
as to avoid this behaviour.

--
messages: 142338
nosy: ezio.melotti, pitrou, rhettinger
priority: normal
severity: normal
status: open
title: JSON-serializing a large container takes too much memory
type: resource usage
versions: Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12650] Subprocess leaks fd upon kill()

[Roundup Robot]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12777] Inconsistent use of VOLUME_NAME_* with GetFinalPathNameByHandle

[Antoine Pitrou]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue12760] Add create mode to open()

[STINNER Victor]

STINNER Victor  added the comment:

> I don't know if it's documented behavior

See #12103: it is not documented.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8668] Packaging: add a 'develop' command

[Alexis Metaireau]

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.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue8668] Packaging: add a 'develop' command

[Alexis Metaireau]

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 install level.

When installing old setuptools-based setup.py, the .egg-info should be gone, 
replaced by a shiny new .dist-info folder. I'm not sure why you're talking 
about it in the context of develop, can you clarify this?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com