[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

[Stefan Krah]

Stefan Krah  added the comment:

> However, the new binary is still not able to start a new thread from the 
> thread module. 

Traceback?


mach/cthreads.h is only relevant for Hurd, as far as I can see. 


> configure:8572: cc +DD64 -I/home/r32813/local/include -o conftest -g
> -L/home/r32813/local/lib -L/home/r32813/Build/2.7.1/Python-2.7.1
> conftest.c -l nsl -lrt -ldld -ldl  -lpthread >&5

Result of this test?

--
nosy: +skrah

___
Python tracker 

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

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

[Wong Wah Meng]

Wong Wah Meng  added the comment:

Traceback?

$ python
Python 2.7.1 (r271:86832, Sep 28 2011, 17:31:02) [C] on hp-ux11
Type "help", "copyright", "credits" or "license" for more information.
>>> import thread
>>> def testing():
...print "Hello World"
... 
>>> thread.start_new_thread(testing, ())  
Traceback (most recent call last):
  File "", line 1, in 
thread.error: can't start new thread
>>>

mach/cthreads.h is only relevant for Hurd, as far as I can see. 

I am not sure what Hurd is. So I should not be looking at this one I guess. 

> configure:8572: cc +DD64 -I/home/r32813/local/include -o conftest -g
> -L/home/r32813/local/lib -L/home/r32813/Build/2.7.1/Python-2.7.1
> conftest.c -l nsl -lrt -ldld -ldl  -lpthread >&5

Result of this test?

configure:8556: checking for pthread_create in -lpthread
configure:8572: cc +DD64 -I/home/r32813/local/include -o conftest -g  
-L/home/r32813/local/lib -L/home/r32813/Build/2.7.1/Python-2.7.1 conftest.
c -lnsl -lrt -ldld -ldl  -lpthread >&5
"conftest.c", line 97: warning #2223-D: function "exit" declared implicitly
  void * start_routine (void *arg) { exit (0); }
 ^

"conftest.c", line 102: error #2020: identifier "NULL" is undefined
  pthread_create (NULL, NULL, start_routine, NULL)
  ^

1 error detected in the compilation of "conftest.c".
configure:8572: $? = 2
configure: failed program was:
| /* confdefs.h */
| #define _GNU_SOURCE 1
| #define _NETBSD_SOURCE 1
| #define __BSD_VISIBLE 1
| #define _BSD_TYPES 1
--
nosy: +skrah

___
Python tracker 

___

--

___
Python tracker 

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

[issue11457] Expose nanosecond precision from system calls

[Ezio Melotti]

Changes by Ezio Melotti :


--
stage:  -> test needed

___
Python tracker 

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

[issue13058] Fix file descriptor leak on error

[Thomas Jarosch]

New submission from Thomas Jarosch :

Hi,

attached patch fixes a file descriptor leak on error.

Best regards,
Thomas Jarosch

--
components: Extension Modules
files: cpython-fix-file-descriptor-leak.patch
keywords: patch
messages: 144588
nosy: thomas.jarosch
priority: normal
severity: normal
status: open
title: Fix file descriptor leak on error
type: resource usage
versions: Python 3.4
Added file: 
http://bugs.python.org/file23256/cpython-fix-file-descriptor-leak.patch

___
Python tracker 

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

[issue13059] Sporadic test_multiprocessing failure: IOError("bad message length") in recv_bytes()

[STINNER Victor]

New submission from STINNER Victor :

[ 62/359] test_multiprocessing
Warning -- threading._dangling was modified by test_multiprocessing
Warning -- multiprocessing.process._dangling was modified by 
test_multiprocessing
test test_multiprocessing crashed -- Traceback (most recent call last):
  File "/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/regrtest.py", line 
1163, in runtest_inner
indirect_test()
  File 
"/var/lib/buildslave/3.x.murray-gentoo/build/Lib/test/test_multiprocessing.py", 
line 2349, in test_main
ManagerMixin.pool = ManagerMixin.manager.Pool(4)
  File 
"/var/lib/buildslave/3.x.murray-gentoo/build/Lib/multiprocessing/managers.py", 
line 670, in temp
token, exp = self._create(typeid, *args, **kwds)
  File 
"/var/lib/buildslave/3.x.murray-gentoo/build/Lib/multiprocessing/managers.py", 
line 568, in _create
conn = self._Client(self._address, authkey=self._authkey)
  File 
"/var/lib/buildslave/3.x.murray-gentoo/build/Lib/multiprocessing/connection.py",
 line 507, in Client
answer_challenge(c, authkey)
  File 
"/var/lib/buildslave/3.x.murray-gentoo/build/Lib/multiprocessing/connection.py",
 line 734, in answer_challenge
message = connection.recv_bytes(256) # reject large message
  File 
"/var/lib/buildslave/3.x.murray-gentoo/build/Lib/multiprocessing/connection.py",
 line 243, in recv_bytes
self._bad_message_length()
  File 
"/var/lib/buildslave/3.x.murray-gentoo/build/Lib/multiprocessing/connection.py",
 line 175, in _bad_message_length
raise IOError("bad message length")
IOError: bad message length

http://www.python.org/dev/buildbot/all/builders/x86%20Gentoo%203.x/builds/828/steps/test/logs/stdio

--
components: Library (Lib)
messages: 144589
nosy: haypo, neologix, pitrou
priority: normal
severity: normal
status: open
title: Sporadic test_multiprocessing failure: IOError("bad message length") in 
recv_bytes()
versions: Python 3.3

___
Python tracker 

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

[issue13060] make round() floating-point errors less hurtful

[Arne Babenhauserheide]

New submission from Arne Babenhauserheide :

Hi, 

I just stumbled over round() errors. I read the FAQ¹, and even though the FAQ 
states that this is no bug, its implementation is less than ideal. 

To illustrate: 

>>> round(0.5, 1)
0.0

and 

>>> round(5, -1)
0

This is mathematically wrong and hits for comparisions which humans put in. 

As alternate I use the following hack myself where ever I have to round 
numbers: 

def roundexact(a, *args): 
...  return round(a+0.001*max(1.0, (2*a)//10), *args)

This has correct behavior for *5 on my hardware: 

>>> roundexact(0.5, 0)
1.0

Its errors only appear in corner cases: 

>>> roundexact(0.4999, 0)
0.0
>>> roundexact(0.49998, 0)
1.0

This implementation shields me from implementation details of my hardware in 
all but very few extreme cases, while the current implementation of round() 
exhibits the hardware-imposed bugs in cases which actually matter to humans.

Maybe round could get a keyword argument roundup5 or such, which exhibits the 
behavior that any *5 number is rounded up.

Note: The decimal module is no alternative, because it is more than factor 100 
slower than floats (at least for simple computations): 

>>> from timeit import timeit
>>> timeit("float(1.0)+float(0.1)")
0.30365920066833496

>>> timeit("Decimal(1.0)+Decimal(0.1)", setup="from decimal import Decimal, 
>>> getcontext; getcontext().prec=17")
49.96972298622131

¹: http://docs.python.org/library/functions.html?highlight=round#round

--
components: Interpreter Core
messages: 144590
nosy: ArneBab
priority: normal
severity: normal
status: open
title: make round() floating-point errors less hurtful
versions: Python 3.2

___
Python tracker 

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

[issue13060] make round() floating-point errors less hurtful

[R. David Murray]

R. David Murray  added the comment:

Note that a C accelerator for Decimal is in the works.

--
nosy: +mark.dickinson, r.david.murray

___
Python tracker 

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

[issue13060] make round() floating-point errors less hurtful

[Arne Babenhauserheide]

Arne Babenhauserheide  added the comment:

Better comparision of decimal and float: 

>>> timeit("a+a", setup="from decimal import Decimal, getcontext; 
>>> getcontext().prec=17; a = Decimal(1.0)")
21.125790119171143
>>> timeit("a+a", setup="a = float(1.0)")
0.05324697494506836

--

___
Python tracker 

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

[issue13060] make round() floating-point errors less hurtful

[Arne Babenhauserheide]

Arne Babenhauserheide  added the comment:

If the C accelerator for decimal gets decimal performance close to floats 
(which I doubt, because it has to do much more), it could be very useful for 
me. What is its estimated time to completion?

Even when it is finished, it does not change the problem that round(0.5, 0) 
gives mathematically wrong results, so python requires hacks to be correct in 
this very simple case - instead of being right for most of the simple cases and 
only get it wrong in corner cases.

My hack isn’t really clean, though, because it depends on the internal 
representation of floats in the hardware. A real fix would have to get the real 
size of floats and adjust the added value accordingly.

--

___
Python tracker 

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

[issue13060] make round() floating-point errors less hurtful

[R. David Murray]

R. David Murray  added the comment:

It seems to me that saying "floating point" and "mathematically correct" in the 
same breath is...optimistic :)  But that's why I added Mark to nosy, he knows 
far more about this stuff than I do.

As far as I know the accelerator is feature complete at this point.  I think 
the goal is to ship it with 3.3, but I'm not sure where we are at in the 
process of making that a reality.

--
nosy: +skrah

___
Python tracker 

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

[issue13060] make round() floating-point errors less hurtful

[Mark Dickinson]

Mark Dickinson  added the comment:

> This is mathematically wrong ...

No, it's not 'mathematically wrong'.  There are many different rounding 
conventions in use, and no single universally agreed convention for rounding 
halfway cases.  Python chooses to use unbiased rounding[1] here, which matches 
the rounding used for all other basic arithmetic operations.

Other comments:

(1) I agree that round-half-up might be a useful convention to have available.  
But...

(2) Depending on any sort of predictable rounding behaviour for *decimal* 
halfway cases when using *binary* floats is fraught with peril.  If you really 
care about these halfway cases going in a particular direction (whether it's 
away from zero, towards +infinity, towards even, towards odd, etc.) then you 
should really be using Decimal.







[1] http://en.wikipedia.org/wiki/Rounding#Round_half_to_even

--

___
Python tracker 

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

[issue13060] make round() floating-point errors less hurtful

[Mark Dickinson]

Changes by Mark Dickinson :


--
type:  -> feature request
versions: +Python 3.3 -Python 3.2

___
Python tracker 

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

[issue13060] make round() floating-point errors less hurtful

[Mark Dickinson]

Mark Dickinson  added the comment:

Classifying this as a feature request:  the behaviour of round isn't going to 
change here, but there might be community support for adding a mechanism for 
round to allow other rounding modes.  It might be worth taking this to the 
python-ideas mailing list to hash out what that mechanism should be (extra 
keyword to round, ...).

--

___
Python tracker 

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

[issue13060] allow other rounding modes in round()

[Arne Babenhauserheide]

Arne Babenhauserheide  added the comment:

I did not know about rounding to even, so maybe there should be a warning in 
the 2.7 documentation, that the behavior changed in python 3 (I just checked 
that: python2.7 is in line with the documentation). 

The first time I stumbled over these issues was when implementing a game, where 
I wanted to map pixels to hexfields, where I had to get the borderline cases 
right: https://bitbucket.org/ArneBab/hexbattle/src/38ad49c04836/hexgrid.py#cl-24

This likely won’t hit me in the game, but it really hurts in the doctests.

PS: I like the naming as “allow other rounding modes”, so I changed the title 
of the bug. I hope that’s OK.

PPS: Thank you for all your replies! The bugtracker feels really welcoming and 
helpful, even when reporting something as a bug, which is just a difference in 
goal definition. I hope it will turn out to be useful for the community!

--
title: make round() floating-point errors less hurtful -> allow other rounding 
modes in round()

___
Python tracker 

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

[issue13060] allow other rounding modes in round()

[Mark Dickinson]

Mark Dickinson  added the comment:

> maybe there should be a warning in the 2.7 documentation

Well, such a warning really belongs in the Python 3 documentation rather than 
the Python 2 documentation.  (Or at least, AFAIK that's the convention that's 
been followed to date:  the Python 2 docs don't 'know' about Python 3 in 
general.)

There's a note in the 'What's new in Python 3' documentation that covers this 
and other changes in round:

http://docs.python.org/dev/whatsnew/3.0.html#builtins

--

___
Python tracker 

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

[issue13060] allow other rounding modes in round()

[Stefan Krah]

Stefan Krah  added the comment:

> If the C accelerator for decimal gets decimal performance close to
> floats (which I doubt, because it has to do much more), it could be
> very useful for me. What is its estimated time to completion?


It is finished and awaiting review (See #7652). The version in

   http://hg.python.org/features/cdecimal#py3k-cdecimal

is the same as the version that will be released as cdecimal-2.3
in a couple of weeks.

Benchmarks for cdecimal-2.2 are over here:

http://www.bytereef.org/mpdecimal/benchmarks.html#pi-64-bit


Typically cdecimal is 2-3 times slower than floats. With
further aggressive optimizations one *might* get that down
to 1.5-2 times for a fixed width Decimal64 type, but this is
pure speculation at this point.

If you look at 
http://www.bytereef.org/mpdecimal/benchmarks.html#mandelbrot-64-bit ,
you'll see that the Intel library performs very well for that specific
type. Exact calculations are performed in binary, then converted to
decimal for rounding. Note that this strategy _only_ works for
relatively low precisions.

--

___
Python tracker 

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

[issue11457] os.stat(): add new fields to get timestamps as Decimal objects with nanosecond resolution

[STINNER Victor]

Changes by STINNER Victor :


--
title: Expose nanosecond precision from system calls -> os.stat(): add new 
fields to get timestamps as Decimal objects with nanosecond resolution

___
Python tracker 

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

[issue13061] Decimal module yields incorrect results when Python compiled with llvm

[Joshua Bleecher Snyder]

New submission from Joshua Bleecher Snyder :

When Python is compiled on OS X with llvm, the decimal module behaves 
erratically (simple calculations are wrong, most doctests fail). This was 
originally reported here:

http://stackoverflow.com/questions/7590137/dividing-decimals-yields-invalid-results-in-python-2-5-to-2-7

and the compiler dependency was tracked down here:

https://trac.macports.org/ticket/31444

Although it looks like MacPorts is going to force use of gcc, it'd still be 
better for Python to behave correctly when compiled with llvm.

Possibly related to http://bugs.python.org/issue11149?

--
assignee: ronaldoussoren
components: Build, Installation, Library (Lib), Macintosh
messages: 144604
nosy: josharian, ronaldoussoren
priority: normal
severity: normal
status: open
title: Decimal module yields incorrect results when Python compiled with llvm
type: behavior
versions: 3rd party, Python 2.6, Python 2.7

___
Python tracker 

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

[issue13062] Introspection generator and function closure state

[Nick Coghlan]

New submission from Nick Coghlan :

Based on the python-ideas thread about closures, I realised there are two 
features the inspect module could offer to greatly simplify some aspects of 
testing closure and generator behaviour:

  inspect.getclosure(func)
Returns a dictionary mapping closure references from the supplied function 
to their current values.

  inspect.getgeneratorlocals(generator)
Returns the same result as would be reported by calling locals() in the 
generator's frame of execution

The former would just involve syncing up the names on the code object with the 
cell references on the function object, while the latter would be equivalent to 
doing generator.gi_frame.f_locals with some nice error checking for when the 
generator's frame is already gone (or the supplied object isn't a generator 
iterator).

--
messages: 144606
nosy: ncoghlan
priority: normal
severity: normal
status: open
title: Introspection generator and function closure state
type: feature request

___
Python tracker 

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

[issue11457] os.stat(): add new fields to get timestamps as Decimal objects with nanosecond resolution

[Stefan Krah]

Stefan Krah  added the comment:

> BTW, what is the status of cdecimal?

I just wrote the same in another issue, but not everyone is subscribed
to that:

I think cdecimal is finished and production ready. The version in

http://hg.python.org/features/cdecimal#py3k-cdecimal

is the same as what will be released as cdecimal-2.3 in a couple of
weeks. cdecimal-2.3 has a monumental test suite against *both*
decimal.py and decNumber. The test suite no longer finds any
kind of (unknown) divergence between decimal.py, cdecimal and
decNumber.

Tests for cdecimal-2.3 have been running on 6 cores for more
than half a year.

In short, review would be highly welcome. ;)

--

___
Python tracker 

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

[issue13058] Fix file descriptor leak on error

[Roundup Robot]

Roundup Robot  added the comment:

New changeset dec00ae64ca8 by Charles-François Natali in branch '2.7':
Issue #13058: ossaudiodev: fix a file descriptor leak on error. Patch by Thomas
http://hg.python.org/cpython/rev/dec00ae64ca8

New changeset 160b52c9e8b3 by Charles-François Natali in branch '3.2':
Issue #13058: ossaudiodev: fix a file descriptor leak on error. Patch by Thomas
http://hg.python.org/cpython/rev/160b52c9e8b3

New changeset d8dc24c4e83d by Charles-François Natali in branch 'default':
Issue #13058: ossaudiodev: fix a file descriptor leak on error. Patch by Thomas
http://hg.python.org/cpython/rev/d8dc24c4e83d

--
nosy: +python-dev

___
Python tracker 

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

[issue13058] Fix file descriptor leak on error

[Charles-François Natali]

Charles-François Natali  added the comment:

Patch applied, thanks!

--
nosy: +neologix
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
versions: +Python 2.7, Python 3.2, Python 3.3 -Python 3.4

___
Python tracker 

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

[issue13060] allow other rounding modes in round()

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

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

[issue12746] normalization is affected by unicode width

[STINNER Victor]

STINNER Victor  added the comment:

Issue fixed in Python 3.3 by Martin, changesets 40cf7204ca2b and 50f008019213.

--
nosy: +loewis
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

[issue13054] sys.maxunicode value after PEP-393

[STINNER Victor]

STINNER Victor  added the comment:

As said on IRC, unicodesize and character_size should be 1 before the test is 
something like 'x'*1. Or you can just remove this constant, it's not very 
useful to have a constant equal to 1 :-)

--

___
Python tracker 

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

[issue13062] Introspection generator and function closure state

[Meador Inge]

Changes by Meador Inge :


--
components: +Library (Lib)
stage:  -> needs patch
versions: +Python 3.3

___
Python tracker 

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

[issue13062] Introspection generator and function closure state

[Meador Inge]

Changes by Meador Inge :


--
nosy: +meador.inge

___
Python tracker 

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

[issue13062] Introspection generator and function closure state

[Yury Selivanov]

Changes by Yury Selivanov :


--
nosy: +Yury.Selivanov

___
Python tracker 

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

[issue13063] test_concurrent_futures failures on Windows: IOError('[Errno 232] The pipe is being closed') on _send_bytes()

[STINNER Victor]

STINNER Victor  added the comment:

See also issue #13059.

--

___
Python tracker 

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

[issue13059] Sporadic test_multiprocessing failure: IOError("bad message length") in recv_bytes()

[STINNER Victor]

STINNER Victor  added the comment:

See also issue #13063.

--

___
Python tracker 

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

[issue13063] test_concurrent_futures failures on Windows: IOError('[Errno 232] The pipe is being closed') on _send_bytes()

[STINNER Victor]

New submission from STINNER Victor :

Re-running test 'test_concurrent_futures' in verbose mode
test_killed_child (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 
5.79s ok
test_map (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 3.63s ok
test_map_exception (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 
4.05s ok
test_map_timeout (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 
9.64s ok
test_shutdown_race_issue12456 
(test.test_concurrent_futures.ProcessPoolExecutorTest) ... 3.60s ok
test_submit (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 3.63s ok
test_submit_keyword (test.test_concurrent_futures.ProcessPoolExecutorTest) ... 
4.09s ok
test_map (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.13s ok
test_map_exception (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 
0.12s ok
test_map_submits_without_iteration 
(test.test_concurrent_futures.ThreadPoolExecutorTest)
Tests verifying issue 11777. ... 0.14s ok
test_map_timeout (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 
6.11s ok
test_shutdown_race_issue12456 
(test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.11s ok
test_submit (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 0.11s ok
test_submit_keyword (test.test_concurrent_futures.ThreadPoolExecutorTest) ... 
0.11s ok
test_all_completed (test.test_concurrent_futures.ProcessPoolWaitTests) ... 
3.74s ok
test_first_completed (test.test_concurrent_futures.ProcessPoolWaitTests) ... 
5.18s ok
test_first_completed_some_already_completed 
(test.test_concurrent_futures.ProcessPoolWaitTests) ... 5.02s ok
test_first_exception (test.test_concurrent_futures.ProcessPoolWaitTests) ... 
6.57s ok
test_first_exception_one_already_failed 
(test.test_concurrent_futures.ProcessPoolWaitTests) ... 6.37s ok
test_first_exception_some_already_complete 
(test.test_concurrent_futures.ProcessPoolWaitTests) ... 5.15s ok
test_timeout (test.test_concurrent_futures.ProcessPoolWaitTests) ... 10.94s ok
test_all_completed (test.test_concurrent_futures.ThreadPoolWaitTests) ... 0.12s 
ok
test_first_completed (test.test_concurrent_futures.ThreadPoolWaitTests) ... 
1.62s ok
test_first_completed_some_already_completed 
(test.test_concurrent_futures.ThreadPoolWaitTests) ... 1.61s ok
test_first_exception (test.test_concurrent_futures.ThreadPoolWaitTests) ... 
3.12s ok
test_first_exception_one_already_failed 
(test.test_concurrent_futures.ThreadPoolWaitTests) ... 2.10s ok
test_first_exception_some_already_complete 
(test.test_concurrent_futures.ThreadPoolWaitTests) ... 1.60s ok
test_timeout (test.test_concurrent_futures.ThreadPoolWaitTests) ... 6.12s ok
test_no_timeout (test.test_concurrent_futures.ProcessPoolAsCompletedTests) ... 
3.62s ok
test_zero_timeout (test.test_concurrent_futures.ProcessPoolAsCompletedTests) 
... 5.65s ok
test_no_timeout (test.test_concurrent_futures.ThreadPoolAsCompletedTests) ... 
0.12s ok
test_zero_timeout (test.test_concurrent_futures.ThreadPoolAsCompletedTests) ... 
2.11s ok
test_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_cancelled (test.test_concurrent_futures.FutureTests) ... ok
test_done (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_already_cancelled (test.test_concurrent_futures.FutureTests) 
... ok
test_done_callback_already_failed (test.test_concurrent_futures.FutureTests) 
... ok
test_done_callback_already_successful 
(test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_raises (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_with_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_done_callback_with_exception (test.test_concurrent_futures.FutureTests) 
... ok
test_done_callback_with_result (test.test_concurrent_futures.FutureTests) ... ok
test_exception_with_success (test.test_concurrent_futures.FutureTests) ... ok
test_exception_with_timeout (test.test_concurrent_futures.FutureTests) ... ok
test_repr (test.test_concurrent_futures.FutureTests) ... ok
test_result_with_cancel (test.test_concurrent_futures.FutureTests) ... ok
test_result_with_success (test.test_concurrent_futures.FutureTests) ... ok
test_result_with_timeout (test.test_concurrent_futures.FutureTests) ... ok
test_running (test.test_concurrent_futures.FutureTests) ... ok
test_context_manager_shutdown 
(test.test_concurrent_futures.ProcessPoolShutdownTest) ... 3.58s ok
test_del_shutdown (test.test_concurrent_futures.ProcessPoolShutdownTest) ... 
3.92s ok
test_interpreter_shutdown 
(test.test_concurrent_futures.ProcessPoolShutdownTest) ... 5.60s FAIL
test_processes_terminate (test.test_concurrent_futures.ProcessPoolShutdownTest) 
... 3.67s ok
test_run_after_shutdown (test.test_concurrent_futures.ProcessPoolShutdownTest) 
... 0.01s ok
test_context_manager_shutdown 
(test.test_concurrent_futures.ThreadPoolShutdownTest) ... 0.02s ok
test_del_shutdown (test.test_concurrent_futures.ThreadPoolShutdownTest) ... 
0.03s ok
test_interpreter_shutdown (test.test_concurren

[issue13061] Decimal module yields incorrect results when Python compiled with llvm

[Stefan Krah]

Stefan Krah  added the comment:

> Possibly related to http://bugs.python.org/issue11149?

Maybe I missed it in the links you gave, but that is easily
settled by compiling with and without -fwrapv.

--
nosy: +skrah

___
Python tracker 

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

[issue3130] In some UCS4 builds, sizeof(Py_UNICODE) could end up being more than 4.

[STINNER Victor]

STINNER Victor  added the comment:

The PEP 393 has been accepted: strings are now stored as PyUCS1*, PyUCS2* or 
PyUCS4*. The Py_UNICODE type still exist but is deprecated, and only used in 
the legacy API. Py_UNICODE is now always the wchar_t type, it cannot be 
unsigned int anymore. I hope that no platform chose to use wchar_t larger than 
32 bits. Let' close this issue.

--
resolution:  -> fixed
status: open -> closed
versions: +Python 3.3 -Python 2.6, Python 3.0

___
Python tracker 

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

[issue13060] allow other rounding modes in round()

[Arne Babenhauserheide]

Arne Babenhauserheide  added the comment:

cdecimal sounds great! when is it scheduled for inclusion?

--

___
Python tracker 

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

[issue13062] Introspection generator and function closure state

[Eric Snow]

Changes by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

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

[issue7652] Merge C version of decimal into py3k.

[Eric Snow]

Changes by Eric Snow :


--
nosy: +eric.snow

___
Python tracker 

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

[issue8654] Improve ABI compatibility between UCS2 and UCS4 builds

[STINNER Victor]

STINNER Victor  added the comment:

The PEP 393 has been accepted. There is no more narrow or wide build, 
Py_UNICODE is now always wchar_t.

We have also a stable ABI which doesn't depend on the internal stucture of 
Unicode strings.

In Python 3.2, the name of dynamic libraries is also different if the module 
was compiled in narrow or wide mode. See the PEP 3149.

I think that it is enough. Can we close the issue?

--

___
Python tracker 

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

[issue4489] shutil.rmtree is vulnerable to a symlink attack

[Ross Lagerwall]

Ross Lagerwall  added the comment:

Updated patch based on Eric's comments:
 Store _supports_safe_rmdir at the module level.
 Move imports up to module level
 Skip test on non-threading build

--
Added file: http://bugs.python.org/file23261/i4489_v4.patch

___
Python tracker 

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

[issue13054] sys.maxunicode value after PEP-393

[Antoine Pitrou]

Antoine Pitrou  added the comment:

I think there's no point in deprecating a function (or data) with a perfectly 
valid definition.
As for test_bigmem, better keep character_size hardwired to 1 (if all tests 
really use only ASCII chars, which I'm not sure they do).

--

___
Python tracker 

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

[issue13061] Decimal module yields incorrect results when Python compiled with llvm

[Joshua Bleecher Snyder]

Joshua Bleecher Snyder  added the comment:

>> Possibly related to http://bugs.python.org/issue11149?

> Maybe I missed it in the links you gave, but that is easily
> settled by compiling with and without -fwrapv.

Apologies -- I didn't do enough homework on this one. Yes, I can confirm that 
compiling with -fwrapv solves this issue. Not sure whether that makes this bug 
a straight duplicate of http://bugs.python.org/issue11149...

--

___
Python tracker 

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

[issue8654] Improve ABI compatibility between UCS2 and UCS4 builds

[Daniel Stutzbach]

Daniel Stutzbach  added the comment:

Gladly. :-)

--
resolution:  -> out of date
stage: patch review -> committed/rejected
status: open -> closed

___
Python tracker 

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

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

[Stefan Krah]

Stefan Krah  added the comment:

To me this looks like stdio.h should be included as well. Could
you try the patch?

--
keywords: +patch
Added file: http://bugs.python.org/file23262/issue-13057.diff

___
Python tracker 

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

[issue2799] Remove _PyUnicode_AsString(), rework _PyUnicode_AsStringAndSize(), add PyUnicode_AsChar()

[STINNER Victor]

STINNER Victor  added the comment:

The PEP 393 changed the API:

#define _PyUnicode_AsString PyUnicode_AsUTF8
#define _PyUnicode_AsStringAndSize PyUnicode_AsUTF8AndSize

--

___
Python tracker 

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

[issue13061] Decimal module yields incorrect results when Python compiled with llvm

[Ned Deily]

Changes by Ned Deily :


--
nosy: +ned.deily

___
Python tracker 

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

[issue1943] improved allocation of PyUnicode objects

[STINNER Victor]

STINNER Victor  added the comment:

The PEP 393 is based on the idea proposed in this issue (use only one memory 
block, not two), but also enhanced it to reduce more the memory using other 
technics:

 - use a different character type depending on the maximum character,
 - use a shorter structure for ASCII only strings

The PEP 393 has been accepted and merged into Python 3.3. So I consider this 
issue as done.

--
nosy: +haypo
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

[issue7330] PyUnicode_FromFormat: implement width and precision for %s, %S, %R, %V, %U, %A

[STINNER Victor]

STINNER Victor  added the comment:

Hum, the issue is still open, I will try to review it.

--

___
Python tracker 

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

[issue11574] TextIOWrapper: Unicode Fallback Encoding on Python 3.3

[STINNER Victor]

Changes by STINNER Victor :


--
title: Unicode Fallback Encoding on Python 3.3 -> TextIOWrapper: Unicode 
Fallback Encoding on Python 3.3

___
Python tracker 

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

[issue12632] Python 3 doesn't support cp65001 as the OEM code page

[STINNER Victor]

Changes by STINNER Victor :


--
title: Windows GPF with Code Page 65001 -> Python 3 doesn't support cp65001 as 
the OEM code page

___
Python tracker 

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

[issue12242] distutils2 environment marker for current compiler

[Roumen Petrov]

Roumen Petrov  added the comment:

What is result is i use GNU compiler by example with name 
arm-linux-androideabi-gcc  ?

--
nosy: +rpetrov

___
Python tracker 

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

[issue12242] distutils2 environment marker for current compiler

[Eli Collins]

Changes by Eli Collins :


Added file: http://bugs.python.org/file23263/ca53ff77ce6f.diff

___
Python tracker 

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

[issue12242] distutils2 environment marker for current compiler

[Eli Collins]

Eli Collins  added the comment:

Attached is a fourth revision (ca53ff77ce6f.diff). This covers the typos 
identified in the last review, but I'm submitting a new patch because I  ran a 
quick proofreading regexp, and identified a few more formatting mistakes.

--

___
Python tracker 

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

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

[STINNER Victor]

STINNER Victor  added the comment:

The PEP 393 has been accepted and merge into Python 3.3. Python 3.3 doesn't 
need the Py_UNICODE_NEXT macro anymore. But my macros (unicode_macros.patch) 
are still useful.

--
versions: +Python 3.2 -Python 3.3

___
Python tracker 

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

[issue10521] str methods don't accept non-BMP fillchar on a narrow Unicode build

[STINNER Victor]

STINNER Victor  added the comment:

This issue has been fixed in Python 3.3 thanks to the PEP 393.

--
nosy: +haypo

___
Python tracker 

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

[issue10521] str methods don't accept non-BMP fillchar on a narrow Unicode build

[Ezio Melotti]

Ezio Melotti  added the comment:

It can still be fixed on 2.7/3.2 though.

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

[issue10542] Py_UNICODE_NEXT and other macros for surrogates

[Ezio Melotti]

Ezio Melotti  added the comment:

Py_UNICODE_NEXT has been removed from 3.3 but it's still available and used in 
2.7/3.2 (even if it's private).  In order to fix #10521 on 2.7/3.2 the 
_Py_UNICODE_PUT_NEXT macro attached to this patch is required.

--
versions: +Python 3.3 -Python 3.2

___
Python tracker 

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

[issue12819] PEP 393 - Flexible Unicode String Representation

[STINNER Victor]

STINNER Victor  added the comment:

PEP 393 has been accepted and merged into Python 3.3.

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

[issue12819] PEP 393 - Flexible Unicode String Representation

[Ezio Melotti]

Changes by Ezio Melotti :


--
stage: patch review -> committed/rejected

___
Python tracker 

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

[issue12242] distutils2 environment marker for current compiler

[Eli Collins]

Eli Collins  added the comment:

> What is result is i use GNU compiler by example with name 
> arm-linux-androideabi-gcc  ?

If the executable is named "arm-linux-androideabi-gcc", the code would 
currently call "arm-linux-androideabi-gcc --version". If that resulted in (for 
example) "arm-linux-androideabi-gcc (Some/Platform 4.5.2-1) 4.5.2", then the 
version string returned for regexp matching would be "arm-linux-androideabi-gcc 
4.5.2".

While the patch was getting close to finished, if it seems like a useful idea 
to people, I could add a "--get-compiler-info" command to build_ext which would 
return the name of the active compiler, and the output of 
get_compiler_version().

--

___
Python tracker 

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

[issue13062] Introspection generator and function closure state

[Meador Inge]

Meador Inge  added the comment:

I'll take a shot and writing a patch for this one.  Nick, are the 
elements in 'co_freevars' and '__closures__' always expected to match
up?  In other words, is the 'closure' function below always expected to 
work (simplified; no error checking):

>>> def make_adder(x):
... def add(y):
... return x + y
... return add
... 
>>> def curry(func, arg1):
... return lambda arg2: func(arg1, arg2)
... 
>>> def less_than(a, b):
... return a < b
... 
>>> greater_than_five = curry(less_than, 5)
>>> def closure(func):
... vars = [var for var in func.__code__.co_freevars]
... values = [cell.cell_contents for cell in func.__closure__]
... return dict(zip(vars, values))
...
>>> inc = make_adder(1)
>>> print(closure(inc))
{'x': 1}
>>> print(closure(greater_than_five))
{'arg1': 5, 'func': }

?

--

___
Python tracker 

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

[issue13061] Decimal module yields incorrect results when Python compiled with llvm

[Stefan Krah]

Stefan Krah  added the comment:

It's more a straight duplicate of #12973, but the underlying cause
(signed integer overflow) is the same. For people who are finding
this via a search engine: A lot of bugs have been fixed in #12973,
but even if the test suite passes without -fwrapv it is *still* recommended to 
use -fwrapv.


Could anyone test if the attached patch works for llvm-gcc?

--
keywords: +patch
Added file: http://bugs.python.org/file23265/llvm-gcc-fwrapv.diff

___
Python tracker 

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

[issue13062] Introspection generator and function closure state

[Eric Snow]

Eric Snow  added the comment:

See:
http://hg.python.org/cpython/file/default/Include/funcobject.h#l34
http://hg.python.org/cpython/file/default/Objects/funcobject.c#l454


   454 /* func_new() maintains the following invariants for closures.  The
   455closure must correspond to the free variables of the code object.
   456 
   457if len(code.co_freevars) == 0:
   458closure = NULL
   459else:
   460len(closure) == len(code.co_freevars)
   461for every elt in closure, type(elt) == cell
   462 */

--

___
Python tracker 

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

[issue13061] Decimal module yields incorrect results when Python compiled with llvm

[Mark Dickinson]

Changes by Mark Dickinson :


--
nosy: +mark.dickinson

___
Python tracker 

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

[issue13064] Port codecs and error handlers to the new Unicode API

[STINNER Victor]

New submission from STINNER Victor :

We really need a new API for error handlers, using Python objects instead of 
Py_UNICODE* strings, and using code point indexes instead of UTF-16 unit 
indexes (index in the Py_UNICODE* object). It's also inefficient to encode to 
Py_UNICODE at the first encode/decode error.

I added private APIs, we may make them public:

 * _PyUnicode_AsASCIIString()
 * _PyUnicode_AsLatin1String()
 * _PyUnicode_AsUTF8String()

--

Martin answered me by mail:

Would you like to work on this? Some thoughts:

- encoding error handlers are easier than decoding, since the encoding
  error API uses Py_UNICODE* for almost no good reason (except to pass
  substrings into the exception object, which is better done with
  PyUnicode_Substring). Decoding has the issue that the error handler
  may produce a replacement string which then needs to be inserted into
  the output.

- for decoding, I suggest to duplicate the error handling utility
  function, into one that operates on Unicode objects only. Then port
  one codec at a time, and ultimately remove the then-unused Py_UNICODE
  function.

- adding an error handler result into a string may cause widening of the
  string. I can see two approaches:

  a) write decoders in Py_UCS4. This is perhaps best for the rarely-used
 codecs, such as UTF-7.
  b) write the codecs so that they do incremental widening. Start off
 with a Py_UCS1 buffer, and check each decoded character whether it
 is out of range. When you get an error handler result, check
 maxchar and widen the result accordingly.
  c) in principle, there is a third approach: run over the string once,
 collect all error handler results. Then allocate the output string,
 decode again, pasting the replacement strings into the output
 interleaved with regular decoded chars. This seems too complicated
 to implement.

--
components: Unicode
messages: 144639
nosy: haypo
priority: normal
severity: normal
status: open
title: Port codecs and error handlers to the new Unicode API
versions: Python 3.3

___
Python tracker 

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

[issue13064] Port codecs and error handlers to the new Unicode API

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti
stage:  -> needs patch
type:  -> feature request

___
Python tracker 

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

[issue13062] Introspection generator and function closure state

[Nick Coghlan]

Nick Coghlan  added the comment:

Yep, that looks right to me. The eval loop then references those cells from the 
frame object during execution.

--

___
Python tracker 

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

[issue13062] Introspection generator and function closure state

[Nick Coghlan]

Nick Coghlan  added the comment:

Huh, I didn't actually realise getclosure() could be written as a one liner 
until seeing Meador's version above:

  {var : cell.cell_contents for var, cell in zip(func.__code__.co_freevars, 
func.__closure__)}

--

___
Python tracker 

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

[issue2771] Test issue

[Victor Semionov]

Victor Semionov  added the comment:

Testing.

--
nosy: +vsemionov

___
Python tracker 

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

[issue2771] Test issue

[Victor Semionov]

Victor Semionov  added the comment:

testing

--
Added file: http://bugs.python.org/file23266/test.txt

___
Python tracker 

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

[issue2771] Test issue

[Victor Semionov]

Victor Semionov  added the comment:

adsfaf

--
hgrepos: +78

___
Python tracker 

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

[issue2771] Test issue

[Victor Semionov]

Changes by Victor Semionov :


--
hgrepos:  -78

___
Python tracker 

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

[issue11489] json.dumps not parsable by json.loads (on Linux only)

[Ezio Melotti]

Ezio Melotti  added the comment:

RFC 4627 doesn't say much about lone surrogates:
   A string is a sequence of zero or more Unicode characters [UNICODE].
   [...]

   All Unicode characters may be placed within the
   quotation marks except for the characters that must be escaped:
   quotation mark, reverse solidus, and the control characters (U+
   through U+001F).

   Any character may be escaped.  If the character is in the Basic
   Multilingual Plane (U+ through U+), then it may be
   represented as a six-character sequence: a reverse solidus, followed
   by the lowercase letter u, followed by four hexadecimal digits that
   encode the character's code point.  The hexadecimal letters A though
   F can be upper or lowercase.  So, for example, a string containing
   only a single reverse solidus character may be represented as
   "\u005C".
   [...]

   To escape an extended character that is not in the Basic Multilingual
   Plane, the character is represented as a twelve-character sequence,
   encoding the UTF-16 surrogate pair.  So, for example, a string
   containing only the G clef character (U+1D11E) may be represented as
   "\uD834\uDD1E".


Raymond> JSON is UTF-8 by definition and it is a useful feature that invalid 
UTF-8 won't load.

Even if the input strings are not encodable in UTF-8 because they contain lone 
surrogates, they can still be converted to an \u escape, and the resulting 
JSON document will be valid UTF-8.
AFAIK json always uses \u, so it doesn't produce invalid UTF-8 documents.

While decoding, both json.loads('"\xed\xa0\x80"') and json.loads('"\ud800"') 
result in u'\ud800', but the first is not a valid UTF-8 document because it 
contains an invalid UTF-8 byte sequence that represent a lone surrogate, 
whereas the second one contains only ASCII bytes and it's therefore valid.
Python 2.7 should probably reject '"\xed\xa0\x80"', but since its UTF-8 codec 
is somewhat permissive already, I'm not sure it makes much sense changing the 
behavior now.  Python 3 doesn't have this problem because it works only with 
unicode strings, so you can't pass invalid UTF-8 byte sequences.

OTOH the Unicode standard says that lone surrogates shouldn't be passed around, 
so we might decide to replace them with the replacement char U+FFFD, raise an 
error, or even provide a way to decide what should be done with them (something 
like the errors argument of codecs).

--

___
Python tracker 

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

[issue13065] test

[Victor Semionov]

New submission from Victor Semionov :

ignore me

--
messages: 144647
nosy: vsemionov
priority: normal
severity: normal
status: open
title: test

___
Python tracker 

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

[issue13065] test

[Victor Semionov]

Changes by Victor Semionov :


--
status: open -> closed

___
Python tracker 

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

[issue13066] test

[Victor Semionov]

New submission from Victor Semionov :

ignore me

--
components: IO, Interpreter Core
messages: 144648
nosy: vsemionov
priority: normal
severity: normal
status: open
title: test
type: crash
versions: Python 3.2

___
Python tracker 

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

[issue13066] test

[Victor Semionov]

Changes by Victor Semionov :


--
status: open -> closed

___
Python tracker 

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

[issue13065] test

[Ezio Melotti]

Changes by Ezio Melotti :


--
resolution:  -> invalid
stage:  -> committed/rejected

___
Python tracker 

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

[issue13066] test

[Ezio Melotti]

Changes by Ezio Melotti :


--
resolution:  -> invalid
stage:  -> committed/rejected

___
Python tracker 

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

[issue13067] test

[Victor Semionov]

New submission from Victor Semionov :

ignore me

--
components: IO, Interpreter Core
files: backtrace
messages: 144651
nosy: vsemionov
priority: normal
severity: normal
status: open
title: test
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file23269/backtrace

___
Python tracker 

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

[issue13067] test

[Victor Semionov]

Changes by Victor Semionov :


--
status: open -> closed

___
Python tracker 

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

[issue13061] Decimal module yields incorrect results when Python compiled with llvm

[Ned Deily]

Ned Deily  added the comment:

There is some confusion here, I think. As best as I can tell, the original 
problem reported in the Stackoverflow question and to MacPorts involved using 
the clang compiler, not llvm-gcc and the Decimal problem reported here was only 
ever a problem when using clang.  It's not an issue when using Apple's llvm-gcc 
compiler because the pre-#11149 configure test works properly with llvm-gcc.  
That test looks for "-fwrapv" in the compiler help string:

$ llvm-gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) 
(LLVM build 2335.15.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ llvm-gcc -v --help 2>/dev/null | grep -- -fwrapv
  -fwrapv Assume signed arithmetic overflow wraps around
$ gcc-4.2 --version
i686-apple-darwin11-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc-4.2 -v --help 2>/dev/null | grep -- -fwrapv
  -fwrapv Assume signed arithmetic overflow wraps around
$ clang --version
Apple clang version 2.1 (tags/Apple/clang-163.7.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.1.0
Thread model: posix
$ clang -v --help 2>/dev/null | grep -- -fwrapv

The above was using the 3 Apple-supplied compilers with the OS X 10.7 (Lion) 
version of Xcode 4.1 (Build version 4B110).  The 10.6 compiler versions should 
work the same way.

So this issue should be closed as a duplicate of Issue11149.  I'm setting it to 
pending and will close it if there are no objections.

--
resolution:  -> duplicate
status: open -> pending
superseder:  -> [PATCH] Configure should enable -fwrapv for clang

___
Python tracker 

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

[issue13068] test

[Victor Semionov]

New submission from Victor Semionov :

ignore me

--
messages: 144654
nosy: vsemionov
priority: normal
severity: normal
status: open
title: test
type: crash

___
Python tracker 

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

[issue13068] test

[Victor Semionov]

Changes by Victor Semionov :


--
status: open -> closed

___
Python tracker 

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

[issue13069] test

[Ezio Melotti]

New submission from Ezio Melotti :

Testing issue creation

--
hgrepos: 83
messages: 144655
nosy: ezio.melotti
priority: normal
severity: normal
status: open
title: test

___
Python tracker 

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

[issue13069] test

[Ezio Melotti]

Changes by Ezio Melotti :


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

___
Python tracker 

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

[issue13070] segmentation fault in pure-python multi-threaded server

[Victor Semionov]

New submission from Victor Semionov :

Hello,

I'm developing a multi-threaded TCP server and have been seeing segmentation 
faults on 3.2 on Linux and 3.2.2 on Windows. This happens when using only 
pure-Python libraries, so I believe the problem is in the interpreter. The 
issue is very easy to reproduce with my code, but I think it is obscure, 
because I have not been able to reproduce it with a smaller program.

Here's what happens. The server accepts TCP connections, and creates a thread 
for every new connection. When the client sends a request, the server initiates 
its own TCP connection to a database. If any socket IO operation fails by 
raising a socket error (e.g. the database is down), those errors are caught by 
the calling code, and it gracefully terminates the thread. However, when the 
next client connects and sends a request, even if the server-initiated 
connections are successfully established, the interpreter crashes a bit later 
during the processing of the client's request (I think during IO operations).

Strangely, this does not occur if the thread recovers and does not terminate 
after catching an exception (as the case with failed redis connections). Also, 
I was able to port my program to python 2.7, and it did not crash.

To reproduce, you will need pg8000, which is a pure-python dbapi driver. You 
will need to get my program, wordbase, from the mercurial repository at 
https://bitbucket.org/vsemionov/wordbase (changeset 31c6554e67ee) and edit 
src/wordbase/db/pgsql.py. Change "import psycopg2 as dbapi" to "import 
pg8000.dbapi as dbapi". This is just to ensure that no C-based library is used. 
Steps to reproduce:
0. Ensure postgres is not running
1. Start wordbase with src/wordbase/wordbase.py -f . Use the path to 
the provided sample conf file at src/wordbase/wordbase.conf. By default you'll 
need to be root, in order to be able to create a log file.
2. Connect a client with "telnet localhost 2628" and enter "d hello". This 
should fail with status 420. Reconnect and repeat the same step a couple of 
times. The interpreter usually crashes after repeating this step.

I'm providing the interpreter's backtrace, which is obtained from Python 3.2 on 
Linux. It is attached in a separate file.

If you need any other information, please let me know.

Best regards,
Victor Semionov

--
components: IO, Interpreter Core
files: backtrace
messages: 144656
nosy: vsemionov
priority: normal
severity: normal
status: open
title: segmentation fault in pure-python multi-threaded server
type: crash
versions: Python 3.2
Added file: http://bugs.python.org/file23270/backtrace

___
Python tracker 

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

[issue13068] test

[Ezio Melotti]

Changes by Ezio Melotti :


--
resolution:  -> invalid
stage:  -> committed/rejected

___
Python tracker 

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

[issue13067] test

[Ezio Melotti]

Changes by Ezio Melotti :


--
resolution:  -> invalid
stage:  -> committed/rejected

___
Python tracker 

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

[issue3232] Wrong str->bytes conversion in Lib/encodings/idna.py

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti

___
Python tracker 

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

[issue13072] Getting a buffer from a Unicode array uses invalid format

[STINNER Victor]

New submission from STINNER Victor :

In Python 3.2, when you get a buffer from array.array('u'), "u" is used as 
buffer format. The format is supposed to be a format from the struct module, 
and "u" is an invalid struct format. "w" is used on wide mode.

I just upgraded the array module to use the new Unicode API (PEP 393). The 
array now uses a Py_UCS4 buffer. I used "I" or "L" format depending on the size 
of int and long C types.

It would be better to use a format for a Py_UCS4 string, but struct doesn't 
support such type.

For Python 2.7 and 3.2, I don't know if it is really a bug or not.

--
components: Library (Lib)
messages: 144658
nosy: haypo, pitrou
priority: normal
severity: normal
status: open
title: Getting a buffer from a Unicode array uses invalid format
versions: Python 2.7, Python 3.2, Python 3.3

___
Python tracker 

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

[issue13071] IDLE refuses to open on windows 7

[jfalskfjdsl;akfdjsa;l laksfj;aslkfdj;sal]

New submission from jfalskfjdsl;akfdjsa;l laksfj;aslkfdj;sal 
:

I have tried all ways of opening IDLE and have uninstalled and reinstalled 
Python, but when I try to open it it crashes before anything happens

--
components: IDLE
messages: 144657
nosy: jfalskfjdsl;akfdjsa;l.laksfj;aslkfdj;sal
priority: normal
severity: normal
status: open
title: IDLE refuses to open on windows 7
type: crash
versions: Python 3.2

___
Python tracker 

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

[issue13071] IDLE refuses to open on windows 7

[Ezio Melotti]

Ezio Melotti  added the comment:

Try to open cmd (win+r -> type 'cmd' -> press enter), cd in the Python 
directory and do "python.exe Lib\idlelib\idle.py".
If that doesn't work it should give you a traceback.  Once you get the 
traceback copy/paste it here, so we can figure out what's going on.

--
nosy: +ezio.melotti

___
Python tracker 

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

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

[Wong Wah Meng]

Wong Wah Meng  added the comment:

Hello Stefan,

Hmm. how do I apply the patch? I download the issue-13057.diff file and 
then.? 

Regards,
Wah Meng

--

___
Python tracker 

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

[issue12737] str.title() is overzealous by upcasing combining marks inappropriately

[Ezio Melotti]

Ezio Melotti  added the comment:

After PEP 393 the result is still the same (I attached a slightly improved 
version of the script):

titlecase of  'deme un cafe'  should be  'Deme Un Cafe'  not  'DeMe Un Cafe'
titlecase of  'istanbul'  should be  'Istanbul'  not  'IStanbul'
titlecase of  'α στο διαολο'  should be  'Α Στο Διαολο'  not  'ΑΙ Στο ΔιαΟλο'
failed 3 out of 6 tests

Martin, do you think that str.title() should follow the Unicode standard?
Should string methods work with all the normalizations or just with NFC?

--
Added file: http://bugs.python.org/file23271/titletest.py

___
Python tracker 

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

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

[Ezio Melotti]

Ezio Melotti  added the comment:

"patch -p1 < issue-13057.diff" in the directory where configure is should do 
the trick.

--
nosy: +ezio.melotti

___
Python tracker 

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

[issue12731] python lib re uses obsolete sense of \w in full violation of UTS#18 RL1.2a

[Ezio Melotti]

Ezio Melotti  added the comment:

The failing re tests after PEP 393 are:
FAIL lib re found non alphanumeric string  'cafe'
FAIL lib re found non alphanumeric string  'Ⓚ'
FAIL lib re found non alphanumeric string  ''
FAIL lib re found non alphanumeric string  ''
FAIL lib re found non alphanumeric string  'connector‿punctuation'
FAIL lib re found non alphanumeric string  'Ὰ_Στο_Διάολο'
FAIL lib re found non alphanumeric string  '𐌰𐍄𐍄𐌰‿𐌿𐌽𐍃𐌰𐍂‿𐌸𐌿‿𐌹𐌽‿𐌷𐌹𐌼𐌹𐌽𐌰𐌼'
FAIL lib re found all alphanumeric string  '¹²³'
FAIL lib re found all alphanumeric string  '₁₂₃'
FAIL lib re found all alphanumeric string  '¼½¾'
FAIL lib re found all alphanumeric string  '⑶'

--

___
Python tracker 

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

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

[Wong Wah Meng]

Wong Wah Meng  added the comment:

I tried here is the outcome. It says it can't find a patch??

$ cat issue-13057.diff
diff -r f612b783bc17 configure
--- a/configure Thu Sep 29 07:52:46 2011 +0800
+++ b/configure Thu Sep 29 21:39:32 2011 +0200
@@ -8619,6 +8619,7 @@
 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 #include 
+#include 

 void * start_routine (void *arg) { exit (0); }
 int

$ patch -p1 < issue-13057.diff
Hmm...  I can't seem to find a patch in there anywhere.
$ pwd
/home/r32813/Build/2.7.1/Python-2.7.1
$

Regards,
Wah Meng

--

___
Python tracker 

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

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

[Ezio Melotti]

Ezio Melotti  added the comment:

If that's a Mercurial clone of Python you can try "hg import --no-commit 
issue-13057.diff".  Otherwise you could just edit configure manually -- the 
attached patch is trivial.  You could also install "patch".

--

___
Python tracker 

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

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

[Wong Wah Meng]

Wong Wah Meng  added the comment:

Mercurial clone of python? Haha I am not sure what that is. My unix also won't 
recognize "hg", and will ignore "import --no-commit issue-13057.diff".

I went ahead to edit configure file. Partially understanding the content of 
.diff file, I edited the configure and here is the difference...

I will try to rebuild now...

$ diff configure.original configure
8619a8620,8624
>  #include 
>  +#include 
> 
>   void * start_routine (void *arg) { exit (0); }
>int
$ 

Regards,
Wah Meng

--

___
Python tracker 

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

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

[Wong Wah Meng]

Wong Wah Meng  added the comment:

Hello,

I tried rebuild but it is still the same. :( Attached is the extract of the 
modified configure file, with line number at the side (from VI editor). 
Basically my changes are added as from line 8620 through 8624. I am not sure if 
this is meant to be, just my best guess from the patch file. Appreciate your 
advice. 

  8612  $as_echo_n "checking for pthread_create in -lpthreads... " >&6; }
  8613  if test "${ac_cv_lib_pthreads_pthread_create+set}" = set; then :
  8614$as_echo_n "(cached) " >&6
  8615  else
  8616ac_check_lib_save_LIBS=$LIBS
  8617  LIBS="-lpthreads  $LIBS"
  8618  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
  8619  /* end confdefs.h.  */
  8620   #include 
  8621   +#include 
  8622
  8623void * start_routine (void *arg) { exit (0); }
  8624 int
  8625
  8626  /* Override any GCC internal prototype to avoid an error.
  8627 Use char because int might match the return type of a GCC
  8628 builtin and then its argument prototype would still apply.  */
  8629  #ifdef __cplusplus
  8630  extern "C"
  8631  #endif

Regards,
Wah Meng
Genesis Wafermap Support Ticket: 
To report a problem: 
http://dyno.freescale.net/Question/QuestionMain3.asp?location=zmy02&category=&tickettype=6820
To request a service: 
http://dyno.freescale.net/Question/Questionmain3.asp?location=74&category=2&tickettype=6819
Or if it is related to EWM or DSA: 
http://dyno.freescale.net/Question/Questionmain3.asp?location=ZMY02&tickettype=6539

--

___
Python tracker 

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

[issue13057] Thread not working for python 2.7.1 built with HP Compiler on HP-UX 11.31 ia64

[Ezio Melotti]

Ezio Melotti  added the comment:

You just have to add:
#include 

just after:
#include 

The + in the diff only means that the line was added and shouldn't be included 
in the file.

--

___
Python tracker 

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