[issue2483] int and float accept bytes, complex does not

[Gabriel Genellina]

Gabriel Genellina <[EMAIL PROTECTED]> added the comment:

Are numbers so special to break 
the rules? why stopping here? 
what about other types that may 
want to accept ASCII bytes 
instead of characters? Isn't 
this like going back to the 2.x 
world?

The protocol with embedded ASCII 
numbers isn't a very convincing 
case for me. One can read a 
binary integer in C using a 
single function call. In Python 
2.X this can't be done in a 
single call, one has to use 
struct.unpack to decode the 
bytes read, and there was no 
complains that I know of. 
In 3.0 the same happens for 
ASCII numbers too, one will have 
to decode them first. The 
conversion may look like a 
stupid step, but it's as stupid 
as having to use struct.unpack 
to convert some bits to the 
*same* bits inside the integer 
object.

Writing int(str(value,'ascii')) 
doesn't look so terrible.

And one may argue that 
int(b'1234') should return 
0x34333231 instead of 1234; 
b'1234' is the binary 
representation of 0x34333231 in 
little-endian format.

--
nosy: +gagenellina

__
Tracker <[EMAIL PROTECTED]>

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

[issue2484] Cosmetic patch for warning "unused variable"

[Hirokazu Yamamoto]

Hirokazu Yamamoto <[EMAIL PROTECTED]> added the comment:

I've confirmed trunk doesn't have this problem.

Probably this is merge issue. r57928 changed the position of "int i,j"
in py3k, but not changed in trunk, so when r61864 was merged into py3k
some kind of conflict happened.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2491] io.open() handles errors differently on different platforms

[Neal Norwitz]

New submission from Neal Norwitz <[EMAIL PROTECTED]>:

The attached file has a snapshot of the python.org homepage that was
causing test_urllibnet to fail on some platforms (2 sparc, and ia64 at
least), but not other platforms.  This should be handled consistently.

I don't know if there are really errors in the attached web page or not.
 The problem occurs at byte offset 13259:

>>> data[13250:13270]
'r - Journ\xc3\xa9es Python'

I suppose that's invalid for ASCII, but valid UTF-8.

See r61921.  There is a problem that the API for fdopen doesn't accept
errors, encoding, etc. so it's problematic to handle this condition.

--
components: Library (Lib)
files: py-org.html
messages: 64540
nosy: nnorwitz
priority: critical
severity: normal
status: open
title: io.open() handles errors differently on different platforms
type: behavior
versions: Python 3.0
Added file: http://bugs.python.org/file9864/py-org.html

__
Tracker <[EMAIL PROTECTED]>

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

[issue2490] Assertion failure in datetime.strftime()

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Can you give us an example of the data that caused the failure?

--
nosy: +benjamin.peterson
type:  -> behavior

__
Tracker <[EMAIL PROTECTED]>

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

[issue2486] Consider using bytes type instead of str to store Decimal coefficients

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

Hmm, I forgot there wasn't currently a direct path back from int ->
bytes. I think your numbers *do* show that we need to do something about
the performance of the Python 3.0 version of decimal. A 25% increase in
runtime is a pretty big performance hit.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2459] speedup loops with better bytecode

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

This new patch also updates the code generation for list comprehensions.
Here are some micro-benchmarks:

./python -m timeit -s "l = range(100)" "[x for x in l]"
Before: 10 loops, best of 3: 14.9 usec per loop
After: 10 loops, best of 3: 12.5 usec per loop

./python -m timeit -s "l = range(100)" "[x for x in l if x]"
Before: 1 loops, best of 3: 24.1 usec per loop
After: 10 loops, best of 3: 18.8 usec per loop

./python -m timeit -s "l = range(100)" "[x for x in l if not x]"
Before: 10 loops, best of 3: 15.5 usec per loop
After: 10 loops, best of 3: 11.9 usec per loop

Please note that this patch is orthogonal with Neal's patch in #2183, so
the two combined should be quite interesting for the list comprehensions
bytecode.

Added file: http://bugs.python.org/file9863/loops5.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2490] Assertion failure in datetime.strftime()

[Pierre Metras]

New submission from Pierre Metras <[EMAIL PROTECTED]>:

datetime.strftime(pattern) fails in assertion if pattern is big enough (> 
100 chars) while time.strftime(pattern) gives the expected result.

This occurs on Python 2.5 (tested on OLPC XO laptop, Fedora 9). Python 2.4 
(Debian Etch) does not exhibit this bug.

--
components: Extension Modules
files: test.py
messages: 64536
nosy: genepi
severity: normal
status: open
title: Assertion failure in datetime.strftime()
versions: Python 2.5
Added file: http://bugs.python.org/file9862/test.py

__
Tracker <[EMAIL PROTECTED]>

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

[issue2489] Patch for bugs in pty.py

[Fergus Henderson]

Fergus Henderson <[EMAIL PROTECTED]> added the comment:

On Tue, Mar 25, 2008 at 9:22 PM, Guilherme Polo <[EMAIL PROTECTED]> wrote:
>
>  I would suggest using "if not data" to check for EOF

Good idea.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2489] Patch for bugs in pty.py

[Guilherme Polo]

Guilherme Polo <[EMAIL PROTECTED]> added the comment:

Hi Fergus,

I would suggest using "if not data" to check for EOF

--
nosy: +gpolo

__
Tracker <[EMAIL PROTECTED]>

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

[issue2489] Patch for bugs in pty.py

[Fergus Henderson]

New submission from Fergus Henderson <[EMAIL PROTECTED]>:

The attached patch fixes some bugs in the pty.py module:

  - spawn() would not wait for the invoked process to finish.
Also, it did not return a meaningful value, so there was no way
to tell if the invoked process failed.After this patch,
spawn() now waits for the invoked process, and returns the value
returned from os.waitpid().

  - There was a bug in the _copy() loop that caused it to spin
using 100% CPU rather than blocking after EOF was reached on
one of the two file descriptors that it was waiting for.

--
components: Library (Lib)
files: pty.py.patch
keywords: patch
messages: 64533
nosy: fergushenderson
severity: normal
status: open
title: Patch for bugs in pty.py
type: behavior
versions: Python 2.4, Python 2.5, Python 2.6, Python 3.0
Added file: http://bugs.python.org/file9861/pty.py.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2487] ldexp(x,n) misbehaves when abs(n) is large

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

I agree that the second and fourth cases are bugs.

The second case looks like a Windows only problem:  I get the expected 
OverflowError on both OS X 10.5.2/Intel and SuSE Linux 10.2/i686.

The fourth case is cross-platform, and occurs also for large exponents:

>>> ldexp(1.234, maxint+1)
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: long int too large to convert to int

It's still present in Python 3.0.

I'll take a look.

--
versions: +Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue2486] Consider using bytes type instead of str to store Decimal coefficients

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

Here's a first try at a patch that converts the Decimal coefficient
from type str to type bytes.  It needs some work:  here are some timings 
for a complete run of the test suite (best of 3 in each case) on my
MacBook.

Python 3.0, str:   12.880s
Python 3.0, bytes: 13.294s
Python 2.6: 9.279s
Python 2.5: 9.212s

There's still some room for speedup with the bytes patch, but at the 
moment it doesn't look as though performance alone is a compelling reason 
to make this change.

--
keywords: +patch
Added file: http://bugs.python.org/file9860/decimal_bytes.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2488] Backport sys.maxsize to Python 2.6

[Ryan Freckleton]

Ryan Freckleton <[EMAIL PROTECTED]> added the comment:

Here's a patch including docstring and NEWS update for this backport.

--
keywords: +patch
nosy: +ryan.freckleton
Added file: http://bugs.python.org/file9859/patch.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2487] ldexp(x,n) misbehaves when abs(n) is large

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

ldexp(1.234, maxint) works as expected in our trunk-math branch.
ldexp(1.234, -maxint-2) fails with the same error message.

--
assignee:  -> marketdickinson
nosy: +marketdickinson, tiran
priority:  -> normal
versions: +Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue2488] Backport sys.maxsize to Python 2.6

[Christian Heimes]

New submission from Christian Heimes <[EMAIL PROTECTED]>:

See topic

--
components: Extension Modules
keywords: 26backport, easy
messages: 64528
nosy: tiran
priority: high
severity: normal
status: open
title: Backport sys.maxsize to Python 2.6
type: feature request
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue2487] ldexp(x,n) misbehaves when abs(n) is large

[Fredrik Johansson]

New submission from Fredrik Johansson <[EMAIL PROTECTED]>:

Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import ldexp
>>> from sys import maxint

>>> ldexp(1.234, maxint//2)
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: math range error

>>> ldexp(1.234, maxint)
0.0

>>> ldexp(1.234, -maxint)
0.0

>>> ldexp(1.234, -maxint-2)
Traceback (most recent call last):
  File "", line 1, in 
OverflowError: long int too large to convert to int

The first and third cases seem right.

The second is clearly a bug.

In the fourth case, it would be more correct to return 0.0 than to raise
an exception IMHO.

--
components: Library (Lib)
messages: 64527
nosy: fredrikj
severity: normal
status: open
title: ldexp(x,n) misbehaves when abs(n) is large
type: behavior
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue2470] Need fixer for dl (removed) -> ctypes module

[Thomas Heller]

Thomas Heller <[EMAIL PROTECTED]> added the comment:

Thomas Heller schrieb:
> Thomas Heller <[EMAIL PROTECTED]> added the comment:
> 
>> In the simplest case, convert
>> 
>> import dl
>> libc = dl.open("libc.so.6")
>> iconv = libc.call("iconv_open", "ISO-8859-1", "ISO-8859-2")
>> print(iconv)
>> 
>> to
>> 
>> import ctypes
>> libc = ctypes.CDLL("libc.so.6")
>> iconv = libc.iconv_open("ISO-8859-1", "ISO-8859-2")
>> print(iconv)
>> 

Currently, in py3k, ctypes only passed bytes objects as char*; so
the strings should be translated to bytes literals:

import ctypes
libc = ctypes.CDLL("libc.so.6")
iconv = libc.iconv_open(b"ISO-8859-1", b"ISO-8859-2")
#   ^  ^
print(iconv)

__
Tracker <[EMAIL PROTECTED]>

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

[issue2457] add --help and -h options to pdb

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
assignee: benjamin.peterson -> georg.brandl
nosy: +georg.brandl

__
Tracker <[EMAIL PROTECTED]>

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

[issue2457] add --help and -h options to pdb

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
assignee:  -> benjamin.peterson
priority:  -> low

__
Tracker <[EMAIL PROTECTED]>

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

[issue2481] locale.strxfrm does not work with Unicode strings

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

Sure, although it probably shouldn't be backported to 2.5.

--
versions: +Python 2.6 -Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue2443] uninitialized access to va_list

[Rolland Dudemaine]

Rolland Dudemaine <[EMAIL PROTECTED]> added the comment:

This is what I meant. The initialization should be done by calling 
va_start(count_va); as you described.
In the files and lines I reported though, this is not called.
I'll file a patch for it soon.
--Rolland Dudemaine

Alexander Belopolsky wrote:
> Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:
>
> This is not a bug.  All the reported functions expect va_list argument
> to be initialized before being called.  AFAICT, they are consistently
> used in this way.  For example,
>
> PyObject *
> PyObject_CallFunctionObjArgs(PyObject *callable, ...)
> {
> PyObject *args, *tmp;
> va_list vargs;
>
> if (callable == NULL)
> return null_error();
>
> /* count the args */
> va_start(vargs, callable);
> args = objargs_mktuple(vargs);
> va_end(vargs);
> if (args == NULL)
> return NULL;
> tmp = PyObject_Call(callable, args, NULL);
> Py_DECREF(args);
>
> return tmp;
> }
>
> This may need to be clarified in the docs.  For example, PyString_FromFormatV 
> does not mention that vargs needs to be
> initialized:  api/string.html#PyString_FromFormatV>.  On the other hand, this may be
> obvious to most C programmers.
>
> I suggest to close this issue as invalid.
>
> --
> nosy: +belopolsky
>
> __
> Tracker <[EMAIL PROTECTED]>
> 
> __
>

--
title: Define Py_VA_COPY macro as a cross-platform replacement for gcc 
__va_copy -> uninitialized access to va_list

__
Tracker <[EMAIL PROTECTED]>

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

[issue2482] Decimal(unicode)

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

The original bug here is fixed, so I'm closing this issue.  I've opened
a separate issue (issue 2486) for discussing changing the Decimal 
coefficient from str to bytes.

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue2486] Consider using bytes type instead of str to store Decimal coefficients

[Mark Dickinson]

New submission from Mark Dickinson <[EMAIL PROTECTED]>:

The Python 3.0 version of decimal.py currently stores the coefficient of
a Decimal number (or the payload of a NaN) as a string, all of whose
characters are in the range '0' through '9'.

It may be more time-efficient to store the coefficient as a bytes 
instance instead, since bytes -> int conversion is likely to be faster 
than str -> int conversion.  On the other hand, int -> bytes conversion 
has to go through str, so may be significantly slower than int -> str 
conversion...

Bottom line:  this needs testing.

One other option:  it may even be worth considering storing the 
coefficient directly as a Python integer.  I've argued against this 
before, on the basis that it makes direct access to the decimal digits 
of a number harder, and this direct access is useful for rounding as 
well as for some of the more esoteric Decimal operations (logical 
operations, shifts and rotations).  But it may be worth a look.

(I think it's clear what the *right* option is, given unlimited 
developer time and energy:  decimal.py should represent the coefficient 
using a long integer implementation written in C, with wordsize a power 
of 10---probably either 10**4 or 10**9.)

See related discussion at issue 2482 and at

http://mail.python.org/pipermail/python-dev/2008-March/078189.html

--
components: Library (Lib)
messages: 64521
nosy: facundobatista, marketdickinson, ncoghlan
severity: normal
status: open
title: Consider using bytes type instead of str to store Decimal coefficients
type: performance
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue2390] Merge 2.6 ACKS with 3.0 ACKS

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

On Tue, Mar 25, 2008 at 4:29 PM, Christian Heimes <[EMAIL PROTECTED]>
wrote:

>
> Christian Heimes <[EMAIL PROTECTED]> added the comment:
>
> Are you absolutely sure you have used "svn copy"? The logs don't show a
> svn copy.

Oh, no. I copied with cp, so svn doesn't know about it.

>
>
> __
> Tracker <[EMAIL PROTECTED]>
> 
> __
>

Added file: http://bugs.python.org/file9858/unnamed

__
Tracker <[EMAIL PROTECTED]>

__On Tue, Mar 25, 2008 at 4:29 PM, Christian 
Heimes [EMAIL PROTECTED]> 
wrote:

Christian Heimes [EMAIL 
PROTECTED]> added the comment:

Are you absolutely sure you have used "svn copy"? The logs don't 
show a
svn copy.Oh, no. I copied with cp, so svn doesn't know 
about it. 


__
Tracker [EMAIL PROTECTED]>
http://bugs.python.org/issue2390>
__
-- Cheers,Benjamin Peterson
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2390] Merge 2.6 ACKS with 3.0 ACKS

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

Are you absolutely sure you have used "svn copy"? The logs don't show a
svn copy.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2481] locale.strxfrm does not work with Unicode strings

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Can it be backported?

--
nosy: +benjamin.peterson

__
Tracker <[EMAIL PROTECTED]>

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

[issue2390] Merge 2.6 ACKS with 3.0 ACKS

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


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

__
Tracker <[EMAIL PROTECTED]>

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

[issue2485] Traceback changed in 2.6 for unhashable objects

[Martin Geisler]

New submission from Martin Geisler <[EMAIL PROTECTED]>:

The traceback message given when trying to hash unhashable objects has
changed from Python 2.5 to 2.6:

Python 2.5.2a0 (r251:54863, Feb 10 2008, 01:31:28) 
>>> hash([])
Traceback (most recent call last):
  File "", line 1, in 
TypeError: list objects are unhashable

Python 2.6a1 (r26a1:61143, Mar 25 2008, 19:41:30) 
>>> hash([])
Traceback (most recent call last):
  File "", line 1, in 
TypeError: unhashable type: 'list'

This breaks my Doctests unless I add a somewhat ugly "# doctest:
+IGNORE_EXCEPTION_DETAIL" comment, so if this is not done on purpose, I
would prefer Python 2.6 to output the same as 2.5.

--
messages: 64517
nosy: mg
severity: normal
status: open
title: Traceback changed in 2.6 for unhashable objects
type: behavior
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue2390] Merge 2.6 ACKS with 3.0 ACKS

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


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

__
Tracker <[EMAIL PROTECTED]>

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

[issue2481] locale.strxfrm does not work with Unicode strings

[Martin v. Löwis]

Martin v. Löwis <[EMAIL PROTECTED]> added the comment:

FWIW, this is fixed in Python 3.0.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2390] Merge 2.6 ACKS with 3.0 ACKS

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

On Tue, Mar 25, 2008 at 4:23 PM, Christian Heimes <[EMAIL PROTECTED]>
wrote:

>
> Christian Heimes <[EMAIL PROTECTED]> added the comment:
>
> I think I'll follow a different path here. I may end up with
>
> svn rm Misc/ACKS
> svn copy ../trunk/Misc/ACKS Misc/

That's what I did. They are exactly the same file.

>
>
> It should make future merges easier.
>
> __
> Tracker <[EMAIL PROTECTED]>
> 
> __
>

Added file: http://bugs.python.org/file9857/unnamed

__
Tracker <[EMAIL PROTECTED]>

__On Tue, Mar 25, 2008 at 4:23 PM, Christian 
Heimes [EMAIL PROTECTED]> 
wrote:

Christian Heimes [EMAIL 
PROTECTED]> added the comment:

I think I'll follow a different path here. I may end up with

svn rm Misc/ACKS
svn copy ../trunk/Misc/ACKS Misc/That's what I did. They 
are exactly the same file. 


It should make future merges easier.

__
Tracker [EMAIL PROTECTED]>
http://bugs.python.org/issue2390>
__
-- Cheers,Benjamin Peterson
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2390] Merge 2.6 ACKS with 3.0 ACKS

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

I think I'll follow a different path here. I may end up with

svn rm Misc/ACKS 
svn copy ../trunk/Misc/ACKS Misc/

It should make future merges easier.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2390] Merge 2.6 ACKS with 3.0 ACKS

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

On Tue, Mar 25, 2008 at 4:17 PM, Christian Heimes <[EMAIL PROTECTED]>
wrote:

>
> Christian Heimes <[EMAIL PROTECTED]> added the comment:
>
> For the record
>
> You don't have to merge changes from 2.6 to 3.0 manually. In fact you
> mustn't unless you explicitly block the revision with svnmerge.py. In
> general you submit a change to 2.6 and it gets merged into 3.0 later.

Thanks for the heads up. Should I block the revision then?

>
>
> __
> Tracker <[EMAIL PROTECTED]>
> 
> __
>

Added file: http://bugs.python.org/file9856/unnamed

__
Tracker <[EMAIL PROTECTED]>

__On Tue, Mar 25, 2008 at 4:17 PM, Christian 
Heimes [EMAIL PROTECTED]> 
wrote:

Christian Heimes [EMAIL 
PROTECTED]> added the comment:

For the record

You don't have to merge changes from 2.6 to 3.0 manually. In fact you
mustn't unless you explicitly block the revision with svnmerge.py. In
general you submit a change to 2.6 and it gets merged into 3.0 
later.Thanks for the heads up. Should I block the revision 
then? 


__
Tracker [EMAIL PROTECTED]>
http://bugs.python.org/issue2390>
__
-- 
Cheers,Benjamin Peterson
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue2390] Merge 2.6 ACKS with 3.0 ACKS

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

For the record

You don't have to merge changes from 2.6 to 3.0 manually. In fact you
mustn't unless you explicitly block the revision with svnmerge.py. In
general you submit a change to 2.6 and it gets merged into 3.0 later.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2390] Merge 2.6 ACKS with 3.0 ACKS

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Commited in r61913 and r61914.

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue2390] Merge 2.6 ACKS with 3.0 ACKS

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

Yes, please sync the ACKS files again.

--
assignee: tiran -> benjamin.peterson

__
Tracker <[EMAIL PROTECTED]>

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

[issue2026] test_largefile.py converted to unittest

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
resolution:  -> accepted
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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

[issue2390] Merge 2.6 ACKS with 3.0 ACKS

[Benjamin Peterson]

Benjamin Peterson <[EMAIL PROTECTED]> added the comment:

Since the ACKS have changed since I did this merge, shall I remerge and
commit the changes to both branches?

__
Tracker <[EMAIL PROTECTED]>

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

[issue2196] Fix hasattr's exception problems

[Benjamin Peterson]

Changes by Benjamin Peterson <[EMAIL PROTECTED]>:


--
priority:  -> normal

__
Tracker <[EMAIL PROTECTED]>

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

[issue2477] parser support for future import of unicode_strings

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

Slightly better patch

* removed bzr hack
* simplified parsestr()
* updated NEWS

Added file: http://bugs.python.org/file9855/unicode_literals2.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2477] parser support for future import of unicode_strings

[Christian Heimes]

Changes by Christian Heimes <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file9846/unicode_literals.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue1251748] compiler package: "global a; a=5"

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

It seems to me that releasing it as a third-party package would be a
little contradictory, since the compiler package is supposed to follow
the CPython core (compile.c etc.) evolutions.

In any case, whatever the decision (stdlib package or separate
releases), I think it would be nice if there was a slightly more
comprehensive test suite. :)

Something like running some selected non-controversial parts of the test
suite compiled with the compiler package (like PyPy does apparently)
could be a good start.

_
Tracker <[EMAIL PROTECTED]>

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

[issue2459] speedup loops with better bytecode

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

By the way, the compiler package fix has been isolated and cleaned up as
part of #2472. Maybe it would be nice to start with that one.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2482] Decimal(unicode)

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

str -> unicode regression fixed in r61904, r61906.

(I backported the fix to 2.5;  it's not absolutely clear that it's worth 
it, but this *is* a bug, and it seems worth not letting the various 
decimal.py versions diverge too much.)

__
Tracker <[EMAIL PROTECTED]>

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

[issue2482] Decimal(unicode)

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

I'm not sure that converting to bytes for Python 3.0 is going to
be a simple change.  For one thing, most of the arithmetic functions
have to do the reverse conversion (int -> str/bytes) at some point.

At the moment, an int -> bytes conversion has to go through unicode (I 
think);  something like  bytes(str(n), 'ascii'), so it's not 100% clear
that replacing str with bytes is going to produce a speed gain.

For now, I'll get the fix for the 2.5/2.6 problem in (it only
involves changing 3 lines in decimal.py, along with adding a few
extra tests).

Changing str -> bytes in 3.0 needs more careful thought, and some 
benchmarking.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2483] int and float accept bytes, complex does not

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

For both these use cases, don't you still have a problem going
the other way, from an integer back to bytes? Is there an easier way
than

bytes(str(n), 'ascii')

?

__
Tracker <[EMAIL PROTECTED]>

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

[issue2459] speedup loops with better bytecode

[Fred L. Drake, Jr.]

Changes by Fred L. Drake, Jr. <[EMAIL PROTECTED]>:


__
Tracker <[EMAIL PROTECTED]>

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

[issue2459] speedup loops with better bytecode

[Fred L. Drake, Jr.]

Changes by Fred L. Drake, Jr. <[EMAIL PROTECTED]>:


__
Tracker <[EMAIL PROTECTED]>

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

[issue2443] Define Py_VA_COPY macro as a cross-platform replacement for gcc __va_copy

[Alexander Belopolsky]

Changes by Alexander Belopolsky <[EMAIL PROTECTED]>:


--
title: uninitialized access to va_list -> Define Py_VA_COPY macro as a 
cross-platform replacement for gcc __va_copy
type: compile error -> feature request

__
Tracker <[EMAIL PROTECTED]>

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

[issue2459] speedup loops with better bytecode

[Gregory P. Smith]

Changes by Gregory P. Smith <[EMAIL PROTECTED]>:


--
nosy: +gregory.p.smith

__
Tracker <[EMAIL PROTECTED]>

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

[issue2484] Cosmetic patch for warning "unused variable"

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

This seems to be already fixed in trunk. Can you confirm?

--
nosy: +georg.brandl

__
Tracker <[EMAIL PROTECTED]>

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

[issue2431] 2to3 is rather slow

[Collin Winter]

Collin Winter <[EMAIL PROTECTED]> added the comment:

The updated version of the patch passes the tests and yields a 19-20%
speed increase in the running time of test_all_fixers and the time taken
for 2to3 to translate itself. I've sent David some comments on the
patch, and once it's cleaned up some, this will be checked in.

I'd like to keep the issue open, since there are clearly additional
speed increases to be made.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2443] uninitialized access to va_list

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

Looks like a good idea to me

--
priority: high -> critical
resolution:  -> accepted

__
Tracker <[EMAIL PROTECTED]>

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

[issue2484] Cosmetic patch for warning "unused variable"

[Hirokazu Yamamoto]

New submission from Hirokazu Yamamoto <[EMAIL PROTECTED]>:

"int i,j;" in inner block is hiding "Py_ssize_t i,j;"

--
components: Extension Modules
files: fix_warning.patch
keywords: patch, patch
messages: 64499
nosy: ocean-city
severity: normal
status: open
title: Cosmetic patch for warning "unused variable"
versions: Python 3.0
Added file: http://bugs.python.org/file9854/fix_warning.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2483] int and float accept bytes, complex does not

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

I have a couple of use cases for bytes-as-ASCII-text -> int, one of
which also touches on floats. The other numeric types also accepting
bytes as representing ASCII encoded strings would then follow from a
consistency of behaviour argument.

Use case 1: Decimal implementation

The simplest way to retain the 2.x series decimal performance in 3.0 is
to switch the mantissa storage from a string to a bytes object. This is
only possible if the int constructor accepts bytes objects and treats
them as an ASCII-encoded string.



Use case 2: Serial protocols with embedded ASCII text

I work with a lot of control protocols for different pieces of hardware,
and one way the hardware vendors avoid having to write a custom control
interface for their hardware is to make their serial interface human
readable (so a terminal program like Hyperterminal or Miniterm becomes
their user interface). Writing automated control software for these
devices is essentially an exercise in screen-scraping the ASCII strings
received on the serial port. Having to go through Unicode to convert
ASCII digits embedded in these strings to numbers would be a major pain.
While these numbers are mostly integers, you do get the occasional
floating point value turning up as well, so bytes->float can also be useful.

--
nosy: +ncoghlan

__
Tracker <[EMAIL PROTECTED]>

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

[issue2477] parser support for future import of unicode_strings

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

> Also Christian - the posted patch accidentally included your hack to
make the version info a bit more non-SVN checkout friendly.

I'm still learning bzr. I just have figured out how to merge changes
from the upstream trunk into my branch. It's actually nice ...

__
Tracker <[EMAIL PROTECTED]>

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

[issue1251748] compiler package: "global a; a=5"

[Neil Schemenauer]

Neil Schemenauer <[EMAIL PROTECTED]> added the comment:

On Tue, Mar 25, 2008 at 09:18:38AM +, Armin Rigo wrote:
> The situation is that by now PyPy has found many many more bugs in
> trying to use the compiler package to run the whole stdlib and
> real-world applications.  What I can propose is to extract what we have
> got and put it back into CPython's stdlib, keeping the current
> documented API.

I'm not sure it can go back into the stdlib since there doesn't seem
to be enough energy available to keep it up-to-date with the Python
release schedule.  I would like to make it available as an add-on
package.

> This will require a little bit of work (e.g. first
> finishing to add all new 2.5 and 2.6 features into PyPy's compiler)
> but IMHO it's more worthwhile than going through the process of
> rediscovering and fixing all the current bugs one by one.

Indeed it would make no sense to redo that work.  Can the version in
the PyPy tree be used as a direct replacement for the stdlib version
or does it need some changes?  You had mentioned being able to
produce a patch against the stdlib version.  Is that easy or would
it be better just to take the PyPy version and package it up.

  Neil

_
Tracker <[EMAIL PROTECTED]>

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

[issue2431] 2to3 is rather slow

[David Wolever]

David Wolever <[EMAIL PROTECTED]> added the comment:

Ah, yea -- in my rush to catch my train I must have neglected to look at 
the _results_ of running test.py... I have updated the patch so the fixers 
will work.

Added file: http://bugs.python.org/file9853/fixer_head_node_lookup_2.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2483] int and float accept bytes, complex does not

[Mark Dickinson]

New submission from Mark Dickinson <[EMAIL PROTECTED]>:

In 3.0, the int and float constructors accepts bytes instances as well as 
strings:

>>> int(b'1')
1
>>> float(b'1')
1.0

but the complex constructor doesn't:

>>> complex(b'1')
Traceback (most recent call last):
  File "", line 1, in 
TypeError: complex() argument must be a string or a number

I'd suggest that at least one of these three results is a bug,
but I'm not sure which.

>From a purity point of view, I think int() and float() shouldn't accept 
bytes.  Is this a case of practicality beats purity?  What are the
pratical reasons to have int() and float() accept bytes?

Once this is resolved, the behaviors of Decimal and Fraction should also 
be considered.

--
components: Interpreter Core
messages: 64494
nosy: marketdickinson
severity: normal
status: open
title: int and float accept bytes, complex does not
type: behavior
versions: Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue2480] pickling of large recursive structures fails

[Daniel Darabos]

Daniel Darabos <[EMAIL PROTECTED]> added the comment:

Sidenote: If I click "edit" for nonrecursivepickler.py, I get told that
"File has been classified as spam." Strange. Should I not use Viagra as
a classname? :) (j/k I didn't do anything like that)

However I have now fixed a mistake in my code.

Added file: http://bugs.python.org/file9852/nonrecursivepickler-fixed.py

__
Tracker <[EMAIL PROTECTED]>

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

[issue1714] ConfigParser.py do not allow leading (and trailing) space in values.

[Ralf Schmitt]

Changes by Ralf Schmitt <[EMAIL PROTECTED]>:


--
nosy: +schmir

__
Tracker <[EMAIL PROTECTED]>

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

[issue2480] pickling of large recursive structures fails

[Ralf Schmitt]

Changes by Ralf Schmitt <[EMAIL PROTECTED]>:


--
nosy: +schmir

__
Tracker <[EMAIL PROTECTED]>

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

[issue2480] pickling of large recursive structures fails

[Daniel Darabos]

Changes by Daniel Darabos <[EMAIL PROTECTED]>:


Added file: http://bugs.python.org/file9851/picklertest.py

__
Tracker <[EMAIL PROTECTED]>

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

[issue2480] pickling of large recursive structures fails

[Daniel Darabos]

Daniel Darabos <[EMAIL PROTECTED]> added the comment:

So now I've learned that this is a result of the way Pickler is
implemented. I think that it would make sense to create an
implementation that is not that recursive and that would handle such
structures better.

I have now written one such implementation that is a subclass of the
original pickler and handles recursive data structures. I presume that
it is inferior in a couple of ways (performance and memory efficiency
probably), but a complete rewrite could probably create an
implementation that handles recursive data structures and is not inferior.

--
title: pickling of recursive sets of objects fails -> pickling of large 
recursive structures fails
Added file: http://bugs.python.org/file9850/nonrecursivepickler.py

__
Tracker <[EMAIL PROTECTED]>

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

[issue2478] decimal.Decimal( 0 ).sqrt() fails

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

It'd be nice to have it, but actually I'm not sure that this is doable
without some heavy editing of decimal's test framework.

Thanks!

--
nosy: +facundobatista

__
Tracker <[EMAIL PROTECTED]>

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

[issue2482] Decimal(unicode)

[Facundo Batista]

Facundo Batista <[EMAIL PROTECTED]> added the comment:

Decimal needs to grow something like the following near the top of the
module:

try:
  _bytes = bytes
except NameError: # 2.5 or earlier
  _bytes = str

and then use _bytes instead of str as appropriate throughout the rest of
the module.

This will solve the actual problem, and scales well with 2.6 and 3k.

--
nosy: +facundobatista

__
Tracker <[EMAIL PROTECTED]>

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

[issue2431] 2to3 is rather slow

[Collin Winter]

Collin Winter <[EMAIL PROTECTED]> added the comment:

With the patch applied, all tests in test_fixers fail.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2482] Decimal(unicode)

[Mark Dickinson]

Changes by Mark Dickinson <[EMAIL PROTECTED]>:


--
assignee:  -> marketdickinson
nosy: +marketdickinson
versions: +Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue2482] Decimal(unicode)

[Oleg Broytmann]

New submission from Oleg Broytmann <[EMAIL PROTECTED]>:

Decimal(u'123').to_eng_string() returns unicode in Python 2.5.2. That's
probably due to the optimization in decimal module, after which decimal
stores coefficient (mantissa) as a str, and doesn't coerce input to str.

See the thread at
http://mail.python.org/pipermail/python-dev/2008-March/078189.html

--
components: Library (Lib)
messages: 64488
nosy: phd
severity: normal
status: open
title: Decimal(unicode)
type: behavior
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue2443] uninitialized access to va_list

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

On the second thought the macro dance highlighted by OP belongs to 
pyport.h.  Attached patch defines Py_VA_COPY macro and uses it to simplify   
va_list copying code.

--
keywords: +patch
Added file: http://bugs.python.org/file9849/issue2443.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2477] parser support for future import of unicode_strings

[Nick Coghlan]

Nick Coghlan <[EMAIL PROTECTED]> added the comment:

The patch actually isn't all that complicated - the main structural
change to make it possible to process the strings correctly is
converting the parser functions to have treat the flags argument as an
I/O variable, rather than just an input. Other than that, there are just
some fairly straightforward updates to the compiler to take advantage of
the additional flag information now available from the parser.

Being able to write significant pieces of code that run on both 2.6 and
3.0 without modification will be a big win in my opinion. While 2to3
will still be a valuable migration tool, especially for one-way
migrations, it will be far far easier to support 2.6 and 3.0 in parallel
if that pseudo-compilation step isn't necessary.

Also Christian - the posted patch accidentally included your hack to
make the version info a bit more non-SVN checkout friendly.

--
nosy: +ncoghlan

__
Tracker <[EMAIL PROTECTED]>

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

[issue2481] locale.strxfrm does not work with Unicode strings

[Georg Brandl]

Changes by Georg Brandl <[EMAIL PROTECTED]>:


--
assignee:  -> loewis
nosy: +loewis

__
Tracker <[EMAIL PROTECTED]>

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

[issue1714] ConfigParser.py do not allow leading (and trailing) space in values.

[Quentin Gallet-Gilles]

Changes by Quentin Gallet-Gilles <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file9217/cfgparser_doublequotes.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2478] decimal.Decimal( 0 ).sqrt() fails

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

Fixed in r61892 (2.6) and r61893 (2.5).  Thanks for the report!

This bug exposes a flaw in the decimal testsuite:  the thousands of 
testcases in Lib/test/decimaltestdata are only ever run with an explicitly 
given context.  Would it be worth having an option to run (almost all) 
these tests with an implicit context as well, or even to
do this by default in addition to the explicit context testing?

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue2481] locale.strxfrm does not work with Unicode strings

[Christoph Zwerschke]

New submission from Christoph Zwerschke <[EMAIL PROTECTED]>:

While locale.strcoll seems to work with Unicode strings, locale.strxfrm
gives a UnicodeError. Example:

###

try:
locale.setlocale(locale.LC_ALL, 'de')
except locale.Error: # Windoof
locale.setlocale(locale.LC_ALL, 'german')

s = ['Ägypten', 'Zypern']

print sorted(s, cmp=locale.strcoll) # works
print sorted(s, key=locale.strxfrm) # works

s = [u'Ägypten', u'Zypern']

print sorted(s, cmp=locale.strcoll) # works
print sorted(s, key=locale.strxfrm) # UnicodeError

###

Therefore, it is not possible to sort lists of Unicode strings
effectively. If possible, this should be fixed. If not possible, this
problem should at least be mentioned in the documentation. Currently,
the docs do not indicate that strcoll and strxfrm behave differently
concerning Unicode.

--
components: Unicode
messages: 64484
nosy: cito
severity: normal
status: open
title: locale.strxfrm does not work with Unicode strings
type: behavior
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue2443] uninitialized access to va_list

[Alexander Belopolsky]

Alexander Belopolsky <[EMAIL PROTECTED]> added the comment:

This is not a bug.  All the reported functions expect va_list argument 
to be initialized before being called.  AFAICT, they are consistently 
used in this way.  For example,

PyObject *
PyObject_CallFunctionObjArgs(PyObject *callable, ...)
{
PyObject *args, *tmp;
va_list vargs;

if (callable == NULL)
return null_error();

/* count the args */
va_start(vargs, callable);
args = objargs_mktuple(vargs);
va_end(vargs);
if (args == NULL)
return NULL;
tmp = PyObject_Call(callable, args, NULL);
Py_DECREF(args);

return tmp;
}

This may need to be clarified in the docs.  For example, PyString_FromFormatV 
does not mention that vargs needs to be 
initialized: .  On the other hand, this may be 
obvious to most C programmers.

I suggest to close this issue as invalid.

--
nosy: +belopolsky

__
Tracker <[EMAIL PROTECTED]>

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

[issue2478] decimal.Decimal( 0 ).sqrt() fails

[Mark Dickinson]

Changes by Mark Dickinson <[EMAIL PROTECTED]>:


--
versions: +Python 2.6, Python 3.0

__
Tracker <[EMAIL PROTECTED]>

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

[issue1524825] ConfigParser: accept leading whitespace on options+comments

[Quentin Gallet-Gilles]

Quentin Gallet-Gilles <[EMAIL PROTECTED]> added the comment:

Didn't think "a few days" would translate into a month. My bad!

Anyway, here's the promised patch.

--
keywords: +patch
Added file: http://bugs.python.org/file9848/cfgparser_comments.patch

_
Tracker <[EMAIL PROTECTED]>

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

[issue2480] pickling of recursive sets of objects fails

[Daniel Darabos]

New submission from Daniel Darabos <[EMAIL PROTECTED]>:

In the attached demo I create a graph of 250 nodes, all of which are
connected to every other node, and this is represented by a set
attribute of the Node objects.

When I try to pickle this graph, it fails in various ways. In regular
pickle it is always a "maximum recursion depth exceeded" error. In
cPickle it is either a KeyError or a silent termination of the process.
(As tested on Windows XP 32 bits.) It depends on the size of the graph.
For smaller graphs (say 100 nodes) it works fine.

If connections are described using a dictionary or even a list, I get
the same errors.

--
components: Library (Lib)
files: bugdemo.py
messages: 64481
nosy: cyhawk
severity: normal
status: open
title: pickling of recursive sets of objects fails
versions: Python 2.5
Added file: http://bugs.python.org/file9847/bugdemo.py

__
Tracker <[EMAIL PROTECTED]>

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

[issue2478] decimal.Decimal( 0 ).sqrt() fails

[Mark Dickinson]

Mark Dickinson <[EMAIL PROTECTED]> added the comment:

I'll fix this.

--
nosy: +marketdickinson

__
Tracker <[EMAIL PROTECTED]>

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

[issue2477] parser support for future import of unicode_strings

[Ralf Schmitt]

Changes by Ralf Schmitt <[EMAIL PROTECTED]>:


--
nosy: +schmir

__
Tracker <[EMAIL PROTECTED]>

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

[issue2477] parser support for future import of unicode_strings

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

Working patch

I had to introduce yet another PyParser Ex method for string parsing. I
also renamed the future feature to "unicode_literals"

Added file: http://bugs.python.org/file9846/unicode_literals.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2478] decimal.Decimal( 0 ).sqrt() fails

[Georg Brandl]

Changes by Georg Brandl <[EMAIL PROTECTED]>:


--
assignee:  -> rhettinger
nosy: +rhettinger

__
Tracker <[EMAIL PROTECTED]>

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

[issue2026] test_largefile.py converted to unittest

[Giampaolo Rodola']

Giampaolo Rodola' <[EMAIL PROTECTED]> added the comment:

Uh! This report is still open.
Facundo could you close it? :)

__
Tracker <[EMAIL PROTECTED]>

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

[issue2477] parser support for future import of unicode_strings

[Marc-Andre Lemburg]

Marc-Andre Lemburg <[EMAIL PROTECTED]> added the comment:

The flag should be named "unicode_literals" since that what changes.
Unicode strings are already available in Python 2.x :-)

BTW: I'm not convinced that these future imports are all that useful -
the ratio between usefulness and added complexity leans a lot towards
the latter.

--
nosy: +lemburg

__
Tracker <[EMAIL PROTECTED]>

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

[issue2224] branches/trunk-math patch

[Christian Heimes]

Changes by Christian Heimes <[EMAIL PROTECTED]>:


Removed file: http://bugs.python.org/file9594/trunk-math.patch

__
Tracker <[EMAIL PROTECTED]>

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

[issue2224] branches/trunk-math patch

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

Merge Mark's and my math branch into 2.6. IMHO it's ready and stable but
I like to get the opinion of yet another core developer first.

Merge recipe


Since svnmerge.py causes too many conflicts I've created a patch.
However the patch doesn't include copied files from the trunk-math
branch. In order to apply the patch one has to copy some files from the
trunk-math branch into the trunk.

COPY: Python/pymath.c Include/pymath.h Lib/test/cmath_testcases.txt
Lib/test/ieee754.txt
DELETE: Python/hypot.c Objects/doubledigits.c

--
priority: high -> critical
Added file: http://bugs.python.org/file9845/trunk-math-integration.diff

__
Tracker <[EMAIL PROTECTED]>

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

[issue2479] Bytearray and io backport

[Christian Heimes]

New submission from Christian Heimes <[EMAIL PROTECTED]>:

Fix the remaining tests and merge the branch into 2.6

svn+ssh://[EMAIL PROTECTED]/python/branches/trunk-bytearray

So far 5 unit tests are failing. Two are related to pickling/copy and
two to subclassing.

--
components: Interpreter Core, Library (Lib), Tests
keywords: 26backport
messages: 64475
nosy: tiran
priority: critical
severity: normal
status: open
title: Bytearray and io backport
versions: Python 2.6

__
Tracker <[EMAIL PROTECTED]>

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

[issue1251748] compiler package: "global a; a=5"

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Armin, it would be nice to merge back your work indeed. If you submit a
patch I can take a look at it.

_
Tracker <[EMAIL PROTECTED]>

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

[issue2472] Fixed block ordering code in compiler.pyassem

[Antoine Pitrou]

Antoine Pitrou <[EMAIL PROTECTED]> added the comment:

Neal, I don't have sufficient permissions to assign bugs to anybody, but
here you are in the nosy list. :)

--
nosy: +nascheme

__
Tracker <[EMAIL PROTECTED]>

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

[issue2477] parser support for future import of unicode_strings

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

I've carefully examined both version. I agree that
update_flags_from_node is too fragile. I haven't verified my theory but
I *think* the current code does neither support

  from __future__ import egg, spam

nor

  from __future__ import egg
  from __future__ import spam

The PyParser_ParseFileFlagsEx() is easier and more stable. I'll go with it.

By the way I also like your name "unicode_strings". Should we stay with
it or use my idea "unicode_literals"?

__
Tracker <[EMAIL PROTECTED]>

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

[issue2478] decimal.Decimal( 0 ).sqrt() fails

[glathoud]

New submission from glathoud <[EMAIL PROTECTED]>:

I got a crash with Python 2.5.2 :

Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import decimal
>>> decimal.Decimal( 0 ).sqrt()
Traceback (most recent call last):
  File "", line 1, in 
  File "f:\Python25\lib\decimal.py", line 2330, in sqrt
return ans._fix(context)
  File "f:\Python25\lib\decimal.py", line 1461, in _fix
Etiny = context.Etiny()
AttributeError: 'NoneType' object has no attribute 'Etiny'

__
Tracker <[EMAIL PROTECTED]>

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

[issue2478] decimal.Decimal( 0 ).sqrt() fails

[glathoud]

Changes by glathoud <[EMAIL PROTECTED]>:


--
components: Library (Lib)
nosy: glathoud
severity: normal
status: open
title: decimal.Decimal( 0 ).sqrt()  fails
type: crash
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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

[issue1251748] compiler package: "global a; a=5"

[Armin Rigo]

Armin Rigo <[EMAIL PROTECTED]> added the comment:

Thanks Antoine for the clarification.

The situation is that by now PyPy has found many many more bugs in
trying to use the compiler package to run the whole stdlib and
real-world applications.  What I can propose is to extract what we have
got and put it back into CPython's stdlib, keeping the current
documented API.  This will require a little bit of work (e.g. first
finishing to add all new 2.5 and 2.6 features into PyPy's compiler)
but IMHO it's more worthwhile than going through the process of
rediscovering and fixing all the current bugs one by one.

_
Tracker <[EMAIL PROTECTED]>

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

[issue2477] parser support for future import of unicode_strings

[Eric Smith]

Changes by Eric Smith <[EMAIL PROTECTED]>:


--
nosy: +eric.smith

__
Tracker <[EMAIL PROTECTED]>

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

[issue2357] sys.exc_{type, values, traceback} should raise a Py3K warning

[Jack Diederich]

Jack Diederich <[EMAIL PROTECTED]> added the comment:

+1, I'll burn my _apply_evil(ModuleObject *) function patch to
moduleobject.c which did a memcpy on a type object and several other
heresies.

On Tue, Mar 25, 2008 at 4:27 AM, Brett Cannon <[EMAIL PROTECTED]> wrote:
>
>  Brett Cannon <[EMAIL PROTECTED]> added the comment:
>
>  I agree with Georg; a 2to3 fixer is enough.
>
>
>
>  __
>  Tracker <[EMAIL PROTECTED]>
>  
>  __
>

__
Tracker <[EMAIL PROTECTED]>

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

[issue2477] parser support for future import of unicode_strings

[Christian Heimes]

Christian Heimes <[EMAIL PROTECTED]> added the comment:

I'll check it out today.

--
assignee:  -> tiran
nosy: +tiran

__
Tracker <[EMAIL PROTECTED]>

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

[issue2470] Need fixer for dl (removed) -> ctypes module

[Thomas Heller]

Thomas Heller <[EMAIL PROTECTED]> added the comment:

> In the simplest case, convert
> 
> import dl
> libc = dl.open("libc.so.6")
> iconv = libc.call("iconv_open", "ISO-8859-1", "ISO-8859-2")
> print(iconv)
> 
> to
> 
> import ctypes
> libc = ctypes.CDLL("libc.so.6")
> iconv = libc.iconv_open("ISO-8859-1", "ISO-8859-2")
> print(iconv)
> 
> Notice that .call has up to 11 arguments, the first one being
> the function name.
> 
> Thomas, is it the case that all calls to dl.call can be converted to a
> ctypes call without parameter conversion? dl supports these parameter
> types:
> - byte string, passed as char*
> - integers, passed as int
> - None, passed as NULL

Yes, this is correct.

__
Tracker <[EMAIL PROTECTED]>

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

[issue2476] optparse docs should mention %default being new in 2.4

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Fixed in r61882.

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

__
Tracker <[EMAIL PROTECTED]>

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

[issue2359] A Py3K warning for array.array.{read,write} is needed

[Georg Brandl]

Georg Brandl <[EMAIL PROTECTED]> added the comment:

Committed patch as r61881.

--
nosy: +georg.brandl
resolution:  -> accepted
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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