[issue4753] Faster opcode dispatch on gcc

[Paolo 'Blaisorblade' Giarrusso]

Paolo 'Blaisorblade' Giarrusso  added the comment:

The standing question is still: can we get ICC to produce the expected 
output? It looks like we still didn't manage, and since ICC is the best 
compiler out there, this matters.
Some problems with SunCC, even if it doesn't do jump sharing, it seems 
that one doesn't get the speedups - I guess that on most platforms we 
should select the most common alternative for interpreters (i.e. no 
switch, one jump table, given by threadedceval5.patch + 
abstract-switch-reduced.diff).

On core platforms we can spend time on fine-tuning - and the definition 
of "core platforms" is given by "do developers want to test for that?".

When that's fixed, I think that we just have to choose the simpler form 
and merge that.

@alexandre:
[about removing the switch]
> There is no speed difference on pybench on x86; on x86-64, the code 
is slower due to the opcode fetching change.

Actually, on my machine it looks like the difference is caused by the 
different layout caused by switch removal, or something like that, 
because fixing the opcode fetching doesn't make a difference here (see 
below).

Indeed, I did my benchmarking duties. Results are that 
abstract-switch-reduced.diff (the one removing the switch) gives a 1-3% 
slowdown, and that all the others don't make a significant difference. 
The differences in the assembly output seem to be due to a different 
code layout for some branches, I didn't have a closer look.

However, experimenting with -falign-labels=16 can give a small speedup, 
I'm trying to improve the results (what I actually want is to align 
just the opcode handlers, I'll probably do that by hand).

reenable-static-prediction can give either a slowdown or a speedup by 
around 1%, i.e. around the statistical noise.

Note that on my machine, I get only a 10% speedup with the base patch, 
and that is more reasonable here. In the original thread on PyPy-dev, I 
got a 20% one with the Python interpreter I built for my student 
project, since that one is faster* (by a 2-3x factor, like PyVM), so 
the dispatch cost is more significant, and reducing it has a bigger 
impact. In fact, I couldn't believe that Python got the same speedup.

This is a Core 2 Duo T7200 (Merom) in 64bit mode with 4MB of L2 cache, 
and since it's a laptop I expect it to have slower RAM than a desktop.

@alexandre:
> The patch make a huge difference on 64-bit Linux. I get a 20% 
speed-up and the lowest run time so far. That is quite impressive!
Which processor is that?

@pitrou:
> The machine I got the 15% speedup on is in 64-bit mode with gcc
4.3.2.

Which is the processor? I guess the bigger speedups should be on 
Pentium4, since it has the bigger mispredict penalties.


*DISCLAIMER: the interpreter of our group (me and Sigurd Meldgaard) is 
not complete, has some bugs, and the source code has not yet been 
published, so discussion about why it is faster shall not happen here - 
I want to avoid any flame.
I believe it's not because of skipped runtime checks or such stuff, but 
because we used garbage collection instead of refcounting, indirect  
threading and tagged integers, but I don't have time to discuss that 
yet.
The original thread on pypy-dev has some insights if you are interested 
on this.

___
Python tracker 

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

[issue4893] Use separate thread support code under MS Windows CE

[Ulrich Eckhardt]

Ulrich Eckhardt  added the comment:

The thread code is unaffected by the Unicode/ANSI issues, but CE 
doesn't have _beginthread[ex], which are mandatory for the desktop 
variants. I have checkin 68455 and I will try to compile the new NT 
code under CE to estimate how large the changes are.

___
Python tracker 

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

[issue4903] binascii.crc32()

[Martin v. Löwis]

Martin v. Löwis  added the comment:

What is "this" that you want to get documented? Can you propose a
specific wording?

--
nosy: +loewis

___
Python tracker 

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

[issue4905] Use INVALID_FILE_ATTRIBUTES instead of magic numbers

[Ulrich Eckhardt]

New submission from Ulrich Eckhardt :

GetFileAttributes[W|A] returns a DWORD with this value when it 
couldn't determine the file's attributes. In the Python codebase, 
there are basically three values this is compared with, the above 
macro, 0x and (DWORD)-1, it should only be the macro.

However, this macro isn't defined in some SDKs (I don't remember if 
those were early MSVC versions or some MS Windows CE SDKs), so we also 
need to work around that.

I'm currently preparing a patch that resolves those including the 
workaround when the macro isn't defined.

--
components: Interpreter Core
messages: 79535
nosy: eckhardt
severity: normal
status: open
title: Use INVALID_FILE_ATTRIBUTES instead of magic numbers
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

[issue4753] Faster opcode dispatch on gcc

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> @pitrou:
> > The machine I got the 15% speedup on is in 64-bit mode with gcc
> 4.3.2.
> 
> Which is the processor? I guess the bigger speedups should be on 
> Pentium4, since it has the bigger mispredict penalties.

Athlon X2 3600+.

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> It looks like we still didn't manage, and since ICC is the best 
> compiler out there, this matters.

Well, from the perspective of Python, what matters mostly is the
commonly used compilers (that is, gcc and MSVC). I doubt many people
compile Python with icc, honestly.

Same for CPU-specific tuning: I don't think we want to ship Python with
compiler flags which depend on the particular CPU being used.

___
Python tracker 

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

[issue4906] os.listdir fails on debug build (windows)

[Hirokazu Yamamoto]

New submission from Hirokazu Yamamoto :

Due to r68455, os.listdir fails on debug build (windows).

//

Python 2.7a0 (trunk, Jan 10 2009, 18:36:15) [MSC v.1200 32 bit (Intel)] 
on win32

Type "help", "copyright", "credits" or "license" for more information.
>>> import os
[33639 refs]
>>> os.listdir(".")
Traceback (most recent call last):
  File "", line 1, in 
WindowsError: [Error 0] この操作を正しく終了しました。: './*.*'
[33678 refs]

//

Probably a following XP Buildbot error comes from same reason.

http://www.python.org/dev/buildbot/trunk.stable/x86%20XP-4%
20trunk/builds/1759/step-compile/0

This error is raised near Modules/posixmodule.c (2205)

Py_BEGIN_ALLOW_THREADS
result = FindNextFile(hFindFile, &FileData);
Py_END_ALLOW_THREADS
/* FindNextFile sets error to ERROR_NO_MORE_FILES if
   it got to the end of the directory. */
if (!result && GetLastError() != ERROR_NO_MORE_FILES) {

GetLastError() is sometimes 0 when should be ERROR_NO_MORE_FILES.
This happens because, on debug build, Py_END_ALLOW_THREADS finally
reaches PyThread_get_key_value in Python/thread_nt.h, and TlsGetValue
in it calls SetValueError(0) when function succeeds. See
http://msdn.microsoft.com/en-us/library/ms686812.aspx

I've attached the patch to fix this. I believe LastError set by
TlsGetValue on its failure is not used anywhere.

--
components: Interpreter Core
files: fix_thread_nt.patch
keywords: needs review, patch
messages: 79538
nosy: ocean-city
priority: critical
severity: normal
status: open
title: os.listdir fails on debug build (windows)
versions: Python 2.7
Added file: http://bugs.python.org/file12672/fix_thread_nt.patch

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

On 2009-01-10 10:55, Antoine Pitrou wrote:
> Antoine Pitrou  added the comment:
> 
>> It looks like we still didn't manage, and since ICC is the best 
>> compiler out there, this matters.
> 
> Well, from the perspective of Python, what matters mostly is the
> commonly used compilers (that is, gcc and MSVC). I doubt many people
> compile Python with icc, honestly.

Agreed. Our main targets should be GCC for Linux and MSVC for Windows.

On other platforms such as Solaris and AIX, the native vendor compilers
are commonly used for compiling Python.

That said, with a configure option to turn the optimization on and
off, there shouldn't be any problem with slowdowns.

> Same for CPU-specific tuning: I don't think we want to ship Python with
> compiler flags which depend on the particular CPU being used.

Certainly not in the binaries we release on python.org.

Of course, people are still free to setup OPT to have the compiler
generate CPU specific code.

___
Python tracker 

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

[issue4906] os.listdir fails on debug build (windows)

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

I see, so it was I that caused this :)
I will owe up to it and submit a fix.

--
nosy: +krisvale

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Paolo 'Blaisorblade' Giarrusso]

Paolo 'Blaisorblade' Giarrusso  added the comment:

> Same for CPU-specific tuning: I don't think we want to ship Python
with compiler flags which depend on the particular CPU being used.

I wasn't suggesting this - but since different CPUs have different
optimization rules, something like "oh, 20% performance slowdown on
PowerPC" or "on P4" is important to know (and yeah, configure options
are a good solution).

Which is the barrier for platform-specific tricks, as long as the code
is still portable? I'd like to experiment with __builtin_expect and with
manual alignment (through 'asm volatile(".p2align 4")' on x86/x86_64
with GAS - PPC might need a different alignment probably).

All hidden through macros to make it disappear on unsupported platforms,
without any configure option for them (there shouldn't be the need for
that).

> I doubt many people compile Python with icc, honestly.

Yep :-(. Why don't distributors do it? (First culprit might
be license/compatibility problems I guess, but the speedup would be
worth the time to fix the troubles IMHO).

___
Python tracker 

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

[issue4903] binascii.crc32()

[David M. Beazley]

David M. Beazley  added the comment:

Placing a note in the standard library documentation would be a start.   
Just say in Python 3.0 it always returns the result as an unsigned 
integer whereas in Python 2.6 a 32-bit signed integer is returned. 
Although the numerical value may differ between versions, the underlying 
bits are the same.  Use crc32() & 0x to get a consistent value 
(already noted).

Note: Not everyone uses checksums in only a packed-binary format.  
Having the integer value just change across Python  versions like that 
is a real subtle compatibility problem to point out.

___
Python tracker 

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

[issue4906] os.listdir fails on debug build (windows)

[Kristján Valur Jónsson]

Kristján Valur Jónsson  added the comment:

Checked in:
Completed: At revision: 68476

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

___
Python tracker 

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

[issue4905] Use INVALID_FILE_ATTRIBUTES instead of magic numbers

[Ulrich Eckhardt]

Ulrich Eckhardt  added the comment:

The patch replaces remaining magic numbers with INVALID_FILE_ATTRIBUTES.

--
keywords: +patch
Added file: http://bugs.python.org/file12673/python-2.7-fileattrib-magic.0.patch

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> (First culprit might
> be license/compatibility problems I guess, but the speedup would be
> worth the time to fix the troubles IMHO).

That would be the obvious reason IMO. And Intel is the only one who can
"fix the troubles".

___
Python tracker 

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

[issue4884] Work around gethostbyaddr_r bug

[Roumen Petrov]

Roumen Petrov  added the comment:

What about socket_gethostbyname_ex() ?

--
nosy: +rpetrov

___
Python tracker 

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

[issue1767370] Make xmlrpc use HTTP/1.1 and keepalive

[williambr]

williambr  added the comment:

Hi.

I am very intereasted about this patch... specially about the keep-alive
part...
I have a proposition... wouldn't be fair enough to have a separated
Transport just for keep-alive connections?

I could wirte one if no one is against it...

--
nosy: +williambr

___
Python tracker 

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

[issue4907] ast.literal_eval does not properly handled complex numbers

[Armin Ronacher]

New submission from Armin Ronacher :

ast.literal_eval does not properly handle complex numbers:

>>> ast.literal_eval("1j")
1j
>>> ast.literal_eval("2+1j")
Traceback (most recent call last):
  ...
ValueError: malformed string
>>> ast.literal_eval("(2+1j)")
Traceback (most recent call last):
  ...
ValueError: malformed string

Expected result:

>>> ast.literal_eval("1j")
1j
>>> ast.literal_eval("2+1j")
(2+1j)
>>> ast.literal_eval("(2+1j)")
(2+1j)

I attached a patch that fixes this problem.

--
components: Library (Lib)
files: literal-eval.patch
keywords: needs review, patch, patch
messages: 79548
nosy: aronacher
priority: normal
severity: normal
stage: patch review
status: open
title: ast.literal_eval does not properly handled complex numbers
type: behavior
versions: Python 2.6
Added file: http://bugs.python.org/file12674/literal-eval.patch

___
Python tracker 

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

[issue4868] Faster utf-8 decoding

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I committed the patch with the last suggested change (word -> data) in
py3k (r68483). I don't intend to backport it to trunk, but I suppose it
wouldn't be too much work to do.

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

___
Python tracker 

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

[issue4907] ast.literal_eval does not properly handled complex numbers

[Armin Ronacher]

Armin Ronacher  added the comment:

fixed patch :)

Added file: http://bugs.python.org/file12675/literal-eval.patch

___
Python tracker 

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

[issue3860] GzipFile and BZ2File should support context manager protocol

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Committed in trunk and py3k. Thanks!

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

___
Python tracker 

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

[issue4879] Allow buffering for HTTPResponse

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Why not name the parameter buffering=False rather than nobuffer=True?
Sounds more "natural" to me.

--
nosy: +pitrou

___
Python tracker 

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

[issue4472] Is shared lib building broken on trunk for Mac OS X?

[Skip Montanaro]

Skip Montanaro  added the comment:

Works for me.  Thanks Ronald.  Closing...

--
assignee:  -> ronaldoussoren
status: pending -> closed

___
Python tracker 

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

[issue4907] ast.literal_eval does not properly handled complex numbers

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Looks good to me assuming you add a test.

--
keywords:  -needs review
nosy: +benjamin.peterson

___
Python tracker 

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

[issue4904] Typo for PickingError in pickle.py

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Thanks for the report! Fixed in r68488.

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

___
Python tracker 

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

[issue4861] fix problems with ctypes.util.find_library

[Matthias Klose]

Matthias Klose  added the comment:

now fixed in 2.6, 2.7, 3.0 and 3.1.

objdump is never installed in /sbin. I don't think we should assume a
specific path for objdump. we don't do this for gcc either.

--
assignee: theller -> doko
resolution:  -> fixed
status: open -> closed

___
Python tracker 

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

[issue3383] ctypes.util fails to find libc in some environments

[Matthias Klose]

Matthias Klose  added the comment:

I keep this open for now, I don't have access to AIX. Yes, if objdump is
found in some /sbin PATH, then maybe we should search there explicitely.

___
Python tracker 

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

[issue4901] inconsistent API docs for tp_iter

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Thanks for the report! Fixed in r68495.

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

___
Python tracker 

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

[issue2396] Backport memoryview object to Python 2.7

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Here is a patch. Some remarks:
- I had to disable a few tests in test_memoryview.py, mainly because
array.array does not support the new buffer API in 2.x
- I kept the PyBytes_* aliases in memoryobject.c rather than using the
PyString_* equivalents. Is it ok?
- I didn't update the Windows build files, I suppose someone else can do
it (I'm unable to do it myself)
- I'm not sure about the tp_flags juggling in typeobject.c, my additions
may be redundant (although very lightweight)

--
assignee:  -> pitrou
keywords: +patch
stage:  -> patch review
title: Backport memoryview object to Python 2.6 -> Backport memoryview object 
to Python 2.7
Added file: http://bugs.python.org/file12676/memview-trunk.patch

___
Python tracker 

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

[issue2486] Decimal slowdown in 3.0 due to str/unicode changes

[Mark Dickinson]

Mark Dickinson  added the comment:

(Adding Raymond to the nosy list.)

In r68494, I've checked in some work towards rewriting Decimal (or parts 
of Decimal) in C.  I reused Facundo's old /decimal directory in the 
sandbox, so the URL is:

http://svn.python.org/view/sandbox/trunk/decimal/decimal_in_c/

What's there is a fully functional hybrid Python and C implementation of 
decimal.  All the existing decimal tests pass, at least on my machine.  
There's very little performance increase to boast of at the moment, but 
that may change.  To try it, check out the directory and follow the
README instructions.  This probably doesn't work on Windows;  help
fixing that would be appreciated.

The code is for py3k only;  I started out maintaining versions
for both 2.x and 3.x, but that was just too painful.  I'd rather
get the py3k version working, then backport.

The main files are:
  deccoeff.c:  contains classes Deccoeff and _Decimal.  Deccoeff
implements base 10 nonnegative integer arithmetic:  its instances
can be treated as integers, but also sliced as though they were
strings, which makes rounding and shifting operations simple.
_Decimal is a minimal base class for Decimal;  the idea is
to move functions from Decimal to _Decimal over time.
  decimal.py: version of Lib/decimal.py, fixed to use Deccoeff
instead of string for the coefficient.

As I see it, there are two goals for this work:

(1) Speed decimal up.
(2) Bring proposals to add a decimal literal to C closer to realizability.

By the way, presumably it's not a prerequisite for (2) that *all* of the 
decimal.py functionality be recoded in C?  I could imagine a situation 
where the decimal literals are present in the core, but an 'import 
decimal' was necessary to get complete functionality.

___
Python tracker 

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

[issue1777] ElementTree/cElementTree findtext inconsistency

[Fredrik Lundh]

Fredrik Lundh  added the comment:

Forgot to mention that this is fixed in the cElementTree trunk (public
as of today's 1.0.6 preview release).  Will merge with Python trunk when
I find the time...

___
Python tracker 

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

[issue4908] adding a get_metadata in distutils

[Tarek Ziadé]

New submission from Tarek Ziadé :

Let's add a "get_metadata" API in Distutils that would return
in a dictionary the content of the .egg-info file introduced into Python
2.5.


  >>> from distutils import get_metadata
  >>> get_metadata('ThePackage')
  {..}

(Working on a prototype)

--
assignee: tarek
components: Distutils
messages: 79562
nosy: tarek
severity: normal
status: open
title: adding a get_metadata in distutils
type: feature request
versions: Python 2.7, Python 3.1

___
Python tracker 

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

[issue2486] Decimal slowdown in 3.0 due to str/unicode changes

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
nosy: +rhettinger

___
Python tracker 

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

[issue2486] Decimal slowdown in 3.0 due to str/unicode changes

[Mark Dickinson]

Mark Dickinson  added the comment:

Changing title and assignee.  (But all help is appreciated:  if anyone 
wants to commit changes to the sandbox directory, please go ahead!)

___
Python tracker 

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

[issue2486] Recode (parts of) decimal module in C

[Mark Dickinson]

Changes by Mark Dickinson :


--
assignee: facundobatista -> marketdickinson
title: Decimal slowdown in 3.0 due to str/unicode changes -> Recode (parts of) 
decimal module in C

___
Python tracker 

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

[issue4884] Work around gethostbyaddr_r bug

[Jeffrey Yasskin]

Jeffrey Yasskin  added the comment:

socket_gethostbyname_ex() calls gethostbyname_r() rather than
gethostbyaddr_r(), and that appears not to have the bug.

___
Python tracker 

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

[issue2486] Recode (parts of) decimal module in C

[Mark Dickinson]

Mark Dickinson  added the comment:

> (2) Bring proposals to add a decimal literal to C ...

That should be "to Python", not "to C", of course.

___
Python tracker 

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

[issue2486] Recode (parts of) decimal module in C

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> By the way, presumably it's not a prerequisite for (2) that *all* of the 
> decimal.py functionality be recoded in C?  I could imagine a situation 
> where the decimal literals are present in the core, but an 'import 
> decimal' was necessary to get complete functionality.

We already have this situation with builtin open() and "import io", so I
guess that wouldn't be out of question.

--
nosy: +pitrou

___
Python tracker 

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

[issue2233] Makefile.pre.in contains extra slash before $(DESTDIR) which can cause Cygwin build to fail

[Roumen Petrov]

Roumen Petrov  added the comment:

Jason, did you test what is result is DESTDIR default to "/".

This variable(macro) is used with specific syntax by example (from
Makefile):
  $(INSTALL) -d -m $(DIRMODE) $(DESTDIR)$$b; \
where $$b is absolute path.

___
Python tracker 

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

[issue3754] minimal cross-compilation support for configure

[Roumen Petrov]

Changes by Roumen Petrov :


Added file: http://bugs.python.org/file12677/python-trunk.patch-CROSS-20090110

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

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

[Roumen Petrov]

Changes by Roumen Petrov :


Added file: http://bugs.python.org/file12678/python-trunk.patch-MINGW-20090110

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

[issue4909] incorrect renaming in imports

[Martin v. Löwis]

New submission from Martin v. Löwis :

The fragment

try:
import cStringIO as StringIO
except ImportError:
import StringIO
s=StringIO.StringIO()

gets rewritten to

try:
import io as StringIO
except ImportError:
import io
s=io.StringIO()

Unfortunately, that code fails to work: the first import succeeds,
actually binding StringIO; the name io is unbound and gives NameError.

Apparently, the fixer choses to replace all occurrences of StringIO with
io; it should extend this replacement to "as" clauses.

My work-around is to import as _StringIO in both cases, and then refer
to the module as _StringIO.

--
components: 2to3 (2.x to 3.0 conversion tool)
messages: 79568
nosy: loewis
severity: normal
status: open
title: incorrect renaming in imports

___
Python tracker 

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

[issue2396] Backport memoryview object to Python 2.7

[Thomas Heller]

Changes by Thomas Heller :


--
nosy: +theller

___
Python tracker 

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

[issue1251] ssl module doesn't support non-blocking handshakes

[Facundo Batista]

Facundo Batista  added the comment:

Bill, should this issue be closed?

Or Senthil found a bug in the actual code and you're waiting for him to
point out where is the problem or a way to reproduce it?

--
nosy: +facundobatista

___
Python tracker 

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

[issue2396] Backport memoryview object to Python 2.7

[Antoine Pitrou]

Antoine Pitrou  added the comment:

This new patch includes documentation update and fixes as well.

Added file: http://bugs.python.org/file12679/memview-trunk2.patch

___
Python tracker 

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

[issue4910] help(int.__long__) refers to nonexistent long function

[Mark Dickinson]

New submission from Mark Dickinson :

In Python 3.x:

>>> int.__long__.__doc__
'x.__long__() <==> long(x)'

But the long builtin no longer exists.

I'm actually not sure why the nb_long slot still exists in 3.x at all.  
Can anyone enlighten me?

--
messages: 79571
nosy: marketdickinson
severity: normal
status: open
title: help(int.__long__) refers to nonexistent long function
versions: Python 3.0, Python 3.1

___
Python tracker 

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

[issue1424152] urllib/urllib2: HTTPS over (Squid) Proxy fails

[Facundo Batista]

Facundo Batista  added the comment:

Everything looks ok, with one detail, the new set_tunnel() function.

Should this function be public? If yes, new documentation should be
added. If not, it should start with "_". 

I think that it should be public, because we're using it from somewhere
else. So, please provide new patchs for documentation (don't bother to
modify actual code patches).

Thank you!

___
Python tracker 

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

[issue4607] uuid behavior with multiple threads

[Facundo Batista]

Facundo Batista  added the comment:

Yes, _buffer is not longer global.

Thanks for the report!

--
nosy: +facundobatista
resolution:  -> out of date
status: open -> closed

___
Python tracker 

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

[issue4608] urllib.request.urlopen does not return an iterable object

[Facundo Batista]

Facundo Batista  added the comment:

Senthil, do you think you could provide a test case for this?

Thank you!

--
assignee:  -> facundobatista
nosy: +facundobatista

___
Python tracker 

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

[issue4909] incorrect renaming in imports

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Tricky. I only solution I can think of is replacing cStringIO with
_stringio or just refusing to replace StringIO usage once cStringIO has
been seen. The latter seems like the best solutions.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue4909] incorrect renaming in imports

[Martin v. Löwis]

Martin v. Löwis  added the comment:

If there is no straight-forward solution, we should close it as "won't
fix", and encourage users to work around.

___
Python tracker 

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

[issue4909] incorrect renaming in imports

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Ok. I will close this for now. This is a very common construct; if we
get more bug reports, we can reconsider. (I'm attaching the patch I used
to "fix" this for future reference.)

--
keywords: +patch
resolution:  -> wont fix
status: open -> closed
Added file: http://bugs.python.org/file12681/cStringIO_hack.patch

___
Python tracker 

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

[issue4908] adding a get_metadata in distutils

[Ray]

Changes by Ray :


--
nosy: +rayterrill

___
Python tracker 

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

[issue4796] Decimal to receive from_float method

[Facundo Batista]

Facundo Batista  added the comment:

Raymond, Mark, thanks for this work!

I'd include the following in the PEP (under the "from float"
discussion), what do you think?

"""
Update: The .from_float() method was added to Python 2.7 and 3.1
versions, providing lossless and exact conversion from float to Decimal 
(see issue 4796 [7]_ for further information).


It has the following syntax::

Decimal.from_float(floatNumber)

where ``floatNumber`` is the float number origin of the construction.  
Example::

>>> Decimal.from_float(1.1)
Decimal('1.100088817841970012523233890533447265625')
"""

--
nosy: +facundobatista

___
Python tracker 

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

[issue4796] Decimal to receive from_float method

[Mark Dickinson]

Mark Dickinson  added the comment:

I agree the PEP should be updated.  Your proposed update looks good to me.

___
Python tracker 

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

[issue4910] Should both nb_long and nb_int still exist in 3.x?

[Mark Dickinson]

Mark Dickinson  added the comment:

long(x) replaced by int(x) in r68508.

I'm still wondering about the nb_long slot, though.

--
title: help(int.__long__) refers to nonexistent long function -> Should both 
nb_long and nb_int still exist in 3.x?

___
Python tracker 

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

[issue4912] Invalid syntax in ctypes/util.py

[Antoine Pitrou]

New submission from Antoine Pitrou :

ctypes/util.py contains invalid py3k syntax at lines 106-107:

if rv == 10:
raise OSError, 'gcc or cc command not found'

--
assignee: theller
components: ctypes
messages: 79582
nosy: pitrou, theller
severity: normal
status: open
title: Invalid syntax in ctypes/util.py
type: crash
versions: Python 3.0, Python 3.1

___
Python tracker 

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

[issue4912] Invalid syntax in ctypes/util.py

[Benjamin Peterson]

Benjamin Peterson  added the comment:

Fixed in r68511.

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

___
Python tracker 

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

[issue4279] Module 'parser' fails to build

[Mark Sapiro]

Mark Sapiro  added the comment:

This problem also occurs when building the 2.6.1 parser module on Cygwin
1.5.25. It did not occur with Python 2.6 or 2.5.x.

The error from 'make' is

building 'parser' extension
gcc -shared -Wl,--enable-auto-image-base
build/temp.cygwin-1.5.25-i686-2.6/cygdrive/c/Python_dist/Python-2.6.1/Modules/parsermodule.o
-L/usr/local/lib -L. -lpython2.6 -o
build/lib.cygwin-1.5.25-i686-2.6/parser.dll
build/temp.cygwin-1.5.25-i686-2.6/cygdrive/c/Python_dist/Python-2.6.1/Modules/parsermodule.o:
In function `parser_expr':
/cygdrive/c/Python_dist/Python-2.6.1/Modules/parsermodule.c:552:
undefined reference to `__PyParser_Grammar'
build/temp.cygwin-1.5.25-i686-2.6/cygdrive/c/Python_dist/Python-2.6.1/Modules/parsermodule.o:
In function `parser_suite':
/cygdrive/c/Python_dist/Python-2.6.1/Modules/parsermodule.c:552:
undefined reference to `__PyParser_Grammar'
collect2: ld returned 1 exit status

I was able to work around the error and build a parser module that
passed unit test by manually running

gcc -shared -Wl,--enable-auto-image-base
build/temp.cygwin-1.5.25-i686-2.6/cygdrive/c/Python_dist/Python-2.6.1/Modules/parsermodule.o
Python/graminit.o -L/usr/local/lib -L. -lpython2.6 -o
build/lib.cygwin-1.5.25-i686-2.6/parser.dll

i.e. by including Python/graminit.o in the explicit object files to load.

I have also confirmed that applying the parser-grammar.patch from #4288
will allow make to successfully build a parser module that passes unit
tests.

--
nosy: +msapiro
versions: +Python 2.6

___
Python tracker 

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

[issue4288] parsermodule and grammar variable

[Mark Sapiro]

Changes by Mark Sapiro :


--
nosy: +msapiro

___
Python tracker 

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

[issue4279] Module 'parser' fails to build

[Yaakov (Cygwin Ports)]

Yaakov (Cygwin Ports)  added the comment:

Here's the patch I used for the Cygwin Ports 2.6 and 3.0 packages.  It's
the simplest working solution that I could find.

Added file: http://bugs.python.org/file12682/2.6.1-parsermodule.patch

___
Python tracker 

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

[issue4913] wave.py writes 16 bit sample files of half the correct duration

[Alex Robinson]

New submission from Alex Robinson :

Corrected code in writeframesraw():

self._datawritten = self._datawritten + len(data) *
self._sampwidth
else:
self._file.write(data)
self._datawritten = self._datawritten + len(data) *
self._sampwidth


Note that the default (not byte swapped) assignment to _datawritten must
also be multiplied by _sampwidth. If not, audio programs will ignore the
second half of a 16-bit-sample file.

As a side note, the calls to _patchheader() do not need to be protected
by this "if" statement:

if self._datalength != self._datawritten:

_patchheader does the same test to optimize its operation.

--
components: Library (Lib)
messages: 79586
nosy: alex_python_org
severity: normal
status: open
title: wave.py writes 16 bit sample files of half the correct duration
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 2.7, Python 3.0, Python 3.1

___
Python tracker 

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

[issue4753] Faster opcode dispatch on gcc

[Alexander Belopolsky]

Changes by Alexander Belopolsky :


--
nosy: +belopolsky

___
Python tracker 

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

[issue2486] Recode (parts of) decimal module in C

[Raymond Hettinger]

Raymond Hettinger  added the comment:

FWIW, I'm currently seeking project sponsorship to work on this.  To do
it right, a substantial portion of the module should be coded in C and
needs to function independently of Python, with accessors provided to
for Python to wrap around.

Once, there is a fast C version, a discussion of a decimal literal can
become a reasonable possibility.  It will be an uphill battle though. 
Many decimal apps have few internal constants -- most of the data comes
into the program from and external source and gets written back.  A
literal itself doesn't have much utility except for playing around at
the command line.  Also, there would need to be a PEP talking about how
decimals should interact with binary floats and the rest of the language
(which pretty much ignores decimals).

--
priority: high -> normal

___
Python tracker 

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

[issue4796] Decimal to receive from_float method

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Go ahead with the update, but it isn't really necessary.  The PEPs are
for getting something into the language in the first place and for
centralizing a major discussion.  They typically get out of date quickly
after they've been implemented.  In this case, we've got the tracker
discussion to document the minor discussions than led to this minor
change in the API.  So, it's okay to update the PEP or not.

___
Python tracker 

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

[issue4789] Documentation changes break existing URIs

[Mark Sapiro]

Mark Sapiro  added the comment:

Thank you for adding the redirects, and for getting them right in spite
of my garbling some of them in the original report.

I have updated the links for the next Mailman release.

___
Python tracker 

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

[issue4914] trunc(x) erroneously documented as built-in

[Mitchell Model]

New submission from Mitchell Model :

In the Numeric Types documentation for 2.6, 3.0, and 3.1 trunc is 
documented as a built-in, like round, but while there is a trunc in math 
there is no built-in trunc. Read some of the debate on trunc from a year 
ago convinced me that this discrepancy is a documentation problem not a 
problem with the built-in functions.  Sorry if I'm completely off target 
here, but since I noticed I figured it was worth an issue.

--
assignee: georg.brandl
components: Documentation, Library (Lib)
messages: 79590
nosy: MLModel, georg.brandl
severity: normal
status: open
title: trunc(x) erroneously documented as built-in
versions: Python 2.6, Python 3.0, Python 3.1

___
Python tracker 

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

[issue4903] binascii.crc32() - document signed vs unsigned results

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Agreed, we failed to mention the behavior change in the docs.  I'll take 
care of that.  (if its mentioned at all, its mentioned in a note buried 
in the Misc/NEWS file somewhere)

2to3 could presumably be made to notice crc32 and adler32 calls and warn 
about this problem.  I wouldn't have 2to3 add code to re-sign the return 
value by default as not everything needs that but it is worthy of a 
warning.

--
assignee:  -> gregory.p.smith
components: +Documentation
priority:  -> normal
resolution: duplicate -> 
status: closed -> open
title: binascii.crc32() -> binascii.crc32() - document signed vs unsigned 
results

___
Python tracker 

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