[issue13122] Out of date links in the sidebar of the documentation index of versions 3.1 and 3.2

[Georg Brandl]

Georg Brandl  added the comment:

Nobody said 3.2 was not stable...

--

___
Python tracker 

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

[issue13060] allow other rounding modes in round()

[Mark Dickinson]

Mark Dickinson  added the comment:

I'm warming to this idea.

We already have several round-to-integer functions (but not 
round-to-an-arbitrary-number-of-decimal-places) available in the math module 
(under the names floor, ceil and trunc).  This *does* seem to be a common need, 
and it's easy to get roll-your-own implementations wrong (e.g., check what the 
implementation in msg145140 does for negative numbers).  I suspect that once we 
get more people shifting to py3k we're going to get more complaints about round 
doing round-half-to-even.

Rather than expanding the signature of round, it might be worth considering a 
new math-module function (with name to be determined) that does round-half-up 
for floats.  We might later extend it to other types in the same way as is 
currently done for floor and ceil (with __floor__ and __ceil__ magic methods);  
introduction of such magic methods would probably require a PEP though.

At issue: *which* round-half-up function do we want?  The one that rounds 
halfway cases away from zero (what Wikipedia calls "Round half away from 
zero"), or the one that rounds halfway cases towards +infinity?  I'm inclined 
towards the former.  I don't think it's worth implementing both.

I guess we should follow floor / ceil's lead of returning integer output for 
float input in the case where number of places to round to isn't given (though 
personally I would have been happier if floor / ceil had continued to return 
float output for float input, as in Python 2.x).

--

___
Python tracker 

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

[issue10517] test_concurrent_futures crashes with "--with-pydebug" on RHEL5 with "Fatal Python error: Invalid thread state for this thread"

[Charles-François Natali]

Charles-François Natali  added the comment:

Hello,

> Did anyone test this fix for case of fork() being called from Python sub 
> interpreter?
>

Not specifically, unless it's part of the test suite.
Anyway, unless this problem is systematic - which I doubt - it
probably wouldn't have helped.

> Getting a report of fork() failing in sub interpreters under mod_wsgi that 
> may be caused by this change. Still investigating.
>
> Specifically throwing up error:
>
>  Couldn't create autoTLSkey mapping
>

Hmmm.
If you can, try strace or instrument the code (perror() should be
enough) to see why it's failing.
pthread_setspecific() can fail with:
- EINVAL, if the TLS key is invalid (which would be strange since we
call pthread_key_delete()/pthread_key_create() just before)
- or ENOMEM, if you run out of memory/address space

The later seems much more likely (e.g. if many child processes and
subinterpreters are created).
BTW, if this is a bug report from someone else, tell him to post here,
it'll be easier.
And we don't byte :-)

--

___
Python tracker 

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

[issue10141] SocketCan support

[Charles-François Natali]

Charles-François Natali  added the comment:

Working fine on the buildbots and Vinay's box, closing!

--
resolution:  -> fixed
stage: needs patch -> 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

[issue13131] FD leak in urllib2

[Valery Khamenya]

New submission from Valery Khamenya :

Explanation from dablitz's comment at https://bugs.pypy.org/issue867 :


urllib2 in the stdlib leaks fd's if an exception is raised while opening a 
connection. The issue occurs due to a socket being opened then an exception 
being raised before an object with the socket is returned, leaving no way to 
explicitly close the object. On cpython this would not be an issue as the 
object would lose all references almost immediately however it lingers around 
with a proper GC causing FD's to build up if the same condition happens 
repeatedly (eg a loop/web crawling)

The file enclosed is a script to generate the leakage, to run invok it as 
follows  leak.py

pypy should start leaking FD's and can be see in /proc//fd



Related issues:
http://bugs.python.org/issue3066
http://bugs.python.org/issue1208304
http://bugs.python.org/issue1601399

--
components: IO, Library (Lib)
files: leak.py
messages: 145166
nosy: Valery.Khamenya
priority: normal
severity: normal
status: open
title: FD leak in urllib2
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file23344/leak.py

___
Python tracker 

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

[issue8087] Unupdated source file in traceback

[Diego Mascialino]

Diego Mascialino  added the comment:

On Fri, Oct 7, 2011 at 5:25 PM, Ezio Melotti  wrote:
>
> Ezio Melotti  added the comment:
>
> I'm not sure this is useful to have.  If you changed your code you know that 
> you have to reload, so why would you want a warning that tells you that you 
> changed the code?

The source line showed in the traceback could not be the same line
executed.

Take a look to this example:

k.py:
def f():
a,b,c = 1,2

Traceback (most recent call last):
  File "", line 1, in 
  File "k.py", line 2, in f
a,b,c = 1,2
ValueError: need more than 2 values to unpack

k.py:
def f():
# blah
a,b = 1,2

Traceback (most recent call last):
  File "", line 1, in 
  File "k.py", line 2, in f
# blah
ValueError: need more than 2 values to unpack

> For some reason I always had the opposite problem (i.e. after a reload the 
> traceback was still showing the original code, and not the new one), while 
> IIUC you are saying that it shows the new code even if the module is not 
> reloaded.
> I tried your code and indeed it does what you say, so either I am mistaken 
> and I've been misreading the tracebacks, or this changed from 2.6 to 2.7, or 
> in some cases even the behavior (I think) I observed might happen.
> I'll have to verify this next time it happens.

That is strange, I think Python does not save the original code in any place.

--

___
Python tracker 

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

[issue8087] Unupdated source file in traceback

[Ezio Melotti]

Ezio Melotti  added the comment:

> The source line showed in the traceback could not be the same line executed.

My point is that when I see an error and modify the source to fix it, then I 
know that I'll have to reload.  If for some reason I forget to reload, I'll get 
the wrong line in the traceback and then reload, but I don't think that ever 
happened to me.
So to me, your warning will only be useful in the case where I modified the 
source, forgot to reload and got the same error again with a wrong line 
displayed.  Also note that reloading is not so common; usually you just restart 
your application and that will give you the right traceback.

Also I'm not sure the warning you proposed is the best way to handle this.

--

___
Python tracker 

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

[issue13131] FD leak in urllib2

[Valery Khamenya]

Valery Khamenya  added the comment:

by the way, timeout parameter should be set to 0.2 as for my 13Mbit ADSL line. 
With 0.002 it is not reproducible for my environment

--

___
Python tracker 

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

[issue11812] transient socket failure to connect to 'localhost'

[Charles-François Natali]

Charles-François Natali  added the comment:

> Attached patch reads the name of the server socket instead of using
> HOST or 'localhost'.

> By the way, why do we use 'localhost' instead of '127.0.0.1' for
> support.HOST? '127.0.0.1' doesn't depend on the DNS configuration of
> the host (especially its "hosts" file, even Windows has such file).

This might be a good idea.
Apparently, Windows 7 doesn't use its hosts file (yes, it does have one) to 
resolve 'localhost', but its DNS resolver, see 
http://serverfault.com/questions/4689/windows-7-localhost-name-resolution-is-handled-within-dns-itself-why

Depending on the DNS setup, it could lead to a latency which might explain such 
failures.

> Seems a clear race condition.

The code looks correct: a threading.Event is set by the server once it called 
listen(), point at which incoming connections should be queued (SYN/ACK is sent 
before accept()).
So I'd bet either on resolution delay (on Unix /etc/nsswitch.conf), or an 
overloaded machine.

--
nosy: +neologix

___
Python tracker 

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

[issue13132] distutils sends non-RFC compliant HTTP request

[Mitchell Hashimoto]

New submission from Mitchell Hashimoto :

In ``Lib/distutils/command/register.py`` as well as ``upload.py``, the 
following code exists to build the HTTP request body to send to the cheese shop 
server:

body.write('\nContent-Disposition: form-data; name="%s"'%key)
body.write("\n\n")

RFC2616 page 31 (http://tools.ietf.org/html/rfc2616#page-31) states that 
headers must be separated by CRLF. Specifically, the above "\n\n" for the 
header separator is causing issues with some minimal RFC-compliant web servers.

--
assignee: tarek
components: Distutils
messages: 145171
nosy: eric.araujo, mitchellh, tarek
priority: normal
severity: normal
status: open
title: distutils sends non-RFC compliant HTTP request
versions: Python 2.6, 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

[issue13132] distutils sends non-RFC compliant HTTP request

[Mitchell Hashimoto]

Mitchell Hashimoto  added the comment:

Patch attached.

--
keywords: +patch
Added file: http://bugs.python.org/file23345/issue13132.patch

___
Python tracker 

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

[issue8087] Unupdated source file in traceback

[Diego Mascialino]

Diego Mascialino  added the comment:

> So to me, your warning will only be useful in the case where I modified the 
> source, forgot to reload and got the same error again with a wrong line 
> displayed. Also note that reloading is not so common; usually you just 
> restart your application and that will give you the right traceback.

I know the case when this happens is really unsusual, but the
interperter could be able to alert you than that line of the traceback
is wrong.

> Also I'm not sure the warning you proposed is the best way to handle this.

I agree that, another approach is to save a copy of the source file
associated to the compiled code (like a .pys).

--

___
Python tracker 

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

[issue12192] Doc that collection mutation methods return item or None

[Mike Hoy]

Mike Hoy  added the comment:

Created a patch based on suggestions here.

--
keywords: +patch
Added file: http://bugs.python.org/file23346/return-none.diff

___
Python tracker 

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

[issue13130] test_gdb: attempt to dereference a generic pointer

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Following patch seems to fix it:

diff --git a/Tools/gdb/libpython.py b/Tools/gdb/libpython.py
--- a/Tools/gdb/libpython.py
+++ b/Tools/gdb/libpython.py
@@ -1152,7 +1152,7 @@ class PyUnicodeObjectPtr(PyObjectPtr):
 field_str = field_str.cast(_type_unsigned_char_ptr)
 elif repr_kind == 2:
 field_str = field_str.cast(_type_unsigned_short_ptr)
-elif repr_kind == 3:
+elif repr_kind == 4:
 field_str = field_str.cast(_type_unsigned_int_ptr)
 else:
 # Python 3.2 and earlier

--
nosy: +pitrou

___
Python tracker 

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

[issue12192] Doc that collection mutation methods return item or None

[Roundup Robot]

Roundup Robot  added the comment:

New changeset 352d075839f7 by Georg Brandl in branch 'default':
Closes #12192: Document that mutating list methods do not return the instance 
(original patch by Mike Hoy).
http://hg.python.org/cpython/rev/352d075839f7

--
nosy: +python-dev
resolution:  -> fixed
stage: needs patch -> 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

[issue13130] test_gdb: attempt to dereference a generic pointer

[Roundup Robot]

Roundup Robot  added the comment:

New changeset ef1f0434c79c by Antoine Pitrou in branch 'default':
Fix test_gdb following the small unicode struct change in c25262e97304 (issue 
#13130)
http://hg.python.org/cpython/rev/ef1f0434c79c

--
nosy: +python-dev

___
Python tracker 

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

[issue13130] test_gdb: attempt to dereference a generic pointer

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Let's wait for the buildbots.

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

___
Python tracker 

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

[issue13112] backreferences in comprehensions

[yoch]

yoch  added the comment:

Okay, thanks ;)

--

___
Python tracker 

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

[issue13130] test_gdb: attempt to dereference a generic pointer

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Seems to have cleared the buildbot failures.

--
status: pending -> closed

___
Python tracker 

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

[issue13125] test_all_project_files() expected failure

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Could you arrange to silence stdout/stderr in non-verbose mode?

$ ./python -m test -uall test_lib2to3
[1/1] test_lib2to3
ParseError on file /home/antoine/cpython/default/Lib/lib2to3/main.py bad input: 
type=22, value='=', context=('', (81, 38))
ParseError on file 
/home/antoine/cpython/default/Lib/lib2to3/tests/pytree_idempotency.py bad 
input: type=22, value='=', context=('', (47, 33))
--- /home/antoine/cpython/default/Lib/lib2to3/tests/data/bom.py 2011-08-01 
15:24:54.045209157 +0200
+++ @   2011-10-08 20:31:41.981242859 +0200
@@ -1,2 +1,2 @@
-# coding: utf-8
+# coding: utf-8
 print "BOM BOOM!"
1 test OK.

--
nosy: +pitrou

___
Python tracker 

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

[issue13133] FD leaks in ZipFile.read(), ZipFile.extract() and also using explicit arc_member.close()

[Valery Khamenya]

New submission from Valery Khamenya :

The attached file reproduces 3 types of FD leaks and leads to the error like:

IOError: [Errno 24] Too many open files: '/tmp/1019'

For example if executed with pypy.

--
components: IO, Library (Lib)
files: zipfiletest.py
messages: 145182
nosy: Valery.Khamenya
priority: normal
severity: normal
status: open
title: FD leaks in ZipFile.read(), ZipFile.extract() and also using explicit 
arc_member.close()
type: resource usage
versions: Python 2.7
Added file: http://bugs.python.org/file23347/zipfiletest.py

___
Python tracker 

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

[issue13131] FD leak in urllib2

[Valery Khamenya]

Valery Khamenya  added the comment:

the problem seems to be fixed with the patch attached. 
Thanks go to fijal@freenode

--
keywords: +patch
Added file: http://bugs.python.org/file23348/urllib2.patch

___
Python tracker 

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

[issue13131] FD leak in urllib2

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +orsenthil

___
Python tracker 

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

[issue13131] FD leak in urllib2

[Ezio Melotti]

Ezio Melotti  added the comment:

Pay attention not to introduce regressions like the one in #12576 while fixing 
this.  I'm not sure there are similar tests for urllib2 -- if not they should 
be added.

--
nosy: +ezio.melotti
stage:  -> patch review

___
Python tracker 

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

[issue13133] FD leaks in ZipFile.read(), ZipFile.extract() and also using explicit arc_member.close()

[Meador Inge]

Meador Inge  added the comment:

I can't reproduce this problem in either 2.7.2 or 3.3.0a0.

> For example if executed with pypy.

Do you mean that this problem is only reproducible when the attached
script is run with pypy?

--
nosy: +meador.inge

___
Python tracker 

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

[issue13134] speed up finding of one-character strings

[Antoine Pitrou]

New submission from Antoine Pitrou :

In stringlib/fastsearch, instead of using our own loops, we can use memchr() 
(and, if available, memrchr()) when looking for one-character strings. memchr() 
is generally quite optimized; on this Linux/glibc machine, I get speedups of 
5x-10x:

./python -m timeit -s "large='a'*1+'b'" "large.find('b')"
-> before: 10.5 usec per loop
-> after: 0.889 usec per loop

./python -m timeit -s "large='b'+'a'*1" "large.rfind('b')"
-> before: 7.06 usec per loop
-> after: 1.94 usec per loop

--
components: Interpreter Core
messages: 145186
nosy: haypo, loewis, pitrou
priority: normal
severity: normal
status: open
title: speed up finding of one-character strings
type: performance
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

[issue13134] speed up finding of one-character strings

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
keywords: +patch
Added file: http://bugs.python.org/file23349/memchr.patch

___
Python tracker 

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

[issue13134] speed up finding of one-character strings

[Antoine Pitrou]

Antoine Pitrou  added the comment:

With MSVC there seems to be no difference, meaning Windows probably has a naïve 
memchr() implementation.

--

___
Python tracker 

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

[issue13133] FD leaks in ZipFile.read(), ZipFile.extract() and also using explicit arc_member.close()

[Valery Khamenya]

Valery Khamenya  added the comment:

"I can't reproduce this problem in either 2.7.2 or 3.3.0a0."

You probably mean CPython implementation of Python. No, I didn't mean this 
implementation.

"Do you mean that this problem is only reproducible when the attached
script is run with pypy?"

I can't say "only". I just could say yes, it is reproducible with pypy. 
Perhaps, there are others Python implementations that will suffer from the bug 
in current implementation of ZipFile

--

___
Python tracker 

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

[issue13134] speed up finding of one-character strings

[Antoine Pitrou]

Antoine Pitrou  added the comment:

New patch with a couple of tests.

--
Added file: http://bugs.python.org/file23350/memchr2.patch

___
Python tracker 

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

[issue13135] Using type() as a constructor doesn't support new class keyword arguments

[Marty Alchin]

New submission from Marty Alchin :

PEP 3115 introduced keyword arguments to class definitions and changed 
metaclasses to use them instead. Unfortunately, `type()` doesn't seem to have 
been updated to accept those keyword arguments as well. What this amounts to is 
that using `type()` as a constructor can no longer fully replicate the behavior 
of a class definition. Therefore, classes that use keyword arguments can't be 
created dynamically.

I would attempt a patch, but I don't have a development environment capable of 
compiling Python, so I wouldn't have any chance to test it.

--
messages: 145190
nosy: gulopine
priority: normal
severity: normal
status: open
title: Using type() as a constructor doesn't support new class keyword arguments
type: feature request

___
Python tracker 

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

[issue13133] FD leaks in ZipFile.read(), ZipFile.extract() and also using explicit arc_member.close()

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

Yes, in 2.7 many parts of the stdlib relies on reference counting to close 
files.  But 3.2 introduced a ResourceWarning which is emitted (in debug mode) 
each time a __del__ closes a valuable resource like a file or a socket.  This 
was done exactly for this reason - help other implementations with a different 
garbage collector.

Now Lib/zipfile.py is probably much more gc-friendly: see how it uses a new 
member "close_fileobj", and the "with" statement in ZipFile.read().

PyPy will benefit of this when it migrates to 3.2; meanwhile, you could apply 
the same changes in pypy's own copy of zipfile.py.

--
nosy: +amaury.forgeotdarc
resolution:  -> out of date
status: open -> pending

___
Python tracker 

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

[issue13136] speed-up conversion between unicode widths

[Antoine Pitrou]

New submission from Antoine Pitrou :

This patch speeds up _PyUnicode_CONVERT_BYTES by unrolling its loop.

Example micro-benchmark:

./python -m timeit -s "a='x'*1;b='\u0102'*1000;c='\U0010'" "a+b+c"

-> before:
10 loops, best of 3: 14.9 usec per loop
-> after:
10 loops, best of 3: 9.19 usec per loop

--
components: Interpreter Core
files: unroll_convert_bytes.patch
keywords: patch
messages: 145192
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: speed-up conversion between unicode widths
type: performance
versions: Python 3.3
Added file: http://bugs.python.org/file23351/unroll_convert_bytes.patch

___
Python tracker 

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

[issue13136] speed-up conversion between unicode widths

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Antoine Pitrou wrote:
> 
> New submission from Antoine Pitrou :
> 
> This patch speeds up _PyUnicode_CONVERT_BYTES by unrolling its loop.
> 
> Example micro-benchmark:
> 
> ./python -m timeit -s "a='x'*1;b='\u0102'*1000;c='\U0010'" "a+b+c"
> 
> -> before:
> 10 loops, best of 3: 14.9 usec per loop
> -> after:
> 10 loops, best of 3: 9.19 usec per loop

Before going further with this, I'd suggest you have a look at your
compiler settings. Such optimizations are normally performed by the
compiler and don't need to be implemented in C, making maintenance
harder.

The fact that Windows doesn't exhibit the same performance difference
suggests that the optimizer is not using the same level or feature
set as on Linux. MSVC is at least as good at optimizing code as gcc,
often better.

I tested using memchr() when writing those "naive" loops. It turned
out that using memchr() was slower than using the direct loops. memchr()
is inlined by the compiler just like the direct loop and the generated
code for the direct version is often easier to optimize for the compiler
than the memchr() one, since it receives more knowledge about the used
data types.

--
nosy: +lemburg

___
Python tracker 

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

[issue13136] speed-up conversion between unicode widths

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Before going further with this, I'd suggest you have a look at your
> compiler settings.

They are set by the configure script:

gcc -pthread -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes-I. -I./Include-DPy_BUILD_CORE -o
Objects/unicodeobject.o Objects/unicodeobject.c

> Such optimizations are normally performed by the
> compiler and don't need to be implemented in C, making maintenance
> harder.

The fact that the glibc includes such optimization (in much more
sophisticated form) suggests to me that many compilers don't perform
these optimizations automically.

> I tested using memchr() when writing those "naive" loops.

memchr() is mentioned in another issue, #13134.

> memchr()
> is inlined by the compiler just like the direct loop

I don't think so. If you look at the glibc's memchr() implementation,
it's a sophisticated routine, not a trivial loop. Perhaps you're
thinking about memcpy().

> and the generated
> code for the direct version is often easier to optimize for the compiler
> than the memchr() one, since it receives more knowledge about the used
> data types.

?? Data types are fixed in the memchr() definition, there's no knowledge
to be gained by inlining.

--

___
Python tracker 

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

[issue13137] from __future__ import division breaks ad hoc numeric types

[Blair]

New submission from Blair :

I believe that the use of __future__.division may have unintended consequences 
with user types that define division.

The following fails:

from __future__ import division

class NumericType(object):
def __init__(self,x):
self.x = x

def __div__(self,rhs):
return self.x/rhs

print NumericType(3.0) / 2.0

with the error message

  File "C:\proj_py\learning\future_bug\future.py", line 10, in 
print NumericType(3.0) / 2.0
TypeError: unsupported operand type(s) for /: 'NumericType' and 'float'

Remove the line `from __future__ import division` and everything works fine.

I am using Python 2.7.2

--
components: None
messages: 145195
nosy: gumtree
priority: normal
severity: normal
status: open
title: from __future__ import division breaks ad hoc numeric types
type: behavior
versions: Python 2.7

___
Python tracker 

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

[issue13137] from __future__ import division breaks ad hoc numeric types

[Benjamin Peterson]

Benjamin Peterson  added the comment:

You have to implement __truediv__.

--
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

___
Python tracker 

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

[issue13135] Using type() as a constructor doesn't support new class keyword arguments

[Benjamin Peterson]

Benjamin Peterson  added the comment:

That's not true. You simply call the metaclass itself.

--
nosy: +benjamin.peterson
resolution:  -> invalid
status: open -> closed

___
Python tracker 

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

[issue13135] Using type() as a constructor doesn't support new class keyword arguments

[Marty Alchin]

Marty Alchin  added the comment:

Hrm, that does seem to satisfy the case I was immediately concerned with, but I 
was thinking there was another issue with it, but now I'm having trouble 
pinning down an example. I'll just assume I was getting ahead of myself. Thanks 
for the sanity lesson.

--

___
Python tracker 

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

[issue13138] ElementTree's Element.iter() lacks versionadded

[Andreas Stührk]

New submission from Andreas Stührk :

See http://docs.python.org/whatsnew/2.7.html#updated-module-elementtree-1-3

--
assignee: docs@python
components: Documentation
files: Element_iter_versionadded.patch
keywords: patch
messages: 145199
nosy: Trundle, docs@python
priority: normal
severity: normal
status: open
title: ElementTree's Element.iter() lacks versionadded
versions: Python 2.7
Added file: http://bugs.python.org/file23352/Element_iter_versionadded.patch

___
Python tracker 

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

[issue13136] speed-up conversion between unicode widths

[Meador Inge]

Meador Inge  added the comment:

On Sat, Oct 8, 2011 at 5:34 PM, Antoine Pitrou  wrote:

> Antoine Pitrou  added the comment:
>
>> Before going further with this, I'd suggest you have a look at your
>> compiler settings.
>
> They are set by the configure script:
>
> gcc -pthread -c -Wno-unused-result -DNDEBUG -g -fwrapv -O3 -Wall
> -Wstrict-prototypes    -I. -I./Include    -DPy_BUILD_CORE -o
> Objects/unicodeobject.o Objects/unicodeobject.c
>
>> Such optimizations are normally performed by the
>> compiler and don't need to be implemented in C, making maintenance
>> harder.
>
> The fact that the glibc includes such optimization (in much more
> sophisticated form) suggests to me that many compilers don't perform
> these optimizations automically.

I agree.  This is more of an optimized runtime library problem than
code optimization problem.

>> I tested using memchr() when writing those "naive" loops.
>
> memchr() is mentioned in another issue, #13134.

Yeah, this conversation is really more relevant to issue13134, but I will
reply to these here anyway 

>> memchr()
>> is inlined by the compiler just like the direct loop
>
> I don't think so. If you look at the glibc's memchr() implementation,
> it's a sophisticated routine, not a trivial loop. Perhaps you're
> thinking about memcpy().

Without link-time optimization enabled, I doubt the toolchain can
"inline" 'memchr'
in the traditional sense (i.e. inserting the body of the routine
inline).  Even if it could,
the inline heuristics would most likely choose not to.  I don't think we use LTO
with GCC, but I think we might with VC++.

GCC does something else called builtin folding that is more likely.
For example,
'memchr ("bca", 'c', 3)' gets replace with instructions to compute a pointer
index into "bca".  This won't happen in this case because all of the 'memchr'
arguments are all variable.

>> and the generated
>> code for the direct version is often easier to optimize for the compiler
>> than the memchr() one, since it receives more knowledge about the used
>> data types.
>
> ?? Data types are fixed in the memchr() definition, there's no knowledge
> to be gained by inlining.

I think what Marc-Andre is alluding to is that the first parameter of
'memchr' is 'void *'
which could (in theory) limit optimization opportunities.  Where as if
it knew that
the data being searched is a 'char *' or something it could take
advantage of that.

--
nosy: +meador.inge

___
Python tracker 

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

[issue10399] AST Optimization: inlining of function calls

[Meador Inge]

Changes by Meador Inge :


--
nosy: +meador.inge

___
Python tracker 

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

[issue13139] multiprocessing.map skips finally blocks

[Daniel Wagner-Hall]

New submission from Daniel Wagner-Hall :

import random

from multiprocessing import Pool
from time import sleep

def Process(x):
  try:
print x
sleep(random.random())
raise Exception('Exception: ' + x)
  finally:
print 'Finally: ' + x

Pool(3).map(Process, ['1','2','3'])

Expect all three Finally blocks to be called (or at least, one Finally per x 
printed by line 8)

Actually, only one (occasionally two) are printed.

Same behaviour exhibited on dual-core Mac running OSX 10.6 with Python 2.7, and 
single core Ubuntu running Python 2.6.

--
components: None
messages: 145201
nosy: illicitonion
priority: normal
severity: normal
status: open
title: multiprocessing.map skips finally blocks
type: behavior
versions: Python 2.6, Python 2.7

___
Python tracker 

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

[issue13132] distutils sends non-RFC compliant HTTP request

[Éric Araujo]

Éric Araujo  added the comment:

Hi Mitchell, thanks for your interest in Python.  Using CLRF was requested 
before (#10510) and rejected on the ground that the RFC (at least for HTTP 1.0) 
allows LF.  CRLF is preferred but not required.  Hence, we deem it is not a bug.

The register, upload and upload_docs commands in distutils2 do use CRLF.

BTW, I think your patch was incomplete: You stripped one newline, replaced one 
LF with CRLF, and left many other LFs.

--
assignee: tarek -> eric.araujo
nosy: +orsenthil
versions:  -Python 2.6, Python 3.1, Python 3.4

___
Python tracker 

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

[issue12533] python-celementtree prevents me from running python develop.py to compile Imprudence Viewer

[Éric Araujo]

Éric Araujo  added the comment:

Closing, please reopen if there is more info.

--
resolution:  -> invalid
stage:  -> committed/rejected
status: pending -> closed
versions:  -Python 2.7

___
Python tracker 

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

[issue12967] AttributeError distutils\log.py

[Éric Araujo]

Éric Araujo  added the comment:

I stand by my opinion that running setup.py from IDLE is not supported.

--
resolution:  -> wont fix
stage:  -> committed/rejected
status: open -> closed
type: compile error -> behavior

___
Python tracker 

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

[issue13136] speed-up conversion between unicode widths

[Martin v . Löwis]

Martin v. Löwis  added the comment:

Marc-Andre: gcc will normally not unroll loops, unless -funroll-loops is given 
on the command line. Then, it will unroll many loops, and do so with 8 
iterations per outer loop. This typically causes significant code bloat, which 
is why unrolling is normally disabled and left to the programmer.

For those who want to experiment with this, I attach a C file with just the 
code in question. Compile this with your favorite compiler settings, and see 
what the compile generates. clang, on an x64 system, compiles the original loop 
into


LBB0_2: ## =>This Inner Loop Header: Depth=1
movzbl  (%rdi), %eax
movw%ax, (%rdx)
incq%rdi
addq$2, %rdx
decq%rsi
jne LBB0_2

and the unrolled loop into

LBB1_2: ## %.lr.ph6
## =>This Inner Loop Header: Depth=1
movzbl  (%rdi,%rcx), %r8d
movw%r8w, (%rdx)
movzbl  1(%rdi,%rcx), %r8d
movw%r8w, 2(%rdx)
movzbl  2(%rdi,%rcx), %r8d
movw%r8w, 4(%rdx)
movzbl  3(%rdi,%rcx), %r8d
movw%r8w, 6(%rdx)
addq$8, %rdx
addq$4, %rcx
cmpq%rax, %rcx
jl  LBB1_2

--
nosy: +loewis
Added file: http://bugs.python.org/file23353/unroll.c

___
Python tracker 

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

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

[Éric Araujo]

Éric Araujo  added the comment:

> Note the existing test doesn't actually perform a build so the new
> test also doesn't, but it does check the core logic
Sounds good to me.

+def manifest_setup_ldargs
I’d make all new methods private ones (i.e. leading underscore).

> an embedded manifests
Typo: extra s

> return None if not temp_manifest else (temp_manifest, mfid)
Using a ternary expression runs afoul of PEP 291: distutils should remain 
compatible with 2.3.  (I’m not sure it is right now, we use modern unittest 
methods in tests and all, but it is no reason for making it worse in new code :)

Your patch will also need an entry in Misc/NEWS; at first glance, there is no 
documentation file to edit.

Will you port the patch to packaging in 3.3?  I can do it if you don’t have the 
time, but I’m not set up yet to test on Windows, so I can ask you to test a 
patch.  Also, for the distutils2 backport (which I can do too), we would need 
to run tests with all versions from 2.4 to 3.3.

--

___
Python tracker 

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

[issue12436] Missing items in installation/setup instructions

[Éric Araujo]

Éric Araujo  added the comment:

> In addition to Notepad++ do you think it would be a good idea to at
> least mention Vim and Emacs with a disclaimer about the learning
> curve?
No.  If someone is looking at this page and doesn’t already have a text editor 
they’re familiar with, I think Notepad++ is the right tool to suggest.

> Do you think it would be a good idea to add instructions on how to add Python
> to the Path in Windows?
The doc already has that somewhere, unless I misremember.

> Yes, but isn't there a script somewhere that does that already?
One or more in Tools/scripts and maybe in PC or PCbuild too.

--

___
Python tracker 

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

[issue13123] bdist_wininst uninstaller does not remove pycache directories

[Éric Araujo]

Éric Araujo  added the comment:

I don’t have a Windows VM set up yet, but I can try to write a patch in the 
coming weeks and ask you to test it.  Deal?

--
stage:  -> needs patch

___
Python tracker 

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

[issue3902] Packages containing only extension modules have to contain __init__.py

[Éric Araujo]

Éric Araujo  added the comment:

>> We’re working on a patch on the core-mentorship list.
> I emailed the diff to the Core-Mentorship list, but since there
> was no reply I will just attach it here.
I added that message here to avoid someone else working on the same bug.  I did 
not reply to the mailing list because it’s not easy to review emailed patches 
and I don’t have Internet access each day.

> Please review patch and let me know if you want any changes.
Done.  You should have received an email; if not, follow the link titled 
“review” on the right of your patch.

--

___
Python tracker 

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

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

[Mark Hammond]

Mark Hammond  added the comment:

Thanks for the review.  One note:

| +def manifest_setup_ldargs
| I’d make all new methods private ones (i.e. leading underscore).

They aren't strictly private and are designed to be overridden by subclasses 
(although in practice, subclassing the compiler is much harder than it should 
be, so pywin32 monkey-patches the instance.)  This is actually the entire point 
of my updated patch - to give setup.py authors some level of control over the 
manifest behaviour.

I do intend forward-porting to 3.3 and also to check it is is too late for 3.2 
(a quick check before implied it might be OK, but I'm not sure)

--

___
Python tracker 

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

[issue7833] bdist_wininst installers fail to load extensions built with Issue4120 patch

[Éric Araujo]

Éric Araujo  added the comment:

> They aren't strictly private and are designed to be overridden by
> subclasses
OK.

> I do intend forward-porting to 3.3 and also to check it is is too late
> for 3.2 (a quick check before implied it might be OK, but I'm not sure)
2.7 and 3.2 are open for bug fixes, as indicated by the versions field of this 
bug (it’s actually a matrix: component distutils + versions 2.7, 3.2, 3.3, 
component distutils2 + version 3.3 == packaging and distutils2 + third-party == 
the distutils2 backport :)

--
assignee: tarek -> mhammond

___
Python tracker 

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

[issue6164] [AIX] Patch to correct the AIX C/C++ linker argument used for 'runtime_library_dirs'

[Éric Araujo]

Éric Araujo  added the comment:

This was fixed in 2.7 and 3.2; no luck for 3.1.

--
resolution: accepted -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.2 -Python 3.1

___
Python tracker 

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

[issue10945] bdist_wininst depends on MBCS codec, unavailable on non-Windows

[Éric Araujo]

Éric Araujo  added the comment:

haypo:
> Can't you only work with Unicode and avoid the MBCS encoding?
It is not code under the users’ control (i.e. setup.py) that uses MBCS, but the 
bdist_wininst command itself.  It used to be runnable from linux, which is 
great to provide binary installers for Windows users who typically don’t have a 
compiler.  This is what the bug is about.

--
versions:  -Python 3.1

___
Python tracker 

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

[issue11638] pysetup un sdist crashes with weird trace if version is unicode by accident

[Éric Araujo]

Éric Araujo  added the comment:

Does someone want to write a test for this?  We have examples of creating 
tarball sdists in Lib/distutils/tests/test_sdist.py, one would just need to 
copy one example and use a version with a unicode version.

--
keywords: +easy
resolution: remind -> 
versions: +Python 2.7, Python 3.2, Python 3.3

___
Python tracker 

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

[issue12967] IDLE RPC Proxy for standard IO streams lacks 'errors' attribute

[Ned Deily]

Ned Deily  added the comment:

I don't have a strong opinion about whether running setup.py in IDLE is 
supported.  But that's not the real issue here.  The problem is that the IDLE 
RPC proxy of the standard IO streams is incomplete, in particular, the 'errors' 
attribute of io.TextIOWrapper streams.  Looking back, it appears that the 
`errors` attribute was added to file objects and io streams in 2.6 but support 
for that was not added to IDLE.  I think that should be fixed.

--
assignee: eric.araujo -> ned.deily
components: +IDLE -Distutils
resolution: wont fix -> 
stage: committed/rejected -> needs patch
status: closed -> open
title: AttributeError distutils\log.py -> IDLE RPC Proxy for standard IO 
streams lacks 'errors' attribute
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

[issue12967] IDLE RPC Proxy for standard IO streams lacks 'errors' attribute

[Éric Araujo]

Changes by Éric Araujo :


--
nosy:  -eric.araujo, tarek

___
Python tracker 

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

[issue10359] ISO C cleanup

[Roundup Robot]

Roundup Robot  added the comment:

New changeset fe0972e102cd by Éric Araujo in branch '3.2':
Make C code in one distutils test comply with ISO C (#10359).
http://hg.python.org/cpython/rev/fe0972e102cd

New changeset 9ded1f21f0fd by Éric Araujo in branch 'default':
Make C code in one packaging test comply with ISO C (#10359).
http://hg.python.org/cpython/rev/9ded1f21f0fd

--

___
Python tracker 

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