[issue19078] Allow reversed(memoryview), like memoryview

[Raymond Hettinger]

Raymond Hettinger added the comment:

Claudiu's patch looks correct.

--
nosy: +rhettinger

___
Python tracker 

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

[issue19072] classmethod doesn't honour descriptor protocol of wrapped callable

[Raymond Hettinger]

Raymond Hettinger added the comment:

I'll take a look at this in more detail in the next week or so.

--

___
Python tracker 

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

[issue10042] functools.total_ordering fails to handle NotImplemented correctly

[Raymond Hettinger]

Raymond Hettinger added the comment:

One other thought:  The OrderedEnum example should not use the total ordering 
decorator.  

To the extent that the docs are trying to teach how to use Enum, they should 
focus on that task and not make a side-trip into the world of class decorators. 
  And to the extent that the docs are trying to show an example of production 
code, it would be better for speed and ease of tracing through a debugger to 
just define all four ordering comparisons.

--

___
Python tracker 

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

[issue19086] Make fsum usable incrementally.

[Raymond Hettinger]

Raymond Hettinger added the comment:

Conceptually, I support the idea of having some way to avoid information loss 
by returning uncollapsed partial sums.  As you say, it would provide an 
essential primitive for parallel fsums and for cumulative subtotals.

If something along those lines were to be accepted, it would likely take one of 
two forms:
   
fsum(iterable, detail=True) --> list_of_floats
fsum_detailed(iterable) --> list_of_floats

Note, there is no need for a "carry" argument because the previous result can 
simply be prepended to the new data (for a running total) or combined in a 
final summation at the end (for parallel computation):

detail = [0.0]
for group in groups:
detail = math.fsum_detailed(itertools.chain(detail, group))
print('Running total', math.fsum(detail))

On the negative side, I think the use case is too exotic and no one will care 
about or learn to use this function.  Also, it usually isn't wise to expose the 
internals (we may want a completely different implementation someday).  Lastly, 
I think there is some virtue in keeping the API simple; otherwise, math.fsum() 
may ward-off some its potential users, resulting in even lower adoption than we 
have now.

With respect to the concerns about speed, I'm curious whether you've run your 
msum() edits under pypy or cython.  I would expect both to give excellent 
performance.

--

___
Python tracker 

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

[issue10042] functools.total_ordering fails to handle NotImplemented correctly

[Raymond Hettinger]

Raymond Hettinger added the comment:

Nick, the latest version of the patch looks like a correct solution.

Before applying, please add a block comment showing why these shenanigans are 
necessary (i.e. the use self.__lt__ instead of the less-than operator because 
the former doesn't fall into recursive operator flipping).

Also, please add a note to the docs indicating 1) that NotImplemented is now 
supported as of version 3.4 and 2) that when speed matters, it is always better 
to code all four ordering operators by hand rather than paying the cost of 
total_ordering's layers of indirection.

--
assignee: rhettinger -> ncoghlan

___
Python tracker 

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

[issue18594] C accelerator for collections.Counter is slow

[Raymond Hettinger]

Raymond Hettinger added the comment:

A C-accelerator should ALWAYS be able to beat a pure python version if it does 
the same steps but without the overhead of the eval-loop.  And in special cases 
such as type(self)==Counter, it can do much better.

To resolve this report, the C accelerator needs to be fixed.  As Stefan 
pointed-out, the fast-path isn't being triggered because of PyDict_CheckExact 
test.  And, the fallback path can be sped-up as well (by doing the same steps 
in C as are being done with the pure python code).

--
stage:  -> needs patch
versions: +Python 3.3

___
Python tracker 

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

[issue19017] selectors: towards uniform EBADF handling

[Guido van Rossum]

Guido van Rossum added the comment:

Charles-Francois, sorry to add you back to the bug, but (a) I thought you had 
agreed to a compromise patch that restarts signals in most cases but not for 
select(), poll() etc.; (b) I may have found a flaw in the idea.

The flaw (if it is one) is related to Py_AddPendingCall(). This "schedules" a 
pending callback, mostly for signals, but doesn't AFAICT interrupt the 
mainthread in any way. (TBH, I only understand the code for Python 2.7, and in 
that version I'm sure it doesn't.)

So is this a flaw? I'm nor sure. Can you think about it?

--

___
Python tracker 

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

[issue19072] classmethod doesn't honour descriptor protocol of wrapped callable

[Graham Dumpleton]

Graham Dumpleton added the comment:

The classmethod __get__() method does:

static PyObject *
cm_descr_get(PyObject *self, PyObject *obj, PyObject *type)
{
classmethod *cm = (classmethod *)self;

if (cm->cm_callable == NULL) {
PyErr_SetString(PyExc_RuntimeError,
"uninitialized classmethod object");
return NULL;
}
if (type == NULL)
type = (PyObject *)(Py_TYPE(obj));
return PyMethod_New(cm->cm_callable,
type, (PyObject *)(Py_TYPE(type)));
}

So it isn't intentionally calling __call__(). If it still doing binding, but 
doing it by calling PyMethod_New() rather than using __get__() on the wrapped 
function. Where it wraps a regular function the result is same as if __get__() 
was called as __get__() for a regular function internally calls PyMethod_New() 
in the same way.

static PyObject *
func_descr_get(PyObject *func, PyObject *obj, PyObject *type)
{
if (obj == Py_None)
obj = NULL;
return PyMethod_New(func, obj, type);
}

By not using __get__(), you deny the ability to have chained decorators that 
want/need the knowledge of the fact that binding was being done. The result for 
stacking multiple decorators which use regular functions (closures) is exactly 
the same, but you open up other possibilities of smarter decorators.

--

___
Python tracker 

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

[issue18594] C accelerator for collections.Counter is slow

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee:  -> rhettinger
priority: high -> normal

___
Python tracker 

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

[issue19119] duplicate test name in Lib/test/test_heapq.py

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee:  -> rhettinger

___
Python tracker 

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

[issue19072] classmethod doesn't honour descriptor protocol of wrapped callable

[Raymond Hettinger]

Raymond Hettinger added the comment:

I don't think it was ever intended that decorators be chained together.  

The whole point is to control binding behavior during dotted look-up (when 
__getattribute__ is called) and not in other circumstances (such as a direct 
lookup in a class dictionary).

Note that classmethods typically wrap regular functions which have both 
__call__ and __get__ methods.   The classmethod object intentionally invokes 
the former instead of the latter which would unhelpfully create an inner bound 
or unbound method.

--

___
Python tracker 

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

[issue19072] classmethod doesn't honour descriptor protocol of wrapped callable

[Raymond Hettinger]

Changes by Raymond Hettinger :


--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue19087] bytearray front-slicing not optimized

[STINNER Victor]

STINNER Victor added the comment:

Oh, by the way:

> $ ./python -m timeit  "b = bytearray(); a = b'x'"  "for i in range(1): b 
> += a"  "bytes(b)"

I'm not sure that it is what you expected: bytearray() is only initialized once 
("setup" of timeit). You probably want to reinitialize at each loop.

--

___
Python tracker 

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

[issue19087] bytearray front-slicing not optimized

[STINNER Victor]

STINNER Victor added the comment:

> One of most used cases for bytearrays is accumulating. And the patch slow 
> down this case.

Please don't use the raw timeit command for micro-benchmarks, it is not 
reliable. For example, I'm unable to reproduce your "slow down" (7% on a 
microbenchmark is not that large).

My micro-benchmark using my benchmark.py script:

Common platform:
Python version: 2.7.3 (default, Aug 9 2012, 17:23:57) [GCC 4.7.1 20120720 (Red 
Hat 4.7.1-5)]
Python unicode implementation: UCS-4
CPU model: Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz
Timer: time.time
Platform: Linux-3.9.4-200.fc18.x86_64-x86_64-with-fedora-18-Spherical_Cow
Timer precision: 954 ns
CFLAGS: -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic 
-D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic 
-D_GNU_SOURCE -fPIC -fwrapv
Bits: int=32, long=64, long long=64, size_t=64, void*=64

Platform of campaign original:
SCM: hg revision=687dd81cee3b tag=tip branch=default date="2013-09-29 22:18 
+0200"
Date: 2013-09-30 00:59:42

Platform of campaign patched:
SCM: hg revision=687dd81cee3b+ tag=tip branch=default date="2013-09-29 22:18 
+0200"
Date: 2013-09-30 00:59:07

+-+
Tests   |original | patched
+-+
10**1 bytes |  859 ns (*) |  864 ns
10**3 bytes | 55.8 us (*) | 56.4 us
10**5 bytes | 5.42 ms | 5.41 ms (*)
10**7 bytes |  578 ms |  563 ms (*)
+-+
Total   |  583 ms |  569 ms (*)
+-+

So performances are the same with the patch.

--
Added file: http://bugs.python.org/file31916/bench_bytearray.py

___
Python tracker 

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

[issue19087] bytearray front-slicing not optimized

[Antoine Pitrou]

Antoine Pitrou added the comment:

> One of most used cases for bytearrays is accumulating.
> And the patch slow down this case.

I see no difference here. You are seeing a 10% slowdown, which is possibly a 
measurement glitch. The bottom line is that the performance remains 
approximately the same.

> It offer better performances for "free" only for suboptimal code
> which currently have O(N) instead of O(1).

The problem is the "suboptimal code" is also the natural way to write such 
code. If you know a simple and idiomatic way to write an optimal bytes FIFO, 
then please share it with us. Otherwise, I will happily ignore your line of 
argument here.

--

___
Python tracker 

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

[issue19104] pprint produces invalid output for long strings

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

I doubt we are able to fix it in maintained releases.

--

___
Python tracker 

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

[issue19104] pprint produces invalid output for long strings

[Antoine Pitrou]

Antoine Pitrou added the comment:

> The whole point of pprint() is formatted output of containers such as
> list or dict.

Well, the whole point of pprint is pretty-printing. Being restricted to
containers is a bug, not a feature...

--

___
Python tracker 

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

[issue19104] pprint produces invalid output for long strings

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The whole point of pprint() is formatted output of containers such as list or 
dict. Before 3.4 it does not wrap long strings at all.

Of course I don't think this alternative is good. But at least it is better 
than producing illegal output.

--

___
Python tracker 

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

[issue19087] bytearray front-slicing not optimized

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> Is there a problem with that?

No more than with msg198657.

> Sorry, I don't get your point. It's not become Python is inefficient that 
> developers must develop workarounds.

I'm not sure that "workarounds" are much worst than using this optimization. At 
least we still not seen real code which will benefit from this optimization.

> Antoine's patch is simple, elegant, and offer better performances for "free".

It offer better performances for "free" only for suboptimal code which 
currently have O(N) instead of O(1).

One of most used cases for bytearrays is accumulating. And the patch slow down 
this case.

$ ./python -m timeit  "b = bytearray(); a = b'x'"  "for i in range(1): b += 
a"  "bytes(b)"

Without patch: 4.3 msec per loop
With patch: 4.62 msec per loops

--

___
Python tracker 

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

[issue16079] list duplicate test names with patchcheck

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue19087] bytearray front-slicing not optimized

[Antoine Pitrou]

Antoine Pitrou added the comment:

> > No, because PyByteArray_Resize() is always called afterwards to ensure
> > that the buffer is resized when it gets below 50% usage.
> 
> I.e. the bytearray is compacted from time to time.

Is there a problem with that?

--

___
Python tracker 

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

[issue19087] bytearray front-slicing not optimized

[STINNER Victor]

STINNER Victor added the comment:

@Serhiy: "I doubt than any performance critical code do it instead of 
increasing an index in constant time."

Sorry, I don't get your point. It's not become Python is inefficient that 
developers must develop workarounds. Antoine's patch is simple, elegant, and 
offer better performances for "free".

--

___
Python tracker 

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

[issue17326] Windows build docs still referring to VS 2008 in 3.3

[Berker Peksag]

Changes by Berker Peksag :


--
resolution:  -> duplicate
stage:  -> committed/rejected
status: open -> closed
superseder:  -> PCbuild/readme.txt not up-to-date

___
Python tracker 

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

[issue19087] bytearray front-slicing not optimized

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> No, because PyByteArray_Resize() is always called afterwards to ensure
> that the buffer is resized when it gets below 50% usage.
>

I.e. the bytearray is compacted from time to time.

--

___
Python tracker 

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

[issue19087] bytearray front-slicing not optimized

[Antoine Pitrou]

Antoine Pitrou added the comment:

> You increase internal index in a bytearray. A bytearray with small
> visible length can consume much hidden memory.

No, because PyByteArray_Resize() is always called afterwards to ensure
that the buffer is resized when it gets below 50% usage.

--

___
Python tracker 

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

[issue19087] bytearray front-slicing not optimized

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

You increase internal index in a bytearray. A bytearray with small visible 
length can consume much hidden memory.

--

___
Python tracker 

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

[issue19087] bytearray front-slicing not optimized

[Antoine Pitrou]

Antoine Pitrou added the comment:

> The same is true with your patch.

I don't understand. What is "true with my patch"?

--

___
Python tracker 

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

[issue19087] bytearray front-slicing not optimized

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

The same is true with your patch.

--

___
Python tracker 

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

[issue19087] bytearray front-slicing not optimized

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Deleting a slice at the front of a bytearray have linear complexity
> from the size of a bytearray (in any case del b[:1] is a little faster
> than b[:1] = b''). I doubt than any performance critical code do it
> instead of increasing an index in constant time.

Increasing an index requires that you compact the bytearray from time to
time, lest it fills the whole memory.

--

___
Python tracker 

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

[issue19087] bytearray front-slicing not optimized

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Deleting a slice at the front of a bytearray have linear complexity from the 
size of a bytearray (in any case del b[:1] is a little faster than b[:1] = 
b''). I doubt than any performance critical code do it instead of increasing an 
index in constant time.

--

___
Python tracker 

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

[issue19087] bytearray front-slicing not optimized

[Antoine Pitrou]

Antoine Pitrou added the comment:

> Could you please show concrete code in which you are going to use this 
> optimization?

There's no need to "use" this optimization. Any networking code that has to 
find message boundaries and split on them will benefit. If you don't understand 
that, I'm not willing to explain it for you.

--

___
Python tracker 

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

[issue19087] bytearray front-slicing not optimized

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> A generic example is to parse messages out of a TCP stream. Basically
any protocol transported on TCP needs such a facility, or has to find
workarounds (which are either suboptimal or complicated).

Could you please show concrete code in which you are going to use this 
optimization?

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://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:

> The patch fixes the problem on my setup. A very minor glitch: after
> manually emptying or removing the PYTHONSTARTUP history file, the
> history is loaded with the content of ~/.python_history on the next
> session.

Yes, the only way to know if a history file has already been loaded with
readline seems to be to query the history itself. So, if the history is
empty, we consider no file has been loaded.

--

___
Python tracker 

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

[issue19087] bytearray front-slicing not optimized

[Antoine Pitrou]

Antoine Pitrou added the comment:

Results under Windows:

- before:

PCbuild\amd64\python.exe -m timeit "b=bytearray(10)" "while b: b[-1:] = b''"
10 loops, best of 3: 74.8 msec per loop

PCbuild\amd64\python.exe -m timeit "b=bytearray(10)" "while b: b[:1] = b''"
10 loops, best of 3: 330 msec per loop

- after:

PCbuild\amd64\python.exe -m timeit "b=bytearray(10)" "while b: b[-1:] = b''"
10 loops, best of 3: 73.9 msec per loop

PCbuild\amd64\python.exe -m timeit "b=bytearray(10)" "while b: b[:1] = b''"
10 loops, best of 3: 73.8 msec per loop

--

___
Python tracker 

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

[issue16041] poplib: unlimited readline() from connection

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

Looks good, although only the POP3 exception is actually tested.  The POP3_SSL 
exception isn't tested.  Any chance you could add a test for that (obviously, 
only if `import ssl` succeeds)?

--

___
Python tracker 

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

[issue12641] Remove -mno-cygwin from distutils

[Antoine Pitrou]

Antoine Pitrou added the comment:

Oscar, thanks for the patches. Two things:
- in the 2.7 patch, could you explicitly close the popen() file object instead 
of relying on deallocation to do it?
- have you signed a contributor's agreement? http://www.python.org/psf/contrib/

--
nosy: +pitrou

___
Python tracker 

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

[issue18314] Have os.unlink remove junction points

[Tim Golden]

Tim Golden added the comment:

I'll try to pick this one up over the next few days. Feel free to ping me if it 
drops into silence!

--
assignee:  -> tim.golden

___
Python tracker 

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

[issue5845] rlcompleter should be enabled automatically

[Xavier de Gaye]

Xavier de Gaye added the comment:

The patch fixes the problem on my setup. A very minor glitch: after
manually emptying or removing the PYTHONSTARTUP history file, the
history is loaded with the content of ~/.python_history on the next
session.

--

___
Python tracker 

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

[issue18314] Have os.unlink remove junction points

[Kim Gräsman]

Kim Gräsman added the comment:

Attached is a patch that considers directory symlinks and junction points 
equivalent.

I'm struggling with the test -- would it be acceptable to only run this test on 
platforms that have mklink /j (Windows Vista and higher)?

I've looked at programmatic means of creating junction points, but it involves 
enough Win32 interop to make it a candidate for a module all by itself (it's 
REALLY messy.)

Any ideas?

Thanks!

--
keywords: +patch
Added file: http://bugs.python.org/file31915/unlink_junction.patch

___
Python tracker 

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

[issue19103] Use pprint in displayhook

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

> (in the patch, import of sys and pprint should be done once at module level 
> and not repeated with every line of interactive output).

See a comment at the start of the Lib/_sitebuiltins.py file. Yes, importing sys 
in the function is redundant.

> For instance, try list(range(40)) with the two options.

Well, I have opened issue19132 for this.

> This is not to mention doctest and other test breakage.

AFAIK doctests doesn't test output longer than 80 characters.

> I believe the majority consensus on python-ideas was to reject this until 
> pprint is much improved, and then reconsider.

There are other pprint-related issue which are opened long time without any 
progress (e.g. issue7434). I intend making progress on issues which are 
required for fixing pprint enough to be reasonable replacement for displayhook.

--
dependencies: +Add compact mode to pprint

___
Python tracker 

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

[issue5845] rlcompleter should be enabled automatically

[Roundup Robot]

Roundup Robot added the comment:

New changeset 687dd81cee3b by Antoine Pitrou in branch 'default':
Issue #5845: In site.py, only load readline history from ~/.python_history if 
no history has been read already.  This avoids double writes to the history 
file at shutdown.
http://hg.python.org/cpython/rev/687dd81cee3b

--

___
Python tracker 

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

[issue19066] os.execv fails with spaced names on Windows

[Terry J. Reedy]

Terry J. Reedy added the comment:

Reminder: you are not supposed to re-open issues.

I agree with Richard that this is a duplicate as submitted. The difference is 
that we now have subprocess; that is our fix for several problems. I will 
re-close unless you make a *specific* suggestion for a doc change.

--

___
Python tracker 

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

[issue19132] Add compact mode to pprint

[Antoine Pitrou]

Antoine Pitrou added the comment:

I think it looks good on the principle.

--
nosy: +pitrou

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://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:

Attaching patch to only load history file if no history exists.

--
keywords:  -needs review
resolution:  -> fixed
Added file: http://bugs.python.org/file31914/rl_history_guard.patch

___
Python tracker 

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

[issue19132] Add compact mode to pprint

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

pprint produces not very nice output for collections with a large number of 
short elements (see msg198556). For example pprint.pprint(list(range(40))) 
outputs more than 40 short lines, while print(repr(list(range(40 takes only 
2 lines on 80-column terminal.

I propose to add new boolean option "compact". With compact=True pprint will 
try combine as much short one-line subelements in one line as possible. Every 
multiline element will be printed on separated lines.

Examples:

>>> pprint.pprint(list(range(40)), width=50, compact=True)
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13,
 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25,
 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37,
 38, 39]
>>> pprint.pprint(['one string', 'other string', 'very very long string which 
>>> continued on several lines', 'and again', 'and again', 'and again', 'and 
>>> again'], width=50, compact=True)
['one string', 'other string',
 'very very long string which is continued on '
 'several lines',
 'and again', 'and again', 'and again',
 'and again']

--
components: Library (Lib)
messages: 198641
nosy: serhiy.storchaka
priority: normal
severity: normal
stage: needs patch
status: open
title: Add compact mode to pprint
type: enhancement
versions: Python 3.4

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://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:

> When a user is not aware of this new feature and has been implementing
> up to now her/his PYTHONSTARTUP file with the first example given in
> python 3.3 documentation at
> 
> http://docs.python.org/3/library/readline.html?highlight=readline#example
> 
> then each new interactive python 3.4 session reads (appending them)
> both history files which are saved on exit. Thus those files double
> their size after each interactive python 3.4 session and pretty soon
> become few mega bytes long with a python start up time that becomes
> quite noticeable.

Interesting. A way to avoid doing this would be to only load history if
no history is already present. Since the sys.__interactivehook__ is
executed after PYTHONSTARTUP, this would allow the latter to take
precedence.

--

___
Python tracker 

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

[issue16041] poplib: unlimited readline() from connection

[Jyrki Pulliainen]

Jyrki Pulliainen added the comment:

Attached a patch for 2.6. 

Due to how tests are in 2.6, this adds one more test case with evil server, 
which basically just returns too long lines.

--
Added file: http://bugs.python.org/file31913/issue16041_py26.patch

___
Python tracker 

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

[issue19124] os.execv executes in background on Windows

[Richard Oudkerk]

Richard Oudkerk added the comment:

> Visual Studio 10+ ? Is it available somewhere for a reference?

Old versions of the relevant files are here:

http://www.controllogics.com/software/VB6/VC98/CRT/SRC/EXECVE.C
http://www.controllogics.com/software/VB6/VC98/CRT/SRC/SPAWNVE.C
http://www.controllogics.com/software/VB6/VC98/CRT/SRC/DOSPAWN.C

--

___
Python tracker 

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

[issue19066] os.execv fails with spaced names on Windows

[Richard Oudkerk]

Changes by Richard Oudkerk :


--
nosy:  -sbt

___
Python tracker 

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

[issue19124] os.execv executes in background on Windows

[Richard Oudkerk]

Changes by Richard Oudkerk :


--
nosy:  -sbt

___
Python tracker 

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

[issue19066] os.execv fails with spaced names on Windows

[Richard Oudkerk]

Richard Oudkerk added the comment:

> Hey. This ticket is about os.execv failing on spaced paths on Windows. It 
> is not a duplicate of issue19124.

It is a duplicate of #436259 "[Windows] exec*/spawn* problem with spaces in 
args".

--

___
Python tracker 

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

[issue5845] rlcompleter should be enabled automatically

[Xavier de Gaye]

Xavier de Gaye added the comment:

There is a backward compatibility issue with changeset d5ef330bac50
that enables tab-completion in the interactive interpreter by default.

When a user is not aware of this new feature and has been implementing
up to now her/his PYTHONSTARTUP file with the first example given in
python 3.3 documentation at

http://docs.python.org/3/library/readline.html?highlight=readline#example

then each new interactive python 3.4 session reads (appending them)
both history files which are saved on exit. Thus those files double
their size after each interactive python 3.4 session and pretty soon
become few mega bytes long with a python start up time that becomes
quite noticeable.

--
nosy: +xdegaye

___
Python tracker 

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

[issue19119] duplicate test name in Lib/test/test_heapq.py

[Tim Peters]

Tim Peters added the comment:

Good catch!  Would like to hear from Raymond what the intent of these tests was 
- looks like "the real" test_get_only (which hasn't been executing) has 
multiple failures.

--
nosy: +tim.peters

___
Python tracker 

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

[issue18919] Unify audio modules tests

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file31912/makeaudiotests.py

___
Python tracker 

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

[issue18857] urlencode of a None value uses the string 'None'

[Joshua Johnston]

Joshua Johnston added the comment:

I still believe that since None represents the absence of a value it should not 
be urlencoded as the string 'None'. I am not sure what they best way to url 
encode it is, but I know that 'None' is not it.

--
status: closed -> open

___
Python tracker 

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

[issue18919] Unify audio modules tests

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Patch updated. Now files created in external program (Audacity) are used for 
testing. This exposed yet one bug, in the aifc module (issue19131).

--
dependencies: +Broken support of compressed AIFC files
Added file: http://bugs.python.org/file31911/audiotests_2.patch

___
Python tracker 

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

[issue18857] urlencode of a None value uses the string 'None'

[Joshua Johnston]

Joshua Johnston added the comment:

Hi Senthil,
You can open the html file with a browser and inspect the data posting to 
itself without a web server running. That is how I tested.

--

___
Python tracker 

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

[issue19131] Broken support of compressed AIFC files

[Serhiy Storchaka]

New submission from Serhiy Storchaka:

In u-law and A-law compressed AIFC files the sampleSize field is equal to 8 
(bits). The aifc module transparently compress/uncompress audio data to 16-bit, 
but doesn't support the samplewidth parameter in consistency. This causes two 
bugs:

1. On read getsampwidth() returns 1, but should return 2 (bytes per sample in 
uncompressed audio data). readframes() returns twice less data than expected.

>>> import aifc
>>> f = aifc.open('pluck-ulaw.aifc', 'r')
>>> f.getparams()
_aifc_params(nchannels=2, sampwidth=1, framerate=11025, nframes=3307, 
comptype=b'ulaw', compname=b'')
>>> f.readframes(1)
b',\x02'

f.readframes(1) should return 4 bytes (2 channels, 16-bit uncompressed data).

2. On write wrong value 2 is saved in the sampleSize field. Resulting file is 
invalid and can't be read in other programs.

Here is a patch and sample file. For tests see issue18919.

I'm sure G722 support is broken too, but I have no any testing files.

--
components: Library (Lib)
files: aifc_sampwidth.patch
keywords: patch
messages: 198631
nosy: r.david.murray, serhiy.storchaka
priority: normal
severity: normal
stage: patch review
status: open
title: Broken support of compressed AIFC files
type: behavior
versions: Python 2.7, Python 3.3, Python 3.4
Added file: http://bugs.python.org/file31909/aifc_sampwidth.patch

___
Python tracker 

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

[issue19131] Broken support of compressed AIFC files

[Serhiy Storchaka]

Changes by Serhiy Storchaka :


Added file: http://bugs.python.org/file31910/pluck-ulaw.aifc

___
Python tracker 

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

[issue19123] duplicate test name in Lib/test/test_regrtest.py

[Roundup Robot]

Roundup Robot added the comment:

New changeset 280d403434c4 by Benjamin Peterson in branch 'default':
rename some more tests to avoid duplicate names (#19123)
http://hg.python.org/cpython/rev/280d403434c4

--

___
Python tracker 

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

[issue19123] duplicate test name in Lib/test/test_regrtest.py

[Xavier de Gaye]

Xavier de Gaye added the comment:

After the last changeset 39f9adc8ad5b there are still 3 methods named
test_findleaks. The proposed patch was also missing one of them.

--

___
Python tracker 

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

[issue19124] os.execv executes in background on Windows

[anatoly techtonik]

Changes by anatoly techtonik :


--
resolution: rejected -> 
status: closed -> open

___
Python tracker 

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

[issue16037] httplib: header parsing is unlimited

[Arfrever Frehtes Taifersar Arahesis]

Changes by Arfrever Frehtes Taifersar Arahesis :


--
title: httplib: header parsing is not unlimited -> httplib: header parsing is 
unlimited

___
Python tracker 

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

[issue19124] os.execv executes in background on Windows

[anatoly techtonik]

anatoly techtonik added the comment:

I can't use subprocess. These are official "business suite" scripts for Android 
development from Google.

--

___
Python tracker 

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

[issue19124] os.execv executes in background on Windows

[anatoly techtonik]

anatoly techtonik added the comment:

On Sun, Sep 29, 2013 at 8:53 PM, Richard Oudkerk  wrote:
>
> Richard Oudkerk added the comment:
>
>> Where did you get that info? MSDN is silent about that.
>> http://msdn.microsoft.com/en-us/library/886kc0as(v=vs.90).aspx
>
> Reading the source code for the C runtime included with Visual Studio.

Visual Studio 10+ ? Is it available somewhere for a reference?

>> The problem is not in what I should or should not use. The problem
>> that existing scripts that work on Unix and use os.execv() to launch
>> interactive scripts, on Windows behave absolutely weird and unusable
>> behavior. I previously experienced this with SCons, but couldn't get
>> the reason. Now I experience this with basic Android development tools
>> and dug down to this. It is clearly a big mess from this side of
>> Windows.
>
> As said before (more than once), os.exec*() is useless on Windows: just use 
> subprocess.

I value your expert opinion, but to increase the bus factor, I can not
leave it without asking for reasons.

Have you tried to run examples provided by MSDN - do they exhibit the
same behavior as Python script I attached earlier and described in the
first message?

--

___
Python tracker 

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

[issue19066] os.execv fails with spaced names on Windows

[anatoly techtonik]

anatoly techtonik added the comment:

On Sun, Sep 29, 2013 at 8:48 PM, Richard Oudkerk  wrote:
>
>> Don't we have such function already? I don't see the problem in
>> quoting the string.
>
> No one seems to know how to write such a quoting function.

Why escape quotes with slash and surrounding in quotes doesn't help?
http://msdn.microsoft.com/en-us/library/ms235416(v=vs.90).aspx
How does Linux and subprocess on Windows survive then?
If I am not mistaken both subprocess and execv on Windows use
CreateProcess. Does subprocess fail as well?

>> Does it start child process in foreground or in background? Did you
>> compile examples on
>> http://msdn.microsoft.com/en-us/library/431x4c1w.aspx page with new
>> VC++ to check? I don't possess the VC++ 10, so I can't do this myself.
>> And I believe that compiling with GCC may lead to different results.
>
> There is no such thing as a background task in Windows.  A process is either 
> attached to a console, or it isn't.  When you use execv() to start a process, 
> it inherits the parent's console.

All right. Then why does it start to interfere with running cmd.exe
(in issue19124)? If it inherits console, it should continue to "own"
it exclusively, and not return it back to parent cmd.exe

> On Unix try replacing os.execv(...) by
>
> os.spawnv(os.P_NOWAIT, ...)
> os._exit(0)
>
> and you will probably get the same behaviour where the shell and the child 
> process both behave as conflicting foreground tasks.

Maybe Python code doesn't use _execv() at all on Windows and uses
these spawnv's?

> ..
>
>> I don't mind if it runs child process with different pid, but why it
>> runs new process in background. Unix version doesn't do this.
>
> The point is that the shell waits for its child process to finish by using 
> waitpid() (or something similar) on the child's pid.  If the child uses 
> execv() then the child is replaced by a grandchild process with the same pid. 
>  From the point of view of the shell, the child and the grandchild are the 
> same process, and waitpid() will not stop until the grandchild terminates.

I can not accept your point when you don't know for sure how cmd.exe
waits for child process to exit. Are you sure that it doesn't use some
blocking CreateProcess call? Are you sure that Python on Windows calls
exactly _execv and not some spawn surrogate?

> This issue should be closed: just use subprocess instead.

We need some quorum on this. I'd like to hear two more people that can
confirm and agree with your position. I don't want to think that
usability of execv() on Windows can not be improved, because people
who love Linux doesn't think that this OS deserves some care. I'd like
to run Python scripts with the same base behaviour regardless of
platform. If that's impossible, that should be documented.

--

___
Python tracker 

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

[issue19066] os.execv fails with spaced names on Windows

[anatoly techtonik]

anatoly techtonik added the comment:

Hey. This ticket is about os.execv failing on spaced paths on Windows. It is 
not a duplicate of issue19124.

--
resolution: duplicate -> 
status: closed -> open

___
Python tracker 

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

[issue19128] duplicate test name in Mac/Tools/Doc/setup.py

[Ned Deily]

Changes by Ned Deily :


--
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type: behavior -> 

___
Python tracker 

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

[issue19128] duplicate test name in Mac/Tools/Doc/setup.py

[Roundup Robot]

Roundup Robot added the comment:

New changeset c865187aa14d by Ned Deily in branch 'default':
Issue #19128: Remove nonfunctional, unused Mac help indexing tool from repo.
http://hg.python.org/cpython/rev/c865187aa14d

--
nosy: +python-dev

___
Python tracker 

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

[issue19092] ExitStack.__exit__ incorrectly suppresses exceptions in __exit__ callbacks of inner context managers

[Hrvoje Nikšić]

Hrvoje Nikšić added the comment:

Indeed, that works, thanks. Here is the updated patch for review, passing all 
tests.

--
Added file: http://bugs.python.org/file31908/exitstack.diff

___
Python tracker 

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

[issue18674] Store weak references in modules_by_index

[Brett Cannon]

Brett Cannon added the comment:

Fine by me.

--

___
Python tracker 

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

[issue16037] httplib: header parsing is not unlimited

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

Thanks!

--
versions:  -Python 2.6

___
Python tracker 

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

[issue16037] httplib: header parsing is not unlimited

[Roundup Robot]

Roundup Robot added the comment:

New changeset 582e5072ff89 by Barry Warsaw in branch '2.6':
- Issue #16037: HTTPMessage.readheaders() raises an HTTPException when more
http://hg.python.org/cpython/rev/582e5072ff89

--

___
Python tracker 

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

[issue16037] httplib: header parsing is not unlimited

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

I'm just going to go ahead and commit this patch to 2.6 with the change I 
mentioned.  Does anything else need to be done for 2.6?

--

___
Python tracker 

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

[issue16037] httplib: header parsing is not unlimited

[Jyrki Pulliainen]

Jyrki Pulliainen added the comment:

I'm fine with not introducing a new exception for 2.6 (or any other version for 
that matter), so go for it :)

--

___
Python tracker 

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

[issue19095] Document SSLSocket.getpeercert always returns None without do_handshake

[Antoine Pitrou]

Antoine Pitrou added the comment:

Change committed in 3.4. Thanks for reporting!

--
resolution:  -> fixed
stage: needs patch -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue19124] os.execv executes in background on Windows

[Richard Oudkerk]

Richard Oudkerk added the comment:

> Where did you get that info? MSDN is silent about that.
> http://msdn.microsoft.com/en-us/library/886kc0as(v=vs.90).aspx

Reading the source code for the C runtime included with Visual Studio.

> The problem is not in what I should or should not use. The problem
> that existing scripts that work on Unix and use os.execv() to launch
> interactive scripts, on Windows behave absolutely weird and unusable
> behavior. I previously experienced this with SCons, but couldn't get
> the reason. Now I experience this with basic Android development tools
> and dug down to this. It is clearly a big mess from this side of
> Windows.

As said before (more than once), os.exec*() is useless on Windows: just use 
subprocess.

--
resolution:  -> rejected
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue19095] Document SSLSocket.getpeercert always returns None without do_handshake

[Roundup Robot]

Roundup Robot added the comment:

New changeset ddcdf7f7eac8 by Antoine Pitrou in branch 'default':
Issue #19095: SSLSocket.getpeercert() now raises ValueError when the SSL 
handshake hasn't been done.
http://hg.python.org/cpython/rev/ddcdf7f7eac8

--
nosy: +python-dev

___
Python tracker 

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

[issue19066] os.execv fails with spaced names on Windows

[Richard Oudkerk]

Richard Oudkerk added the comment:

> It is said that execv() is deprecated, but it is not said that it is
> alias of _execv(). It is only said that _execv() is C++ compliant.
> http://msdn.microsoft.com/en-us/library/ms235416(v=vs.90).aspx

Microsoft seems to have decided that all functions in the C runtime which don't 
begin with an underscore, and are not included in the ANSI C standard should be 
deprecated.  This includes all the fd functions like read(), write(), open(), 
close(), ...  There is no difference in behaviour between these and the 
underscore versions.

...

> Don't we have such function already? I don't see the problem in
> quoting the string.

No one seems to know how to write such a quoting function.

...

> Does it start child process in foreground or in background? Did you
> compile examples on
> http://msdn.microsoft.com/en-us/library/431x4c1w.aspx page with new
> VC++ to check? I don't possess the VC++ 10, so I can't do this myself.
> And I believe that compiling with GCC may lead to different results.

There is no such thing as a background task in Windows.  A process is either 
attached to a console, or it isn't.  When you use execv() to start a process, 
it inherits the parent's console.

On Unix try replacing os.execv(...) by

os.spawnv(os.P_NOWAIT, ...)
os._exit(0)

and you will probably get the same behaviour where the shell and the child 
process both behave as conflicting foreground tasks.

..

> I don't mind if it runs child process with different pid, but why it
> runs new process in background. Unix version doesn't do this.

The point is that the shell waits for its child process to finish by using 
waitpid() (or something similar) on the child's pid.  If the child uses execv() 
then the child is replaced by a grandchild process with the same pid.  From the 
point of view of the shell, the child and the grandchild are the same process, 
and waitpid() will not stop until the grandchild terminates.

This issue should be closed: just use subprocess instead.

--
resolution:  -> duplicate
stage: test needed -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue19124] os.execv executes in background on Windows

[anatoly techtonik]

anatoly techtonik added the comment:

On Sun, Sep 29, 2013 at 6:39 PM, Richard Oudkerk  wrote:
>
> Richard Oudkerk added the comment:
>
> As I wrote in http://bugs.python.org/issue19066, on Windows execv() is 
> equivalent to
>
> os.spawnv(os.P_NOWAIT, ...)
> os._exit(0)

Where did you get that info? MSDN is silent about that.
http://msdn.microsoft.com/en-us/library/886kc0as(v=vs.90).aspx

> This means that control is returned to cmd when the child process *starts* 
> (and afterwards you have cmd and the child connected to the same console).
>
> On Unix control is returned to the shell only once the child process *ends*.

That was my conclusion also.

> Although it might be less memory efficient, you would actually get something 
> closer to Unix behaviour by replacing os.execv(...) with
>
> sts = os.spawnv(os.P_WAIT, ...)
> _exit(sts)
>
> or
>
> sts = subprocess.call(...)
> _exit(sts)
>
> This is why I said that execv() is useless on Windows and that you should 
> just use subprocess instead.

The problem is not in what I should or should not use. The problem
that existing scripts that work on Unix and use os.execv() to launch
interactive scripts, on Windows behave absolutely weird and unusable
behavior. I previously experienced this with SCons, but couldn't get
the reason. Now I experience this with basic Android development tools
and dug down to this. It is clearly a big mess from this side of
Windows.

--

___
Python tracker 

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

[issue19095] Document SSLSocket.getpeercert always returns None without do_handshake

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
assignee: docs@python -> 
components: +Library (Lib) -Documentation
stage:  -> needs patch
type: enhancement -> behavior
versions: +Python 3.4

___
Python tracker 

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

[issue19078] Allow reversed(memoryview), like memoryview

[Antoine Pitrou]

Antoine Pitrou added the comment:

Stefan, what do you think about Claudiu's patch? Should a test be added to 
test_buffer as well?

--

___
Python tracker 

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

[issue18674] Store weak references in modules_by_index

[Antoine Pitrou]

Antoine Pitrou added the comment:

I think the "new new module initialization scheme", if it takes steam, is much 
more promising to solve the underlying issue. I'm inclined to close this entry 
as "won't fix", what do you think?

--

___
Python tracker 

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

[issue10241] gc fixes for module m_copy attribute

[Antoine Pitrou]

Antoine Pitrou added the comment:

I'm closing this issue as fixed though I'm not entirely sure the fix is right. 
The alpha cycle will allow us to get feedback on potential incompatibilities 
with third-party software.

--
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue16037] httplib: header parsing is not unlimited

[Barry A. Warsaw]

Barry A. Warsaw added the comment:

As we discussed in other issues regarding the similar problem, I don't really 
want to introduce a new exception in a point release of 2.6.  Is there any 
reason not to just raise HTTPException with the error message text?  Code that 
has to work across multiple 2.6.X versions won't be able to import the new 
exception, and thus cannot rely on it anyway.

If you agree, I'll make that change when I apply this patch.

--

___
Python tracker 

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

[issue19130] PCbuild/readme.txt not up-to-date

[Zachary Ware]

Zachary Ware added the comment:

Issue17326 can now be closed as a duplicate of this issue.

--
nosy: +zach.ware

___
Python tracker 

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

[issue19130] PCbuild/readme.txt not up-to-date

[Roundup Robot]

Roundup Robot added the comment:

New changeset b602edf9b100 by Christian Heimes in branch '3.3':
Issue #19130: mention historic VS 2008 build dir, too
http://hg.python.org/cpython/rev/b602edf9b100

New changeset a16b83ff7fb1 by Christian Heimes in branch 'default':
Issue #19130: mention historic VS 2008 build dir, too
http://hg.python.org/cpython/rev/a16b83ff7fb1

--

___
Python tracker 

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

[issue19066] os.execv fails with spaced names on Windows

[anatoly techtonik]

anatoly techtonik added the comment:

On Sun, Sep 29, 2013 at 3:03 PM, Richard Oudkerk  wrote:
>
> _spawn*() and _exec*() are implemented by the C runtime library.  spawn*() 
> and execv() are (deprecated) aliases.

It is said that execv() is deprecated, but it is not said that it is
alias of _execv(). It is only said that _execv() is C++ compliant.
http://msdn.microsoft.com/en-us/library/ms235416(v=vs.90).aspx

> The the first message is about someone's attempt to work around the problems 
> with embedded spaces and double quotes by writing a function to escape each 
> argument.  He says he had a partial success.

Don't we have such function already? I don't see the problem in
quoting the string.

> Surely this is basic reading comprehension?

I am mentally crippled. Sorry about that.

>> > Note that on Windows exec*() is useless: it just starts a subprocess and
>> > exits the current process.  You can use subprocess to get the same effect.
>>
>> Are you describing Windows implementation of _exec()
>> http://msdn.microsoft.com/en-us/library/431x4c1w.aspx or current
>> Python implementation?
>
> The Windows implementaion of _exec().

Does it start child process in foreground or in background? Did you
compile examples on
http://msdn.microsoft.com/en-us/library/431x4c1w.aspx page with new
VC++ to check? I don't possess the VC++ 10, so I can't do this myself.
And I believe that compiling with GCC may lead to different results.

>> > Just use subprocess instead which gets this stuff right.
>>
>> subprocess doesn't replace os.exec*, see issue19060
>
> On Unix subprocess does not replace os.exec*().  That is because on Unix 
> exec*() replaces the current process with a new process with the *same pid*.  
> subprocess cannot do this.
>
> But on Windows os.exec*() just starts an independent process with a 
> *different pid* and exits the current process.  The line
>
> os.execv(path, args)
>
> is equivalent to
>
> os.spawnv(os.P_NOWAIT, path, args)
> os._exit(0)

I don't mind if it runs child process with different pid, but why it
runs new process in background. Unix version doesn't do this.

--

___
Python tracker 

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

[issue19130] PCbuild/readme.txt not up-to-date

[Roundup Robot]

Roundup Robot added the comment:

New changeset 69bb4bf24b07 by Christian Heimes in branch '3.3':
Issue #19130: Correct PCbuild/readme.txt, Python 3.3 and 3.4 require VS 2010
http://hg.python.org/cpython/rev/69bb4bf24b07

New changeset f5a7090e16b7 by Christian Heimes in branch 'default':
Issue #19130: Correct PCbuild/readme.txt, Python 3.3 and 3.4 require VS 2010
http://hg.python.org/cpython/rev/f5a7090e16b7

--
nosy: +python-dev

___
Python tracker 

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

[issue19130] PCbuild/readme.txt not up-to-date

[Tim Golden]

Tim Golden added the comment:

Nope. Looks like a mistake. Confusingly, the header refers to VC++ 10.0 
which is VS 2010 (I think). AFAICT a global s/2008/2010/ would be the 
thing to do.

--

___
Python tracker 

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

[issue19130] PCbuild/readme.txt not up-to-date

[Christian Heimes]

Christian Heimes added the comment:

It also mentions VS 10.0 which is 2010 ... I'm fixing it now.

--
nosy: +christian.heimes

___
Python tracker 

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

[issue19130] PCbuild/readme.txt not up-to-date

[Antoine Pitrou]

New submission from Antoine Pitrou:

PCbuild/readme.txt mentions VS2008 while VS2010 is required to build 3.4. Am I 
missing something?

--
assignee: docs@python
components: Documentation
messages: 198602
nosy: brian.curtin, docs@python, loewis, pitrou, tim.golden
priority: normal
severity: normal
status: open
title: PCbuild/readme.txt not up-to-date
type: behavior
versions: Python 3.4

___
Python tracker 

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

[issue19112] tests of _TestProcess are not run by the multiprocessing test suite

[Roundup Robot]

Roundup Robot added the comment:

New changeset a3dd2ccdccf6 by Richard Oudkerk in branch '2.7':
Issue #19112: avoid using function defined in method.
http://hg.python.org/cpython/rev/a3dd2ccdccf6

New changeset 74752bfa6357 by Richard Oudkerk in branch '3.3':
Issue #19112: avoid using function defined in method.
http://hg.python.org/cpython/rev/74752bfa6357

--

___
Python tracker 

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

[issue19129] 6.2.1. Regular Expression Syntax flags

[Jason Smestad]

New submission from Jason Smestad:

In the Python 3.3.2 documentation in the section "6.2.1. Regular Expression 
Syntax" subsection "(?aiLmsux)" it describes flags that are set by extention 
notation. 6 of the flags are described in detail with links for each flag, but 
the "u" flag is not described or linked to in this subsection. 

When reading this subsection, you may be confused as to what the "u" flag is 
for, or if it even belongs there, since there is no link. I suggest that a link 
be added in that subsection to the re.A section in 6.2.2, and that re.U be 
added as a title for the re.A subsection in 6.2.2.

--
assignee: docs@python
components: Documentation
messages: 198600
nosy: docs@python, endoalir
priority: normal
severity: normal
status: open
title: 6.2.1. Regular Expression Syntax flags
versions: Python 3.3

___
Python tracker 

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

[issue19124] os.execv executes in background on Windows

[Richard Oudkerk]

Richard Oudkerk added the comment:

As I wrote in http://bugs.python.org/issue19066, on Windows execv() is 
equivalent to

os.spawnv(os.P_NOWAIT, ...)
os._exit(0)

This means that control is returned to cmd when the child process *starts* (and 
afterwards you have cmd and the child connected to the same console).

On Unix control is returned to the shell only once the child process *ends*.

Although it might be less memory efficient, you would actually get something 
closer to Unix behaviour by replacing os.execv(...) with

sts = os.spawnv(os.P_WAIT, ...)
_exit(sts)

or

sts = subprocess.call(...)
_exit(sts)

This is why I said that execv() is useless on Windows and that you should just 
use subprocess instead.

--
nosy: +sbt

___
Python tracker 

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

[issue19111] 2to3 should remove from future_builtins import *

[Peter]

Peter added the comment:

Thinking about this, perhaps the bug is that Python 3 doesn't have a 
future_builtins module? Consider:


$ python2.6
Python 2.6.8 (unknown, Sep 28 2013, 12:09:28) 
[GCC 4.6.3] on linux3
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import with_statement
>>> from __future__ import print_function
>>> from future_builtins import map, zip
>>> quit()


versus:


$ python3.3
Python 3.3.2 (default, Sep 28 2013, 12:00:20) 
[GCC 4.6.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from __future__ import with_statement
>>> from __future__ import print_function
>>> from future_builtins import map, zip
Traceback (most recent call last):
  File "", line 1, in 
ImportError: No module named 'future_builtins'
>>> quit()


The expectation from the __future__ imports is that once a feature is part of 
Python, the import is a harmless no-op. You could expect the same from  
future_builtins as well.

--

___
Python tracker 

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

[issue19127] duplicate test name in Lib/xml/dom/minidom.py

[Roundup Robot]

Roundup Robot added the comment:

New changeset b76e1b58ed45 by Benjamin Peterson in branch '3.3':
remove duplicate method (closes #19127)
http://hg.python.org/cpython/rev/b76e1b58ed45

New changeset 792006307d6d by Benjamin Peterson in branch '2.7':
remove duplicate method (closes #19127)
http://hg.python.org/cpython/rev/792006307d6d

New changeset 815780593826 by Benjamin Peterson in branch 'default':
merge 3.3 (#19127)
http://hg.python.org/cpython/rev/815780593826

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue19114] duplicate test names in Lib/distutils/tests/test_cmd.py

[Roundup Robot]

Roundup Robot added the comment:

New changeset 9d4d9e945f29 by Benjamin Peterson in branch '3.3':
condense two tests with the same name (closes #19114)
http://hg.python.org/cpython/rev/9d4d9e945f29

New changeset 61ae31665ee1 by Benjamin Peterson in branch '2.7':
condense two tests with the same name (closes #19114)
http://hg.python.org/cpython/rev/61ae31665ee1

New changeset 0a5ce192ba8a by Benjamin Peterson in branch 'default':
merge 3.3 (#19114)
http://hg.python.org/cpython/rev/0a5ce192ba8a

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue19112] tests of _TestProcess are not run by the multiprocessing test suite

[Roundup Robot]

Roundup Robot added the comment:

New changeset 414ccf20d182 by Benjamin Peterson in branch '3.3':
move helper function into its test method (closes #19112)
http://hg.python.org/cpython/rev/414ccf20d182

New changeset 959e894dc794 by Benjamin Peterson in branch '2.7':
move helper function into its test method (closes #19112)
http://hg.python.org/cpython/rev/959e894dc794

New changeset ea54a55a21a1 by Benjamin Peterson in branch 'default':
merge 3.3 (#19112)
http://hg.python.org/cpython/rev/ea54a55a21a1

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue19116] duplicate test names in Lib/test/test_complex.py

[Roundup Robot]

Roundup Robot added the comment:

New changeset cddb3e1e5054 by Benjamin Peterson in branch '3.3':
combine two tests to avoid duplicate names (closes #19116)
http://hg.python.org/cpython/rev/cddb3e1e5054

New changeset d87ef944ddcc by Benjamin Peterson in branch 'default':
merge 3.3 (#19116)
http://hg.python.org/cpython/rev/d87ef944ddcc

--
nosy: +python-dev
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed

___
Python tracker 

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