date:20100416


R. David Murray  added the comment:

That's because 7681 is closed.  (That said, I consider it a bug in the tracker 
that it defaults to searching only open issues...and I think I filed an issue 
in the metatracker for that, too.  Maybe I'll get around to fixing it if I can 
get agreement that fixing it is a good idea).  If you put the number in the 
'show issue' box it will show up.  You'll also note that it is now a clickable 
link in your message in the tracker.

But we really should move this discussion to tracker-discuss.

--

___
Python tracker 

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

[issue8424] tiger/FreeBSD7.2 buildbots: test_itimer_virtual failures


R. David Murray  added the comment:

The FreeBSD 7.2 buildbot also shows this failure.  See also issue 3864; 
although this failure appears to be slightly different, it might be due to a 
remnant of the same platform bug.  I'm making everyone from that bug nosy on 
this one.

--
components: +Tests
nosy: +aimacintyre, eric.smith, gpolo, mark.dickinson, r.david.murray
priority:  -> normal
stage:  -> needs patch
title: tiger buildbot: test_itimer_virtual failures -> tiger/FreeBSD7.2 
buildbots: test_itimer_virtual failures
type:  -> behavior
versions: +Python 2.6, Python 2.7, Python 3.1

___
Python tracker 

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

[issue8263] regrtest stops prematurately on FreeBSD buildbot, with "success" result.


R. David Murray  added the comment:

I can reliably reproduce the SIGINT problem on a FreeBSD 6.3 box, if (and so 
far only if) some test that uses threading is run first (see also issue 3864).  
So I suspect this is a freebsd6 specific problem and just needs a skip added.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue3864] 26.rc1: test_signal issue on FreeBSD 6.3


R. David Murray  added the comment:

The FreeBSD bot in question is now running 6.4, and test_signal is still 
failing.  I have access to a 6.3 box, which shows exactly the same failures as 
I see in the buildbot log.  On that box, doing

t = threading.Thread(target=lambda: None)
t.start()

with or without a t.join() afterward is enough to trigger the failures in 
test_signal.

Although it does not appear to have been fixed in 6.4, the 7.2 buildbot does 
not show the same problems.  (It has a somewhat different problem with *one* of 
the three failing tests in this case, but likely it is a different bug from 
this one, since the output is different.)  So I conclude that it is still most 
likely a platform problem, and I've added freebsd6 specific skips for those 
three tests in r80144.

--

___
Python tracker 

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

[issue8273] move generally useful test_support functions into the unittest package


Raymond Hettinger  added the comment:

If anything gets moved, it needs to be part of a very well thought-out plan 
with the same high threshold for approval that it would have had if it weren't 
in test_support.

The unittest module already brims with complexity and would suffer quite a bit 
if a hodge-podge of functions were added.

--

___
Python tracker 

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

[issue8273] move generally useful test_support functions into the unittest package

2010-04-16 Thread Ezio Melotti


Ezio Melotti  added the comment:

Not the module as it is, but just some of the APIs that it provides, possibly 
after a cleanup to remove things specific to our test suite and to make them 
more general and forward-compatible.

--

___
Python tracker 

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

[issue8418] Crash 0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER on program exit

2010-04-16 Thread Alf P. Steinbach


Alf P. Steinbach  added the comment:

Thanks for explaining that.

However, the first bug I ever reported was #7681, "Use floor division in 
appropiate places in the wave module.", fixed in 3.1.2.

And the tracker search does not find this bug by id.

Nor does it find it by specifying "wave" as text to search for, or by 
specifying me as reporting.

The apparent disappearance of #7681 may be a bug in the tracker.

--

___
Python tracker 

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

[issue8299] Improve GIL in 2.7

2010-04-16 Thread David Beazley


David Beazley  added the comment:

One other comment.  Running the modified fair.py file on my Linux system using 
Python compiled with semaphores shows they they are *definitely* not fair.  
Here's the relevant part of your test:

Treaded, balanced execution, with quickstop:
fast C: 1.580815 (0 left)
fast B: 1.636923 (158919 left)
fast A: 1.788634 (310323 left)

--

___
Python tracker 

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

[issue8299] Improve GIL in 2.7

2010-04-16 Thread David Beazley


David Beazley  added the comment:

I'm not trying to be a pain here, but do you have any explanation as to why, 
with fair scheduling, the observed execution time of multiple CPU-bound threads 
is substantially worse than with unfair scheduling?

>From your own benchmarks, consider this result (Fair scheduling)

Treaded, balanced execution:
fast A: 0.973000 (0 left)
fast C: 0.992000 (0 left)
fast B: 1.013000 (0 left)

Versus this result with unfair scheduling:

Treaded, balanced execution:
fast A: 0.362000 (0 left)
fast B: 0.464000 (0 left)
fast C: 0.549000 (0 left)

If I'm reading this right, it takes the three threads with fair locking almost 
twice as long to complete (1.01s) as the three threads with unfair locking 
(0.55s) .  If so, why would I want fair locking?   Wouldn't I want the solution 
that offers the fastest overall execution time?

--

___
Python tracker 

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

[issue8362] Add Misc/maintainers.rst to 2.x branch


R. David Murray  added the comment:

Any module without a listed maintainer is maintained by the community as a 
whole (as it says in the introduction).  The fact that a module does not have a 
listed maintainer does not mean it is dead, and I don't think anyone(except 
you? :) thinks that.  All modules are listed for completeness, and so that it 
is obvious which modules it would be most helpful if someone with an interest 
put themselves down as expert for (as Giampaolo has just done for ftplib).

Algorithms was listed as an interested area as a result of a brainstorming 
session for interest areas.  I think we had Raymond in mind :).  If no one has 
chosen to be listed, that line should probably be deleted.

I think perhaps the name chosen for the file was unfortunate.  I view it more 
as the 'experts' file, rather than the maintainers file, though in some cases 
the expert is indeed the principle maintainer of the module (such as Vinay for 
logging).

--

___
Python tracker 

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

[issue7606] test_xmlrpc fails with non-ascii path


STINNER Victor  added the comment:

If anyone would like to work on non-ASCII HTTP header, please open a new issue 
with a pointer to this one.

--

___
Python tracker 

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

[issue8362] Add Misc/maintainers.rst to 2.x branch


STINNER Victor  added the comment:

I read the maintainers list. I don't like empty lines. If a module has no 
maintainer, it should not be listed in this file. Since Python3 module names 
are different, if we copy the list to Python2, maintaining this list between 
Python2 and Python3 will be more difficult. Yes, some modules have no dedicated 
maitainer, but it doesn't mean that the module is dead. And I see a list 
without maintainer as a dead module.

Interest Area: algorithms has no maintainer... why is algorithms listed in 
maintainer list? Does it mean that people not listed in this line are not 
interested by algorithms?

Even if it's more difficult to maintain two versions of this file (Python2 and 
Python3), I would like to see it in Python2 (so I'm +1 for this issue).

--
nosy: +haypo

___
Python tracker 

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

[issue8393] subprocess: support undecodable current working directory on POSIX OS


STINNER Victor  added the comment:

Commited in py3k (r80135), blocked in 3.1 (r80136).

Python 3.1 has no _posixsubprocess module, it uses os.chdir() which accepts 
bytes, bytearray and str with surrogates.

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

[issue8421] tiger buildbot: unable to resolv hostname address


R. David Murray  added the comment:

Thanks, David.  test_socket passed on the latest trunk run on the tiger 
buildbot.

--
nosy: +r.david.murray
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> behavior

___
Python tracker 

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

[issue8355] diff.py produce unified format by default


Raymond Hettinger  added the comment:

I concur with Benjamin.

--
nosy: +rhettinger

___
Python tracker 

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

[issue8417] bytes and bytearray constructors raise TypeError for very large ints


Benjamin Peterson  added the comment:

Fixed in r80126. Thanks for the report!

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

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs


Benjamin Peterson  added the comment:

Now with the suggested dictionary speed hack.

--
Added file: http://bugs.python.org/file16957/with_speed_hack.patch

___
Python tracker 

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

[issue8429] buildbot: test_subprocess timeout


STINNER Victor  added the comment:

All builds ends with "test_subprocess" and then the process is killed. There is 
no usefull information :-/

--

___
Python tracker 

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

[issue8428] buildbot: test_multiprocessing timeout


STINNER Victor  added the comment:

All builds ends with "test_multiprocessing" and then the buildbot kills the 
proces. Only "x86 FreeBSD 7.2 3.x" last build (480, not the others) show us 
that test_pool_worker_lifetime 
(test.test_multiprocessing.WithProcessesTestPoolWorkerLifetime) hung.

--

___
Python tracker 

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

[issue8429] buildbot: test_subprocess timeout


STINNER Victor  added the comment:

See also issue #8428.

--

___
Python tracker 

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

[issue8428] buildbot: test_multiprocessing timeout


STINNER Victor  added the comment:

See also issue #8429.

--

___
Python tracker 

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

[issue8355] diff.py produce unified format by default


Benjamin Peterson  added the comment:

-1 Even if diff.py is not exaclty a diff replacement, it still makes sense to 
emulate what's in people's minds. I really don't find having to type 3 more 
characters a very convincing argument.

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

___
Python tracker 

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

[issue7332] python script segment fault at PyMarshal_ReadLastObjectFromFile in import_submodule

2010-04-16 Thread Charles-Francois Natali


Charles-Francois Natali  added the comment:

It's definitely a stack overflow.
Most of the backtraces show an important number of frames.
The last frame is this:
#0  PyMarshal_ReadLastObjectFromFile (fp=0x13e8200)
at ../Python/marshal.c:1026
filesize = 

and a disassembly show us that the segfault is generated on a callq:
0x4bd4d6 : callq  0x4168e8 

And if you look at the code, it's obvious what's happening:
PyObject *
PyMarshal_ReadLastObjectFromFile(FILE *fp)
{
/* 75% of 2.1's .pyc files can exploit SMALL_FILE_LIMIT.
 * REASONABLE_FILE_LIMIT is by defn something big enough for Tkinter.pyc.
 */
#define SMALL_FILE_LIMIT (1L << 14)
#define REASONABLE_FILE_LIMIT (1L << 18)
#ifdef HAVE_FSTAT
off_t filesize;
#endif
#ifdef HAVE_FSTAT
filesize = getfilesize(fp);
if (filesize > 0) {
char buf[SMALL_FILE_LIMIT];
char* pBuf = NULL;
if (filesize <= SMALL_FILE_LIMIT)
pBuf = buf;
else if (filesize <= REASONABLE_FILE_LIMIT)
pBuf = (char *)PyMem_MALLOC(filesize);
if (pBuf != NULL) {
[...]
}

SMALL_FILE_LIMIT is 1 << 14 which is roughly 16K (not that reasonable :-).
So when we enter PyMarshal_ReadLastObjectFromFile and allocate buf, we push 
around 16K on the stack, which is a lot. That's why we segfault soon after when 
we call a function (callq), there's no space left on the stack.
So there are several solutions:
- make buf static, but it would increase Python size by almost 16K
- reduce SMALL_FILE_LIMIT, or remove it altogether. I guess SMALL_FILE_LIMIT is 
there to speedup loading of small files, but I'm not sure that malloc() would 
incur an important overhead
- reading the whole file to memory sounds weird, we sould probably be using 
mmap() here

Peers ?

--
nosy: +neologix

___
Python tracker 

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

[issue762963] timemodule.c: Python loses current timezone

2010-04-16 Thread Paul Boddie


Paul Boddie  added the comment:

Well, this still doesn't work for me. I'm running Kubuntu 8.04 (libc6 package 
version 2.7-10ubuntu5) and reside in the CEST time zone, yet attempting to 
display the time zone always seems to give "+". Here are the failing tests, 
too:

==
FAIL: test_tm_gmtoff1 (__main__.TimeTestCase)
--
Traceback (most recent call last):
  File "Lib/test/test_time.py", line 225, in test_tm_gmtoff1
time.strftime("%z"), time.strftime("%z", time.localtime()))
AssertionError: '+0200' != '+'

==
FAIL: test_tm_gmtoff2 (__main__.TimeTestCase)
--
Traceback (most recent call last):
  File "Lib/test/test_time.py", line 238, in test_tm_gmtoff2
time.strftime("%z", time.localtime()), "+")
AssertionError: '+' == '+'

--

___
Python tracker 

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

[issue8429] buildbot: test_subprocess timeout


New submission from STINNER Victor :

test_subprocess hungs for 30 min or more.

The bug occurs on buildbots:
 - ARMv7Thumb Ubuntu 3.1 (r80093)
 - ARMv4 Debian 3.x (r80102)
 - ARMv7Thumb Ubuntu 3.x (r80020)
 - alpha Debian 3.x (r80020)
 - x86 FreeBSD 7.2 3.x (r80102)
 - sparc Debian trunk (r80085)

--
keywords: buildbot
messages: 103368
nosy: haypo
severity: normal
status: open
title: buildbot: test_subprocess timeout
versions: Python 2.7, Python 3.1, Python 3.2

___
Python tracker 

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

[issue8428] buildbot: test_multiprocessing timeout


STINNER Victor  added the comment:

The error occurs on buildbots:
 - i386 Ubuntu 3.x (r80115)
 - x86 FreeBSD 7.2 3.x (r80116, r80075)
 - x86 XP-4 3.x (r80115, r80106)

--

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs


Benjamin Peterson  added the comment:

And here's a patch for the correct Python version...

--
Added file: http://bugs.python.org/file16956/no_dict_non_string_kwarg.patch

___
Python tracker 

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

[issue8425] a -= b should be fast if a is a small set and b is a large set

2010-04-16 Thread Eric Smith


Changes by Eric Smith :


--
nosy: +eric.smith

___
Python tracker 

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

[issue8421] tiger buildbot: unable to resolv hostname address

2010-04-16 Thread David Bolen


David Bolen  added the comment:

Looks like some initial configuration glitches - the buildbot needed a little 
convincing to go to the DNS server for gethostbyname().  Should be working now.

--

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs


Benjamin Peterson  added the comment:

Here's a patch. It adds a new function, PyArg_ValidateKeywordArguments.

--
keywords: +patch
Added file: 
http://bugs.python.org/file16955/no_dict_non_string_keyword_args.patch

___
Python tracker 

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

[issue8322] test_ssl failures with OpenSSL 1.0.0


Changes by Antoine Pitrou :


--
stage: needs patch -> patch review

___
Python tracker 

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

[issue8322] test_ssl failures with OpenSSL 1.0.0


Antoine Pitrou  added the comment:

New patch updating docs.

--
Added file: http://bugs.python.org/file16954/ciphers2.patch

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs


Benjamin Peterson  added the comment:

They are already checked for pure python functions.

--
nosy: +benjamin.peterson

___
Python tracker 

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

[issue7811] [decimal] ValueError -> TypeError in from_tuple


Raymond Hettinger  added the comment:

I could see a TypeError for the outer tuple a tuple wasn't passed-in.  If the 
contents aren't what we expect, I believe that calling it a ValueError is the 
Python way.

--

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs


Raymond Hettinger  added the comment:

Does this mean that every time someone uses **kwds, that the entire dictionary 
will need to be scanned for invalid keys?  So every API that accepts and passes 
through **kwds will be slowed on every time it is called.  Is there any 
offsetting benefit?

--

___
Python tracker 

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

[issue8428] buildbot: test_multiprocessing timeout


New submission from STINNER Victor :

Example: http://www.python.org/dev/buildbot/3.x/builders/x86 FreeBSD 7.2 
3.x/builds/480/steps/test/logs/stdio

---
test_multiprocessing
test test_multiprocessing failed -- Traceback (most recent call last):
  File 
"/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_multiprocessing.py",
 line 737, in test_notify_all
self.assertReturnsIfImplemented(6, get_value, woken)
  File 
"/usr/home/db3l/buildarea/3.x.bolen-freebsd7/build/Lib/test/test_multiprocessing.py",
 line 111, in assertReturnsIfImplemented
return self.assertEqual(value, res)
AssertionError: 6 != 5

Re-running test test_multiprocessing in verbose mode
test_array (test.test_multiprocessing.WithProcessesTestArray) ... skipped 
'requires _ctypes'
test_getobj_getlock_obj (test.test_multiprocessing.WithProcessesTestArray) ... 
skipped 'requires _ctypes'
test_rawarray (test.test_multiprocessing.WithProcessesTestArray) ... skipped 
'requires _ctypes'
test_notify (test.test_multiprocessing.WithProcessesTestCondition) ... ok
test_notify_all (test.test_multiprocessing.WithProcessesTestCondition) ... FAIL
test_timeout (test.test_multiprocessing.WithProcessesTestCondition) ... ok
test_connection (test.test_multiprocessing.WithProcessesTestConnection) ... ok
test_duplex_false (test.test_multiprocessing.WithProcessesTestConnection) ... ok
test_sendbytes (test.test_multiprocessing.WithProcessesTestConnection) ... ok
test_spawn_close (test.test_multiprocessing.WithProcessesTestConnection) ... ok
test_event (test.test_multiprocessing.WithProcessesTestEvent) ... ok
test_finalize (test.test_multiprocessing.WithProcessesTestFinalize) ... ok
test_heap (test.test_multiprocessing.WithProcessesTestHeap) ... ok
test_import (test.test_multiprocessing.WithProcessesTestImportStar) ... ok
test_listener_client 
(test.test_multiprocessing.WithProcessesTestListenerClient) ... ok
test_lock (test.test_multiprocessing.WithProcessesTestLock) ... ok
test_lock_context (test.test_multiprocessing.WithProcessesTestLock) ... ok
test_rlock (test.test_multiprocessing.WithProcessesTestLock) ... ok
test_enable_logging (test.test_multiprocessing.WithProcessesTestLogging) ... ok
test_level (test.test_multiprocessing.WithProcessesTestLogging) ... ok
test_rapid_restart (test.test_multiprocessing.WithProcessesTestManagerRestart) 
... ok
test_apply (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_async (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_async_timeout (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_imap (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_imap_unordered (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_make_pool (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_map (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_map_chunksize (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_terminate (test.test_multiprocessing.WithProcessesTestPool) ... ok
test_pool_worker_lifetime 
(test.test_multiprocessing.WithProcessesTestPoolWorkerLifetime) ... 
command timed out: 1800 seconds without output, killing pid 87365
process killed by signal 9
program finished with exit code -1
elapsedTime=6317.267055
---

--
keywords: buildbot
messages: 103359
nosy: haypo
severity: normal
status: open
title: buildbot: test_multiprocessing timeout
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

[issue8427] toplevel jumps to another location on the screen

2010-04-16 Thread Andrei Paraschivescu


New submission from Andrei Paraschivescu :

The effect is the window just jumps to another location, matching left corners 
with another window in the same Python application. Its size doesn't change. 

The effect is somewhat erratic, the best I've been able to create is a 
situation where it happens 90% of the time. The application contains a number 
of widget.after calls, and I have not been able to replicate it with a small 
example.

I am running Mac OS X 10.4.11 and Python 2.6; running from my PC with Windows 
XP the effect doesn't happen, so it might be a OS X/Tk issue.

--
components: Tkinter
messages: 103358
nosy: aparasch
severity: normal
status: open
title: toplevel jumps to another location on the screen
versions: Python 2.6

___
Python tracker 

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

[issue8322] test_ssl failures with OpenSSL 1.0.0


Changes by Antoine Pitrou :


Added file: http://bugs.python.org/file16953/ciphers.patch

___
Python tracker 

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

[issue8322] test_ssl failures with OpenSSL 1.0.0


Changes by Antoine Pitrou :


Removed file: http://bugs.python.org/file16952/ciphers.patch

___
Python tracker 

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

[issue8322] test_ssl failures with OpenSSL 1.0.0


Antoine Pitrou  added the comment:

A set_ciphers() method turns out to be highly impractical, since the underlying 
SSL objects are created lazily when we actually connect the socket.
Therefore, I have instead opted for a new "ciphers" argument to the SSL 
constructor(s). Patch attached.

--
keywords: +patch
Added file: http://bugs.python.org/file16952/ciphers.patch

___
Python tracker 

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

[issue7811] [decimal] ValueError -> TypeError in from_tuple


Mark Dickinson  added the comment:

>From both practical and purity points of view I think I prefer TypeError for 
>the cases Stefan gives: if you're passing a float for the sign, then you've 
>somehow ended up with the wrong type for that sign, and that's a TypeError 
>rather than a ValueError.

--

___
Python tracker 

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

[issue8299] Improve GIL in 2.7

2010-04-16 Thread Kristján Valur Jónsson


Kristján Valur Jónsson  added the comment:

What your fair.py is doing is demonstrating the superior behaviour of a 
time-based GIL interrupt to a bytecode based one.  I have no quibbles with that 
and I agree that it is superior.  But I also think that your example is a very 
artificial one.  On average the duration of the bytecodes evens out between 
threads and so they should give a fair first approximation.

But this is not what I was talking about when considering fairness.  Your test 
only measures each thread end to end, and it demonstrates how a bytecode based 
gil yilelding system wil let the two threads work in lockstep, even though each 
loop in one thread is cheaper than the other.  Fair enough.  But fair 
scheduling between threads doesn't show up here.

To demonstrate fair / unfair, I've modified fair.py to add two more runs, where 
three threads of the "fast" variety are run for identical number of rounds.  
This is when you will se a difference between the linux and the mac based GIL 
implementations.  For your info, on my windows dual core office box, with 
regular windows gil:

D:\pydev\python\trunk\PCbuild>python.exe d:\pyscript\fair.py
Sequential execution
slow: 3.384000 (0 left)
fast: 0.177000 (0 left)
Threaded execution
slow: 3.435000 (0 left)
fast: 3.568000 (0 left)
Treaded, balanced execution:
fast A: 0.973000 (0 left)
fast C: 0.992000 (0 left)
fast B: 1.013000 (0 left)
Treaded, balanced execution, with quickstop:
fast A: 0.977000 (0 left)
fast C: 0.976000 (252 left)
fast B: 0.978000 (17601 left)

And now, same box, with the unfair GIL:

D:\pydev\python\trunk\PCbuild>python.exe d:\pyscript\fair.py
Sequential execution
slow: 3.338000 (0 left)
fast: 0.177000 (0 left)
Threaded execution
fast: 0.382000 (0 left)
slow: 3.539000 (0 left)
Treaded, balanced execution:
fast A: 0.362000 (0 left)
fast B: 0.464000 (0 left)
fast C: 0.549000 (0 left)
Treaded, balanced execution, with quickstop:
fast B: 0.389000 (0 left)
fast A: 0.447000 (240480 left)
fast C: 0.36 (613098 left)

The two last cases are the interesting ones.  With unfair scheduling, one 
thread takes almost twice as long to complete its 100 inserts than another. 
 And if they are all stopped when the quickest one finishes, one thread has 
more than 60 iterations to go.

This is what I mean by fair/unfair scheduling.

Cheers,

Kristján

p.s.  Yes, I agree that time based GIL yielding is better.  I intentionally 
didn't want to confuse the matter with that in 2.x.  I wanted to address the 
other issues that are wrong.

--
Added file: http://bugs.python.org/file16951/fair.py

___
Python tracker 

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

[issue8108] test_ftplib fails with OpenSSL 0.9.8m


Antoine Pitrou  added the comment:

After thinking a bit about it, we're in quasi-feature freeze now for 2.x and it 
doesn't sound reasonable to add options to unwrap(); we would need to write 
tests to exercise these options and their behaviour. Also, they aren't strictly 
needed to fix the issues at hand, but provide a functional benefit.

So I've taken some of Darryl's ideas and fixes and incorporated them. Here is a 
new patch with them. I've checked compatibility with OpenSSL 1.0.0 and 0.9.8k. 
If nobody manifests him/herself I will commit it soon.

(note: I dropped the idea of checking for application data with SSL_peek(), 
since it seems to be a blocking call; at least one of the test_ssl test cases 
froze here)

--
Added file: http://bugs.python.org/file16950/newssl6.patch

___
Python tracker 

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

[issue8273] move generally useful test_support functions into the unittest package


Changes by R. David Murray :


--
title: move test_support into the unittest package -> move generally useful 
test_support functions into the unittest package

___
Python tracker 

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

[issue8273] move test_support into the unittest package


Raymond Hettinger  added the comment:

-1 on moving the module into the mainstream without significant reworking and 
rethinking.  This module is a junk collection (I know because I've contributed 
some it).

The unittest module is important.  It needs a super clean, well thought out 
API.  The test_support module doesn't qualify.

--
nosy: +rhettinger

___
Python tracker 

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

[issue8273] move test_support into the unittest package


R. David Murray  added the comment:

I'm writing unittests for a program I'm writing, and would really love to be 
able to use captured_stdout/stderr.  Of course, I have to support Python 2.5, 
and can't really justify installing unittest2, so I'll have to roll my own 
anyway, but I'm definitely +1 for those functions to move into unittest.  A 
bunch of the others, too, but that's the one I just looked at, and the API 
looks good to me.  (I'd rename captured_output and leave it be an 
implementation detail.)

How about 'tools' for the submodule name?

--

___
Python tracker 

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

[issue8425] a -= b should be fast if a is a small set and b is a large set


Changes by Raymond Hettinger :


--
assignee:  -> rhettinger
nosy: +rhettinger
versions: +Python 3.3 -Python 3.1

___
Python tracker 

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

[issue8424] tiger buildbot: test_itimer_virtual failures


Changes by Martin v. Löwis :


--
keywords: +buildbot

___
Python tracker 

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

[issue8423] tiger buildbot: test_pep277 failures


Changes by Martin v. Löwis :


--
keywords: +buildbot

___
Python tracker 

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

[issue7811] [decimal] ValueError -> TypeError in from_tuple


Raymond Hettinger  added the comment:

A ValueError seems more appropriate to me.

--
nosy: +rhettinger

___
Python tracker 

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

[issue8422] tiger buildbot: test_abspath_issue3426 failure (test_genericpath.py)


Changes by Martin v. Löwis :


--
keywords: +buildbot

___
Python tracker 

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

[issue8421] tiger buildbot: unable to resolv hostname address


Martin v. Löwis  added the comment:

David, can you take a look?

--
nosy: +db3l, loewis

___
Python tracker 

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

[issue8426] multiprocessing.Queue fails to get() very large objects

2010-04-16 Thread Ian Davis


New submission from Ian Davis :

I'm trying to parallelize some scientific computing jobs using 
multiprocessing.Pool.  I've also tried rolling my own Pool equivalent using 
Queues.  In trying to return very large result objects from Pool.map()/imap() 
or via Queue.put(), I've noticed that multiprocessing seems to hang on the 
receiving end.  On Cygwin 1.7.1/Python 2.5.2 it hangs with no CPU activity.  On 
Centos 5.2/Python 2.6.2 it hangs with 100% CPU.  cPickle is perfectly capable 
of pickling these objects, although they may be 100's of MB, so I think it's 
the communication.  There's also some asymmetry in the error whether it's the 
parent or child putting the large object.  The put does appear to succeed;  
it's the get() on the other end that hangs forever.

Example code:
-
from multiprocessing import *

def child(task_q, result_q):
while True:
print "  Getting task..."
task = task_q.get()
print "  Got task", task[:10]
task = task * 1
print "  Putting result", task[:10]
result_q.put(task)
print "  Done putting result", task[:10]
task_q.task_done()

def parent():
task_q = JoinableQueue()
result_q = JoinableQueue()
worker = Process(target=child, args=(task_q,result_q))
worker.daemon = True
worker.start()
#tasks = ["foo", "bar", "ABC" * 1, "baz"]
tasks = ["foo", "bar", "ABC", "baz"]
for task in tasks:
print "Putting task", task[:10], "..."
task_q.put(task)
print "Done putting task", task[:10]
task_q.join()
for task in tasks:
print "Getting result..."
print "Got result", result_q.get()[:10]

if __name__ == '__main__':
parent()
-

If run as is, I get
Traceback (most recent call last):
  File 
"/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/queues.py",
 line 242, in _feed
send(obj)
MemoryError: out of memory
(*** hangs, I hit ^C ***)
Got result
Traceback (most recent call last):
Process Process-1:
Traceback (most recent call last):
  File "cygwin_multiprocessing_queue.py", line 32, in 
  File 
"/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/process.py",
 line 237, in _bootstrap
parent()
  File "cygwin_multiprocessing_queue.py", line 29, in parent
print "Got result", result_q.get()[:10]
self.run()
  File 
"/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/process.py",
 line 93, in run
  File 
"/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/queues.py",
 line 91, in get
self._target(*self._args, **self._kwargs)
  File "cygwin_multiprocessing_queue.py", line 6, in child
res = self._recv()
KeyboardInterrupt
task = task_q.get()
  File 
"/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/queues.py",
 line 91, in get
res = self._recv()
KeyboardInterrupt


If instead I comment out the multiplication in child() and uncomment the large 
task in parent(), then I get
  Getting task...
Putting task foo ...
Done putting task foo
Putting task bar ...
  Got task foo
  Putting result foo
Done putting task bar
Putting task ABCABCABCA ...
Done putting task ABCABCABCA
Putting task baz ...
  Done putting result foo
  Getting task...
  Got task bar
  Putting result bar
  Done putting result bar
  Getting task...
Done putting task baz
(*** hangs, I hit ^C ***)
Traceback (most recent call last):
  File "cygwin_multiprocessing_queue.py", line 32, in 
parent()
  File "cygwin_multiprocessing_queue.py", line 26, in parent
task_q.join()
  File 
"/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/queues.py",
 line 303, in join
self._cond.wait()
  File 
"/usr/lib/python2.5/site-packages/multiprocessing-2.6.2.1-py2.5-cygwin-1.7.1-i686.egg/multiprocessing/synchronize.py",
 line 212, in wait
self._wait_semaphore.acquire(True, timeout)
KeyboardInterrupt

--
components: Library (Lib)
messages: 103349
nosy: Ian.Davis
severity: normal
status: open
title: multiprocessing.Queue fails to get() very large objects
type: crash
versions: Python 2.5, Python 2.6

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs

2010-04-16 Thread Alex


Alex  added the comment:

Guido seems to be favoring disallowing it, not ignoring it[0].

http://mail.python.org/pipermail/python-dev/2010-April/099435.html

--
nosy: +alex

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs

2010-04-16 Thread Eric Smith


Eric Smith  added the comment:

I agree with Mark. Guido's point was that if it's implementation defined, 
you'll have portability problems: 
http://mail.python.org/pipermail/python-dev/2010-April/099435.html

--

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs


Mark Dickinson  added the comment:

> I agree with Guido that we just call this an undefined, implementation 
> specific behavior.

Actually I think that was exactly what Guido was *disagreeing* with.  :)

--

___
Python tracker 

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

[issue8401] Strange behavior of bytearray slice assignment


Martin v. Löwis  added the comment:

-1 on assigning strings to slices of bytearrays. As Ezio mentions, this 
operation conceptually requires an encoding, and no encoding is readily 
available in the slice assignment.

-1 on special-casing empty strings.

--

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs


Raymond Hettinger  added the comment:

I don't think this is worth the performance hit or worth the deprecate/remove 
exercise.  I agree with Guido that we just call this an undefined, 
implementation specific behavior.

This behavior has existed for a very long time with no ill-effects.  Marking as 
low priority.

--
nosy: +rhettinger
priority: normal -> low

___
Python tracker 

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

[issue8425] a -= b should be fast if a is a small set and b is a large set

2010-04-16 Thread Eugene Kapun


New submission from Eugene Kapun :

>>> small_set = set(range(2000))
>>> large_set = set(range(2000))
>>> large_set -= small_set # Fast
>>> small_set -= large_set # Slow, should be fast
>>> small_set = small_set - large_set # Fast

--
components: Interpreter Core
messages: 103343
nosy: abacabadabacaba
severity: normal
status: open
title: a -= b should be fast if a is a small set and b is a large set
type: resource usage
versions: Python 3.1

___
Python tracker 

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

[issue7811] [decimal] ValueError -> TypeError in from_tuple


Mark Dickinson  added the comment:

It's a bit ambiguous:  the object being supplied to the Decimal constructor 
does have the right type (tuple), but the wrong contents (i.e., value).  So you 
could argue either way on this, I guess.

--
assignee:  -> mark.dickinson

___
Python tracker 

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

[issue8424] tiger buildbot: test_itimer_virtual failures


New submission from STINNER Victor :

test_itimer_virtual (test.test_signal.ItimerTest) ... FAIL

==
FAIL: test_itimer_prof (test.test_signal.ItimerTest)
--
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_signal.py", 
line 391, in test_itimer_prof
self.fail('timeout waiting for sig_prof signal')
AssertionError: timeout waiting for sig_prof signal

==
FAIL: test_itimer_virtual (test.test_signal.ItimerTest)
--
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_signal.py", 
line 372, in test_itimer_virtual
(signal.getitimer(self.itimer),))
AssertionError: timeout waiting for sig_vtalrm signal; 
signal.getitimer(self.itimer) gives: (0.29, 0.2)

--
Ran 13 tests in 15.302s

--
messages: 103341
nosy: haypo
severity: normal
status: open
title: tiger buildbot: test_itimer_virtual failures
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

[issue8423] tiger buildbot: test_pep277 failures


New submission from STINNER Victor :

http://www.python.org/dev/buildbot/3.x/builders/x86 Tiger 
3.x/builds/6/steps/test/logs/stdio

test test_pep277 failed -- multiple errors occurred; run in verbose mode for 
details
Re-running test test_pep277 in verbose mode
test_directory (test.test_pep277.UnicodeFileTests) ... ok
test_failures (test.test_pep277.UnicodeFileTests) ... ok
test_listdir (test.test_pep277.UnicodeFileTests) ... FAIL
test_normalize (test.test_pep277.UnicodeFileTests) ... ERROR
test_open (test.test_pep277.UnicodeFileTests) ... ok
test_rename (test.test_pep277.UnicodeFileTests) ... ok
test_directory (test.test_pep277.UnicodeNFCFileTests) ... ok
test_failures (test.test_pep277.UnicodeNFCFileTests) ... ok
test_listdir (test.test_pep277.UnicodeNFCFileTests) ... FAIL
test_normalize (test.test_pep277.UnicodeNFCFileTests) ... ERROR
test_open (test.test_pep277.UnicodeNFCFileTests) ... ok
test_rename (test.test_pep277.UnicodeNFCFileTests) ... ok
test_directory (test.test_pep277.UnicodeNFDFileTests) ... ok
test_failures (test.test_pep277.UnicodeNFDFileTests) ... ok
test_listdir (test.test_pep277.UnicodeNFDFileTests) ... ok
test_normalize (test.test_pep277.UnicodeNFDFileTests) ... ERROR
test_open (test.test_pep277.UnicodeNFDFileTests) ... ok
test_rename (test.test_pep277.UnicodeNFDFileTests) ... ok
test_directory (test.test_pep277.UnicodeNFKCFileTests) ... ok
test_failures (test.test_pep277.UnicodeNFKCFileTests) ... ok
test_listdir (test.test_pep277.UnicodeNFKCFileTests) ... FAIL
test_normalize (test.test_pep277.UnicodeNFKCFileTests) ... ERROR
test_open (test.test_pep277.UnicodeNFKCFileTests) ... ok
test_rename (test.test_pep277.UnicodeNFKCFileTests) ... ok
test_directory (test.test_pep277.UnicodeNFKDFileTests) ... ok
test_failures (test.test_pep277.UnicodeNFKDFileTests) ... ok
test_listdir (test.test_pep277.UnicodeNFKDFileTests) ... ok
test_normalize (test.test_pep277.UnicodeNFKDFileTests) ... ERROR
test_open (test.test_pep277.UnicodeNFKDFileTests) ... ok
test_rename (test.test_pep277.UnicodeNFKDFileTests) ... ok

==
ERROR: test_normalize (test.test_pep277.UnicodeFileTests)
--
test test_pep277 crashed -- : 'ascii' codec can't 
encode characters in position 222-239: ordinal not in range(128)
Traceback (most recent call last):
  File "./Lib/test/regrtest.py", line 905, in runtest_inner
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_pep277.py", 
line 195, in test_main
UnicodeNFKDFileTests,
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 
1000, in run_unittest
_run_suite(suite)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 
974, in _run_suite
result = runner.run(suite)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/runner.py", 
line 158, in run
result.printErrors()
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/runner.py", 
line 108, in printErrors
self.printErrorList('ERROR', self.errors)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/runner.py", 
line 116, in printErrorList
self.stream.writeln("%s" % err)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/unittest/runner.py", 
line 24, in writeln
self.write(arg)
UnicodeEncodeError: 'ascii' codec can't encode characters in position 222-239: 
ordinal not in range(128)

--
messages: 103340
nosy: haypo
severity: normal
status: open
title: tiger buildbot: test_pep277 failures
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

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32


Mark Dickinson  added the comment:

Fix merged to release31-maint in r80119.  Thanks, Victor.

--
components: +Tests
resolution:  -> fixed
stage:  -> committed/rejected
status: open -> closed
type:  -> crash

___
Python tracker 

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

[issue8422] tiger buildbot: test_abspath_issue3426 failure (test_genericpath.py)


Changes by STINNER Victor :


--
components: +Library (Lib)
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

[issue8422] tiger buildbot: test_abspath_issue3426 failure (test_genericpath.py)


New submission from STINNER Victor :

http://www.python.org/dev/buildbot/3.x/builders/x86 Tiger 
3.x/builds/6/steps/test/logs/stdio

test test_ntpath failed -- Traceback (most recent call last):
  File 
"/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_genericpath.py", 
line 288, in test_abspath_issue3426
with support.temp_cwd(b'\xe7w\xf0'):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/contextlib.py", line 
17, in __enter__
return next(self.gen)
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/support.py", line 
392, in temp_cwd
os.mkdir(name)
OSError: [Errno 22] Invalid argument

As discussed on IRC: Mac OS X deny the creation of a directory with an invalid 
utf8 name. The test should be skipped on Mac OS X (sys.platform == 'darwin').

--
messages: 103338
nosy: haypo
severity: normal
status: open
title: tiger buildbot: test_abspath_issue3426 failure (test_genericpath.py)

___
Python tracker 

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

[issue8421] tiger buildbot: unable to resolv hostname address


New submission from STINNER Victor :

http://www.python.org/dev/buildbot/3.x/builders/x86 Tiger 
3.x/builds/6/steps/test/logs/stdio:
==
ERROR: testSockName (test.test_socket.GeneralModuleTests)
--
Traceback (most recent call last):
  File "/Users/db3l/buildarea/3.x.bolen-tiger/build/Lib/test/test_socket.py", 
line 504, in testSockName
my_ip_addr = socket.gethostbyname(socket.gethostname())
socket.gaierror: [Errno 7] No address associated with nodename

--
messages: 103337
nosy: haypo
severity: normal
status: open
title: tiger buildbot: unable to resolv hostname address
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

[issue1766304] improve xrange.contains


Raymond Hettinger  added the comment:

As an implementation detail, it isn't too late to put this into 2.x if it is 
something we care about.

--
priority: normal -> low

___
Python tracker 

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

[issue8413] String interpolation doesn't work with sys.version_info


Changes by Raymond Hettinger :


--
priority: normal -> high

___
Python tracker 

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

[issue8420] set_lookkey is unsafe


Changes by Raymond Hettinger :


--
assignee:  -> rhettinger
nosy: +rhettinger

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs

2010-04-16 Thread Eric Smith


Changes by Eric Smith :


--
nosy: +eric.smith

___
Python tracker 

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

[issue7606] test_xmlrpc fails with non-ascii path


STINNER Victor  added the comment:

> Commited: r80112 (py3k)

Looks good: r80118 (3.1).

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

[issue7605] test_cmd_line fails with non-ascii path


Changes by STINNER Victor :


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

[issue7605] test_cmd_line fails with non-ascii path


STINNER Victor  added the comment:

Fixed: r80116 (py3k), r80117 (3.1).

--

___
Python tracker 

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

[issue8420] set_lookkey is unsafe

2010-04-16 Thread Eugene Kapun


New submission from Eugene Kapun :

I've noticed that set_lookkey (in Objects/setobject.c) does some unsafe things:
Objects/setobject.c:
> if (entry->hash == hash) {
>   startkey = entry->key;
>   Py_INCREF(startkey);
>   cmp = PyObject_RichCompareBool(startkey, key, Py_EQ);
>   Py_DECREF(startkey);
At this point, object pointed to by startkey could be deallocated, and then new 
object may be allocated at the same address.
>   if (cmp < 0)
>   return NULL;
>   if (table == so->table && entry->key == startkey) {
At this point, the table may be reallocated at the same address but with 
different (possibly smaller) size, so entry->key may be in deallocated memory. 
Also, entry->key may be equal to startkey but still point to an object other 
than one key was compared with.
>   if (cmp > 0)
>   return entry;
>   }
>   else {
>   /* The compare did major nasty stuff to the
>* set:  start over.
>*/
>   return set_lookkey(so, key, hash);
This can lead to infinite recursion.
>   }

--
components: Interpreter Core
messages: 10
nosy: abacabadabacaba
severity: normal
status: open
title: set_lookkey is unsafe
versions: Python 3.1

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs


Mark Dickinson  added the comment:

Update:  IronPython also produces a TypeError here (thanks Michael Foord and 
Dino Viehland).

--

___
Python tracker 

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

[issue8419] dict constructor allows invalid identifiers in **kwargs


Mark Dickinson  added the comment:

The issue applies to dict.update as well:

>>> d = {1:2}
>>> d.update({3:4}, **{5:6})
>>> d
{1: 2, 3: 4, 5: 6}

--

___
Python tracker 

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

[issue8417] bytes and bytearray constructors raise TypeError for very large ints


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

[issue8419] dict constructor allows invalid identifiers in **kwargs


New submission from Mark Dickinson :

In all versions of CPython right now, the following works.

>>> dict({1:2}, **{3:4})
{1: 2, 3: 4}

Other Python implementations raise TypeError for this;  CPython should probably 
do the same, beginning with deprecating this behaviour in Python 3.2 and 
removing it in 3.3.

>From a python-dev posting[1] by Alex Gaynor:

"""
I ran into the follow behavior while making sure Django works
correctly on PyPy.  The following behavior was observed in all tested
versions of CPython (2.5, 3.1):

>>> def f(**kwargs):
... print(kwargs)
...
>>> kwargs = {1: 3}
>>>
>>> dict({}, **kwargs)
{1: 3}
>>> f(**kwargs)
Traceback (most recent call last):
 File "", line 1, in 
TypeError: f() keywords must be strings
>>>

This behavior seems pretty strange to me, indeed PyPy gives the
TypeError for both attempts.  I just wanted to confirm that it was in
fact intentional.
"""

Raghuram Devarakonda says (in the same python-dev thread):

"I ran into same issue with Django on Jython yesterday [1] since Jython
too gives TypeError for 'dict({}, **kwargs)'."

Guido, on the suggestion that both the CPython and PyPy behaviour be left as 
is, and that the behaviour be regarded as implementation defined:

"That is just going to cause some programs to have a portability
surprise. I think one or the other should be fixed. I am fine with declaring 
dict({}, **{1:3}) illegal, since after all it is abuse of the ** mechanism. We 
should deprecate it in at least one version though."


[1] http://mail.python.org/pipermail/python-dev/2010-April/099427.html

--
components: Interpreter Core
messages: 103330
nosy: mark.dickinson
priority: normal
severity: normal
stage: unit test needed
status: open
title: dict constructor allows invalid identifiers in **kwargs
type: behavior
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

[issue7605] test_cmd_line fails with non-ascii path


STINNER Victor  added the comment:

The problem is that the print is failing because Python uses ASCII encoding for 
stdout. Attached patch encodes sys.path to ASCII using backslashreplace to 
avoid the encoding issue.

--
keywords: +patch
nosy: +haypo
Added file: http://bugs.python.org/file16949/test_cmd_line.patch

___
Python tracker 

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

[issue8418] Crash 0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER on program exit


R. David Murray  added the comment:

The meta-tracker (the tracker to report problems with the tracker) is a 
separate tracker and you have to create a new login there.  I agree that this 
is awkward, but nobody has stepped up to fix it yet.

'your issues' is issues assigned to you, and 'normal' users can never have 
issues assigned to them.  There's already an issue in the meta tracker about 
this.  You can use the 'search' interface to search for bugs created by 
you...sooner or later someone will submit a patch to the meta tracker to put 
such a search in the left hand menu.

I don't have any input on the windows bug, but I'll add Brian Curtin as nosy in 
case he has any thoughts.

--
nosy: +brian.curtin, r.david.murray
priority:  -> normal

___
Python tracker 

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

[issue8418] Crash 0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER on program exit

2010-04-16 Thread Alf P. Steinbach


Alf P. Steinbach  added the comment:

It now seems almost certain that it's /necessary/ to not have run any Python 
programs for a while (say, 10 minutes?) in order for the bug to manifest when 
using Ctrl C in the enclosed program.

Also, I forgot to mention, the SEH exception occurs *while the program is 
printing the traceback*.

Except that the last line is not displayed until the tell-Bill-Gates-about-it 
box is clicked away, it consistently manages to print


C:\Documents and Settings\Alf> sum.v4.py
This program computes the sum of two numbers A and B.

Number A, please: Traceback (most recent call last):
  File "C:\Documents and Settings\Alf\sum.v4.py", line 13, in 


When it doesn't crash it displays four more lines of traceback.

--

___
Python tracker 

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

[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name

2010-04-16 Thread Nick Coghlan


Changes by Nick Coghlan :


--
assignee:  -> ncoghlan

___
Python tracker 

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

[issue8407] expose signalfd(2) and sigprocmask(2) in the signal module

2010-04-16 Thread Jean-Paul Calderone


Jean-Paul Calderone  added the comment:

> The one big difference I can see is that set_wakeup_fd() doesn't transmit the 
> signal number, but this could be fixed if desired (instead of sending '\0', 
> send a byte containing the signal number).

There's a lot more information than the signal number available as well.  The 
signalfd_siginfo struct has 16 fields in it now and may have more in the future.

Another advantage is that this approach allows all asynchronous preemption to 
be disabled.  This side-steps the possibility of hitting any signal bugs in 
CPython itself.  Of course, any such bugs that are found should be fixed, but 
fixing them is often quite challenging and involves lots of complex 
domain-specific knowledge.  In comparison, the signalfd and sigprocmask 
extensions are quite straight-forward and self-contained.

It's also possible to have several signalfds, each with a different signal 
mask.  set_wakeup_fd is limited to a single fd per-process.

sigprocmask has other uses all by itself, of course, like delaying the delivery 
of signals while some sensitive code runs.

--

___
Python tracker 

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

[issue8418] Crash 0xc0000417 STATUS_INVALID_CRUNTIME_PARAMETER on program exit

2010-04-16 Thread Alf P. Steinbach

New submission from Alf P. Steinbach :

Python 3.1.1 in Windows XP Prof, appears to be a Windows-only problem

Effect: on program exit the interpreter crashes with exception 0xc417
STATUS_INVALID_CRUNTIME_PARAMETER at address 0x78588389, which appears to be in
[msvcr90.dll].

To reproduce: very difficult. I had this occur tree times when, after not
running any Python program for a while, hitting Ctrl C at the first prompt of
the enclosed program. On subsequent runs (not waiting) the bug does *not*
manifest. Possibly a timing issue?

Possibly the same bug: ticket #85 for PyInstaller, http://www.pyinstaller.org/ticket/85> has same exception code and same address
and also occurring at program exit. Reported as not manifesting in Linux, only
Windows. If same bug may be more reliable way to reproduce.

PS: I reported two or three bugs earlier; one was fixed in 3.1.2. But the "Your
issues" link shows no issues for me. Trying to report that via "Report tracker
problem" it doesn't recognize me as logged in, and maintains that my login
attempt is invalid. So there's like a bug in the tracker's reporting scheme for
reporting the bug in the tracker. :-)

--
components: Interpreter Core
files: sum.v4.py
messages: 103325
nosy: alfps
severity: normal
status: open
title: Crash 0xc417 STATUS_INVALID_CRUNTIME_PARAMETER on program exit
type: crash
versions: Python 3.1
Added file: http://bugs.python.org/file16948/sum.v4.py

___
Python tracker

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

[issue8362] Add Misc/maintainers.rst to 2.x branch


R. David Murray  added the comment:

@Éric: even if you prepare the patches, I find I'm not interested in doing the 
checkins.  If someone else wants to take this on that's fine with me, but I'm 
not going to do it.

--
assignee: georg.brandl -> 

___
Python tracker 

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

[issue7606] test_xmlrpc fails with non-ascii path


STINNER Victor  added the comment:

Commited: r80112 (py3k). Waiting for the buildbots before te backport to 3.1.

--

___
Python tracker 

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

[issue7606] test_xmlrpc fails with non-ascii path


Antoine Pitrou  added the comment:

> What do you think about my solution (convert the traceback to ASCII to
> avoid the encoding issue)?

It's fine for me. Perhaps you should add a comment to explain why this is 
necessary.

--

___
Python tracker 

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

[issue762963] timemodule.c: Python loses current timezone


R. David Murray  added the comment:

Review the code, test the patch, confirm that it fixes the problem and doesn't 
break anything else, and report your results here.  That doesn't guarantee that 
it will get applied, but it definitely helps.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue7946] Convoy effect with I/O bound threads and New GIL

2010-04-16 Thread Nir Aides


Nir Aides  added the comment:

I uploaded an update to bfs.patch which improves behavior in particular on 
non-Linux multi-core (4+) machines. 

Hi Charles-Francois, Thanks for taking the time to review this patch!

> - nothing guarantees that you'll get a msec resolution

Right, the code should behave well with low precision clocks as long as short 
(sub-tick) tasks are not synchronized with the slice interval. There is a 
related discussion of this problem in schedulers in the section on sub-tick 
accounting in: http://ck.kolivas.org/patches/bfs/sched-BFS.txt

On which target systems can we expect not to have high precision clock?

> - gettimeofday returns you wall clock time: if a process that modifies time 
> is running, e.g. ntpd, you'll likely to run into trouble. the value returned 
> is _not_ monotonic, but clock_gettime(CLOCK_MONOTONIC) is
> - inline functions are used, but it's not ANSI
> - static inline long double get_timestamp(void) {
>struct timeval tv;
>GETTIMEOFDAY(&tv);
>return (long double) tv.tv_sec + tv.tv_usec * 0.01;
> }

I added timestamp capping to the code. timestamp is used for waiting and 
therefore I think the source should be either CLOCK_REALTIME or gettimeofday().

> > `tstate->tick_counter % 1000` is replicating the behaviour of the old GIL, 
> > which based its speculative operation on the number of elapsed opcodes (and 
> > which also gave bad latency numbers on the regex workload).
>
> I find this suspicous too. I haven't looked at the patch in detail, but what 
> does the number of elapsed opcodes offers you over the timesplice expiration 
> approach ?

More accurate yielding. It is possible a better mechanism can be thought of 
and/or maybe it is indeed redundant.

> It is thus recommended that a condition wait be enclosed in the equivalent of 
> a "while loop" that checks the predicate."

Done.

--
Added file: http://bugs.python.org/file16947/bfs.patch

___
Python tracker 

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

[issue7946] Convoy effect with I/O bound threads and New GIL

2010-04-16 Thread Nir Aides


Changes by Nir Aides :


Removed file: http://bugs.python.org/file16830/bfs.patch

___
Python tracker 

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

[issue8408] need console/pager module


R. David Murray  added the comment:

Benjamin was using the term 'bug' as a synonym for 'issue in the tracker'.  The 
point is that a feature like this (a whole new module) is not an appropriate 
tracker item.  In most cases the procedure for getting a new module included in 
the stdlib is distinctly non-trivial and generally requires, among other 
things, that the module get proven by distribution via PyPI first.

--
nosy: +r.david.murray

___
Python tracker 

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

[issue8412] os.system() doesn't support surrogates nor bytes


Changes by STINNER Victor :


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

[issue8412] os.system() doesn't support surrogates nor bytes


STINNER Victor  added the comment:

> Commited to py3k as r80105

The buildbots look happy: backported to 3.1 as r80110.

--

___
Python tracker 

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

[issue8405] Improve test_os._kill (failing on slow machines)


STINNER Victor  added the comment:

With the patch, the test have 1.0 second to succeed. I would prefer 5.0 or 10.0 
seconds: it should not waste the 10 seconds because it should succeed if a new 
milliseconds. But if the machine is "slow" (which is the topic of the issue), 
you can give some more seconds to the test. So max=100, sleep=0.1

--
nosy: +haypo

___
Python tracker 

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

[issue4970] test_os causes delayed failure on x86 gentoo buildbot: Unknown signal 32


STINNER Victor  added the comment:

Commited as r80108 to py3k: "Add CS_GNU_LIBC_VERSION and 
CS_GNU_LIBPTHREAD_VERSION constants for constr(), and disable 
test_execvpe_with_bad_program() of test_os if the libc uses linuxthreads to 
avoid the "unknown signal 32" bug (see issue #4970)."

Wait for the buildbot to port it to trunk (and maybe 2.6 and 3.1).

--

___
Python tracker 

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

[issue8314] test_ctypes fails in test_ulonglong on sparc buildbots


STINNER Victor  added the comment:

> Committed as r79892.

Commited to py3k (r80106), but blocked in 3.1 (r80107) because Python 3.1 uses 
libffi 3.0.5.

--
nosy: +haypo
status: pending -> open

___
Python tracker 

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

[issue8413] String interpolation doesn't work with sys.version_info


Changes by R. David Murray :


--
nosy: +rhettinger

___
Python tracker 

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

[issue8412] os.system() doesn't support surrogates nor bytes