[issue7753] newgil backport

[Ralf Schmitt]

Changes by Ralf Schmitt :


--
nosy: +schmir

___
Python tracker 

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

[issue7138] elementtree segfaults on invalid xml declaration

[Amaury Forgeot d'Arc]

Amaury Forgeot d'Arc  added the comment:

This was merged into 2.6 with r74432, into 2.5 with r77666, into 3.1 with 
r74436.

--
assignee:  -> jyasskin
nosy: +jyasskin
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

[issue7754] decimal.Decimal 0.0**0.0 error

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks for the report.  Unfortunately, this behaviour is by design:  the 
decimal module follows the specification at

http://speleotrove.com/decimal/decarith.html

See particularly:

http://speleotrove.com/decimal/daops.html#refpower

 Yes, I think this is wrong too, particularly since (a) it's inconsistent 
with Decimal('Inf')**Decimal('0.0') giving Decimal('1') and (b) it's 
inconsistent with other established standards like IEEE 754-2008 and C99 Annex 
F.  And that's before getting into arguments about how a simple power operation 
is *not* the same thing as an indeterminate form, and how Decimal is also 
supposed to be usable for pure integer arithmetic, where having 0**0 be 
anything other than 1 is horrible.  I made these points to the author of the 
specification some time ago, but he was regrettably unmoved.  :)  

Ultimately, I don't think it's a big enough issue to justify breaking 
compliance with the specification.

--
assignee:  -> mark.dickinson
nosy: +skrah
resolution:  -> invalid
status: open -> pending

___
Python tracker 

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

[issue7753] newgil backport

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

A few things:

 * The ceval_gil.h file is missing from the patch.

 * Please check whether you can move these variable declarations inside the 
main loop function (as statics):

+/* This single variable consolidates all requests to break out of the fast path
+   in the eval loop. */
+static volatile int eval_breaker = 0;
+/* Request for droppping the GIL */
+static volatile int gil_drop_request = 0;
+/* Request for running pending calls */
+static volatile int pendingcalls_to_do = 0; 
+/* Request for looking at the `async_exc` field of the current thread state */
+static volatile int pending_async_exc = 0;

 * Instead of deprecating the set/getcheckinterval APIs, convert the arguments 
passed to these to the switch interval. The new APIs set/getswitchinteral are 
then not needed.

 * Please add the fallback solutions from the time module in case 
gettimeofday() is not available. You cannot assume that "all modern POSIX 
systems" implement that API - it was introduced in POSIX 2001 and Python 2.x 
still supports OSes that were released prior to that year.

 * Note that gettimeofday() et al. are rather slow APIs on most systems. It 
would be better to directly use a simple performance timer since we don't 
really need any timing accuracy in managing the GIL when run with threads. Have 
a look at the clock_gettime() API for ways of accessing such timers. There may 
also be other ways of accessing such times via pthreads.

 * I haven't looked at the timing details of the implementation, but please 
make sure that it works even if the clock interval is a few ms (while 
gettimeofday() provides us resolution, the system clock may still only tick in 
ms intervals - another reason to use CPU performance timers instead).

Thanks.

--
nosy: +lemburg

___
Python tracker 

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

[issue7753] newgil backport

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

See Tools/pybench/systimes.py for more comments on clocks, ticks and update 
frequency.

--

___
Python tracker 

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

[issue7755] copyright clarification for audiotest.au

[Matthias Klose]

New submission from Matthias Klose :

[forwarded from http://bugs.debian.org/565713]

If the bug submitter is correct about these, it would be nice to replace these, 
or clarify the copyright for these files.

"the python source packages contain a non-free audio clip that is
from Monty Python's Flying Circus, which is Copyright 1969.  i doubt
that the copyright holders have put any of that material into the
public domain, and the copyright term has not yet expired.

the files are:
 ./Lib/test/audiotest.au
 ./Lib/email/test/data/audiotest.au
"

--
components: Tests
messages: 98141
nosy: doko
severity: normal
status: open
title: copyright clarification for audiotest.au
versions: Python 2.6, 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

[issue7754] decimal.Decimal 0.0**0.0 error

[Mark Dickinson]

Mark Dickinson  added the comment:

Now that I think about it, this could be 'fixed' without breaking compliance:  
all the specification requires is that a power function with the specified 
behaviour is present *somewhere* in the decimal module;  it needn't be linked 
to the ** operator.  So there could be two versions of power in decimal.py:  
one version (called Decimal.power) that strictly conforms to the specification, 
and another (Decimal.__pow__) that's identical in every way except that it 
returns Decimal('1') for Decimal('0.0')**0.

While we're at it, we could also 'fix' Decimal.__pos__ and Decimal.__neg__ 
similarly:  the standard requires operations 'plus' and 'minus', with the 
slightly surprising (to me, at least) properties that plus(-0.0) = 0.0 and 
minus(0.0) = 0.0  (for both these, -0.0 seems more natural);  but there's no 
requirement that Python's __pos__ and __neg__ be identical to these.

But these changes would come with all the usual costs: extra code, tests and 
documentation, future maintenance costs, possibility of introducing bugs, user 
confusion, possible backwards compatibility issues,...  So there would have to 
be some significant perceived benefits to outweigh the costs.

Perhaps a discussion on the python-dev mailing list would be in order?

--
status: pending -> open

___
Python tracker 

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

[issue7753] newgil backport

[Antoine Pitrou]

Antoine Pitrou  added the comment:

>  * Instead of deprecating the set/getcheckinterval APIs, convert the
> arguments passed to these to the switch interval. The new APIs
> set/getswitchinteral are then not needed.

This is certainly not a good idea. The semantics are different, which is the 
reason why I created a separate API in the first place instead of recycling the 
old one.

Actually, there should be hardly any reason to want to change the interval with 
the new GIL implementation. It was required with the old GIL due to the fact 
that counting opcodes is a very poor way of estimating wall clock durations.

> Note that gettimeofday() et al. are rather slow APIs on most systems

In my measurements under Linux it seemed to be as fast as clock_gettime() 
actually. But I don't know about other systems. I didn't want to complicate the 
patch (with several different paths) more than seemed necessary.

--
nosy: +pitrou

___
Python tracker 

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

[issue7076] Documentation add note about SystemRandom

[Brian Curtin]

Changes by Brian Curtin :


--
keywords: +needs review
stage:  -> patch review

___
Python tracker 

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

[issue7750] IOError when launching script under pdb with backslash in script path

[Jason R. Coombs]

Jason R. Coombs  added the comment:

Here's a new patch against the trunk that addresses Brian's concerns.

--
keywords: +patch
versions: +Python 2.7
Added file: http://bugs.python.org/file15970/fix with test.patch

___
Python tracker 

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

[issue7750] IOError when launching script under pdb with backslash in script path

[Jason R. Coombs]

Jason R. Coombs  added the comment:

For completeness, I've back-ported the patch to the release26-maint branch.

--
Added file: http://bugs.python.org/file15971/fix with test 
(releas26-maint).patch

___
Python tracker 

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

[issue7750] IOError when launching script under pdb with backslash in script path

[Jason R. Coombs]

Changes by Jason R. Coombs :


Removed file: http://bugs.python.org/file15968/test_pdb.py

___
Python tracker 

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

[issue7756] Complete your registration to Python tracker -- key rt04e51ru5U1WqGum1kklK4ZYWEe1Mkf

[Michael Smith]

New submission from Michael Smith :

Python tracker wrote:
> To complete your registration of the user "msm...@cbnco.com" with
> Python tracker, please do one of the following:
> 
> - send a reply to rep...@bugs.python.org and maintain the subject line as is 
> (the
> reply's additional "Re:" is ok),
> 
> - or visit the following URL:
> 
> http://bugs.python.org/?...@action=confrego&otk=rt04e51ru5U1WqGum1kklK4ZYWEe1Mkf
>

--
messages: 98146
nosy: msm...@cbnco.com
severity: normal
status: open
title: Complete your registration to Python tracker -- key  
rt04e51ru5U1WqGum1kklK4ZYWEe1Mkf

___
Python tracker 

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

[issue7756] Complete your registration to Python tracker -- key rt04e51ru5U1WqGum1kklK4ZYWEe1Mkf

[Brian Curtin]

Changes by Brian Curtin :


--
priority:  -> low
resolution:  -> 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

[issue7490] IGNORE_EXCEPTION_DETAIL should ignore the module name

[Lennart Regebro]

Changes by Lennart Regebro :


Removed file: http://bugs.python.org/file15537/python-py3k-exception-detail.diff

___
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

[Lennart Regebro]

Changes by Lennart Regebro :


Removed file: 
http://bugs.python.org/file15538/python-trunk-exception-detail.diff

___
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

[Lennart Regebro]

Lennart Regebro  added the comment:

New diff for trunk, with the additional test

--
Added file: http://bugs.python.org/file15972/python-trunk-exception-detail.diff

___
Python tracker 

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

[issue7242] Forking in a thread raises RuntimeError

[Zsolt Cserna]

Zsolt Cserna  added the comment:

Could you please provide any advise on this bug?
I've submitted my patch, would be curious if there any chance to get it merged.

--

___
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

[Lennart Regebro]

Lennart Regebro  added the comment:

New diff for Py3k with the additional test

--
Added file: http://bugs.python.org/file15973/python-py3k-exception-detail.diff

___
Python tracker 

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

[issue7753] newgil backport

[Neil Schemenauer]

Neil Schemenauer  added the comment:

Here is an updated set of patches that includes the ceval_gil.h file as well as 
the documentation changes.

--
Added file: http://bugs.python.org/file15974/gil-2.7.txt

___
Python tracker 

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

[issue7753] newgil backport

[Kevin Watters]

Changes by Kevin Watters :


--
nosy: +kevinwatters

___
Python tracker 

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

[issue7076] Documentation add note about SystemRandom

[David W. Lambert]

David W. Lambert  added the comment:

I recall an experience with a random file in /dev that was considerably slow 
after consuming its cache.  I used it as a seeder.  I've now got an ubuntu 
system for which /dev/urandom gives me a hundred million bytes quickly.  
Perhaps a nosy one has more information?

--
nosy: +LambertDW

___
Python tracker 

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

[issue7242] Forking in a thread raises RuntimeError

[R. David Murray]

Changes by R. David Murray :


--
nosy: +loewis

___
Python tracker 

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

[issue7757] sys.path is incorrect when prefix is ""

[Michael Smith]

New submission from Michael Smith :

I've built Python 2.6.2 with a prefix of "" for an embedded system, so it's 
installed into /bin/python, /lib/python2.6/, etc.

If I run a script with "python /tmp/script.py" or by putting in a #!/bin/python 
and executing it directly, sys.path is missing the leading slashes:

['/tmp', 'lib/python26.zip', 'lib/python2.6/', 'lib/python2.6/plat-linux2', 
'lib/python2.6/lib-tk', 'lib/python2.6/lib-old', 'lib/lib-dynload']

This causes all module imports to fail. I can work around this by making /usr a 
symlink to / and running the script as "/usr/bin/python /tmp/script.py", or by 
setting PYTHONHOME=/ before starting Python.

In Modules/getpath.c, search_for_prefix() calls reduce() on argv0_path at the 
end of a do-while loop, so "/bin" becomes "" and the loop terminates. Then 
there's a call to joinpath(PREFIX, "lib/python2.6"), where PREFIX is "", and 
this fails (no leading slash).

calculate_path() warns:

Could not find platform independent libraries 

and falls back to joinpath(PREFIX, "lib/python2.6") again, which still fails.

I was thinking I could work around it by building with prefix="/" instead of 
"", but the behaviour is the same - I don't know why, yet.

--
components: Interpreter Core
messages: 98152
nosy: msm...@cbnco.com
severity: normal
status: open
title: sys.path is incorrect when prefix is ""
type: behavior
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

[issue7743] Additional potential string -> float conversion issues.

[Mark Dickinson]

Mark Dickinson  added the comment:

Second bug listed here fixed in r77698 in the trunk.

--

___
Python tracker 

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

[issue6461] multiprocessing: freezing apps on Windows

[spongebob]

spongebob  added the comment:

I can't seem to freeze an app on Windows using multiprocessing.Manager()


Are apps that use Managers freezable??

Example:

from multiprocessing import freeze_support,Manager

if __name__ == '__main__':
freeze_support()
m=Manager()

will throw errors, when run:

Process SyncManager-1:
Traceback (most recent call last):
  File "multi_exe\build\pyi.win32\multi_exe\outPYZ1.pyz/multiprocessing.process"
, line 232, in _bootstrap
  File "multi_exe\build\pyi.win32\multi_exe\outPYZ1.pyz/multiprocessing.process"
, line 88, in run
  File "multi_exe\build\pyi.win32\multi_exe\outPYZ1.pyz/multiprocessing.managers
", line 520, in _run_server
IOError: [Errno 6] The handle is invalid
Traceback (most recent call last):
  File "", line 5, in 
  File "multi_exe\build\pyi.win32\multi_exe\outPYZ1.pyz/multiprocessing", line 9
8, in Manager
  File "multi_exe\build\pyi.win32\multi_exe\outPYZ1.pyz/multiprocessing.managers
", line 499, in start
EOFError

--
nosy: +spongebob

___
Python tracker 

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

[issue7757] sys.path is incorrect when prefix is ""

[R. David Murray]

R. David Murray  added the comment:

I thought I remembered a bug that mentioned prefix="/".  What I found was 
Issue1676135, which might have something to do with your last question.

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

[issue7753] newgil backport

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou  added the comment:
> 
>>  * Instead of deprecating the set/getcheckinterval APIs, convert the
>> arguments passed to these to the switch interval. The new APIs
>> set/getswitchinteral are then not needed.
> 
> This is certainly not a good idea. The semantics are different, which is the 
> reason why I created a separate API in the first place instead of recycling 
> the old one.
> 
> Actually, there should be hardly any reason to want to change the interval 
> with the new GIL implementation. It was required with the old GIL due to the 
> fact that counting opcodes is a very poor way of estimating wall clock 
> durations.

Applications currently use those APIs for two reasons:

 * they use lots of threads and need to make sure that they
   all run more often than they do with the default settings e.g.
   to make them respond faster to external inputs: in such a
   case, they use a low check interval number

 * they don't use any threads and thus don't need to check
   for other threads at all or only rarely: in such a case they
   use a large check interval number

While the semantics are different, the result is similar and
the actual numbers used are usually determined by experiment
or rough estimate - noone expects the APIs to provide any kind
of exact timing and it's not needed either.

Turning the existing APIs into no-ops is certainly not a good
idea, since that will change application performance for both
use cases.

Esp. the second use case (single threaded process) is a rather
common one in Python - using multiple processes is often the more
scalable approach for Python applications, than relying on
multiple threads.

>> Note that gettimeofday() et al. are rather slow APIs on most systems
> 
> In my measurements under Linux it seemed to be as fast as clock_gettime() 
> actually. But I don't know about other systems. I didn't want to complicate 
> the patch (with several different paths) more than seemed necessary.

Right, but clock_gettime() provides a better resolution.

Both APIs are relatively slow, so if you call them often, it's
better to go with a different mechanism such as one built on
CPU performance counters.

--

___
Python tracker 

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

[issue7758] cPickle segfault on invalid data

[Dan Helfman]

New submission from Dan Helfman :

The following code causes Python to segfault:

>>> import cPickle
>>> import cStringIO as io
>>> cPickle.load( io.StringIO( '0' ) )

Note that if the string is changed from '0' to '1', then the crash does not 
occur and an UnpicklingError is properly raised.

This is in MSYS on Windows XP with Python 2.6.4 from python.org:

$ gdb python
GNU gdb 5.2.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-mingw32"...(no debugging symbols found)...
(gdb) r -c "import cPickle; import cStringIO as io;  cPickle.load( io.StringIO( 
'0' ) )"
Starting program: c:\python26/python.exe -c "import cPickle; import cStringIO 
as io;  cPickle.load( io.StringIO( '0' ) )"

Program received signal SIGSEGV, Segmentation fault.
0x1e09ada3 in ?? ()
(gdb) bt
#0  0x1e09ada3 in ?? ()
#1  0x1e0e1fd5 in ?? ()
#2  0x00a4e290 in ?? ()
#3  0x1e1d1d30 in ?? ()
Cannot access memory at address 0x3

And this is on Mac OS X 10.5 with Python 2.6.4 from python.org:

$ gdb python
GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:14:40 UTC 2008)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-apple-darwin"...Reading symbols for shared 
libraries .. done

(gdb) r -c "import cPickle; import cStringIO as io; cPickle.load( io.StringIO( 
'0' ) )"
Starting program: 
/System/Library/Frameworks/Python.framework/Versions/2.6/bin/python -c "import 
cPickle; import cStringIO as io; cPickle.load( io.StringIO( '0' ) )"
Reading symbols for shared libraries +. done

Program received signal SIGTRAP, Trace/breakpoint trap.
0x8fe01010 in __dyld__dyld_start ()
(gdb) bt
#0  0x8fe01010 in __dyld__dyld_start ()
Cannot access memory at address 0x4

The same crash occurs on the Mac when using Apple's Python 2.5.1. However, on 
Linux with Debian stable's Python 2.5.2, I just get an UnpicklingError (stack 
underflow) exception without a crash.

--
components: None
messages: 98157
nosy: dhelfman
severity: normal
status: open
title: cPickle segfault on invalid data
type: crash
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

[issue7758] cPickle.load() segfault on invalid data

[Dan Helfman]

Changes by Dan Helfman :


--
title: cPickle segfault on invalid data -> cPickle.load() segfault on invalid 
data

___
Python tracker 

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

[issue7755] copyright clarification for audiotest.au

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti
priority:  -> normal

___
Python tracker 

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

[issue7753] newgil backport

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> While the semantics are different, the result is similar and
> the actual numbers used are usually determined by experiment
> or rough estimate - noone expects the APIs to provide any kind
> of exact timing and it's not needed either.

There's no reasonable formula for computing an absolute switching
interval from the current "check interval" number. Besides, as I said,
there's no demonstrated reason to change the interval with the new GIL.

> * they don't use any threads and thus don't need to check
> for other threads at all or only rarely: in such a case they
> use a large check interval number

Well, if you don't use any threads you don't have to change the setting
in the first place :-). You might want to do it in order to
"micro-optimize" your app (i.e. save 1-2% on CPU-bound code), but this
is unnecessary with the new GIL, since the interval is ignored when
there's only one thread running.

> Turning the existing APIs into no-ops is certainly not a good
> idea, since that will change application performance for both
> use cases.

The new GIL will change performance far more anyway. Trying to simulate
the old behaviour is doomed to failure. If we want to keep the current
performance characteristics, we'd better not backport the new GIL (which
I'm fine with by the way).

--

___
Python tracker 

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

[issue7758] cPickle.load() segfault on invalid data

[R. David Murray]

R. David Murray  added the comment:

This is already fixed, I believe as part of a general cleanup of one of the 
CAPI macros.  On current 2.6 branch and on trunk you now get an unpickling 
stack underflow in this case.

--
nosy: +r.david.murray
priority:  -> normal
resolution:  -> out of date
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

[issue7758] cPickle.load() segfault on invalid data

[Eric Smith]

Eric Smith  added the comment:

This is a duplicate of issue 7455.

--
components: +Extension Modules -None
nosy: +eric.smith
resolution: out of date -> duplicate
superseder:  -> cPickle: stack underflow in load_pop()

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

[Stefan Krah]

Stefan Krah  added the comment:

All outstanding issues mentioned here have been solved in Rev. 77696:

  (1) New ANSI path for unknown 64bit platforms (ia64 and Alpha build
  without problems now).

  (2) Unified tests for decimal and cdecimal.

  (3) Documentation for cdecimal.


Other improvements:

  (4) Added comprehensive test suite for testing the library directly.

  (5) Fixed warnings in Visual Studio.

  (6) Code formatting.

--

___
Python tracker 

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

[issue7754] decimal.Decimal 0.0**0.0 error

[Raymond Hettinger]

Raymond Hettinger  added the comment:

I would not be happy with unlinking __pow__ from the standard's power 
operation.  We wouldn't be doing our users a favor by implementing part of the 
standard, then tucking it away in a unexpected place, and substituting our own 
notion of what should be done.

>From the outset, one of the reasons for buying into the standard was the 
>notion that the interactions had been well thought-out and heavily discussed 
>in another forum.  By agreeing to implement the standard, we have surrendered 
>ourselves to the tyranny of whatever decisions were made.  Another reason for 
>staying compliant (in the most obvious way possible) is to make formulas more 
>interoperable between languages that have chosen to implement the standard 
>(i.e. 0**0 should do the same thing in Rexx as it does in Python).

--
nosy: +rhettinger

___
Python tracker 

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

[issue7754] decimal.Decimal 0.0**0.0 error

[Mark Dickinson]

Mark Dickinson  added the comment:

Thanks for the feedback, Raymond.  I'll close this, then.

--
status: open -> closed

___
Python tracker 

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

[issue7753] newgil backport

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Antoine Pitrou wrote:
> 
> Antoine Pitrou  added the comment:
> 
>> While the semantics are different, the result is similar and
>> the actual numbers used are usually determined by experiment
>> or rough estimate - noone expects the APIs to provide any kind
>> of exact timing and it's not needed either.
> 
> There's no reasonable formula for computing an absolute switching
> interval from the current "check interval" number. 

Just use some conversion formula, e.g. switching interval in micro
seconds = constant * byte code check interval. We can then determine
a constant to match todays CPU performance.

Given the inexact nature of the check interval that's a very
reasonable formula.

> Besides, as I said,
> there's no demonstrated reason to change the interval with the new GIL.

Didn't I just point out two use cases ?

Perhaps I'm missing some feature of the new GIL. Is there some
documentation for it somewhere ?

>> * they don't use any threads and thus don't need to check
>> for other threads at all or only rarely: in such a case they
>> use a large check interval number
> 
> Well, if you don't use any threads you don't have to change the setting
> in the first place :-). You might want to do it in order to
> "micro-optimize" your app (i.e. save 1-2% on CPU-bound code), but this
> is unnecessary with the new GIL, since the interval is ignored when
> there's only one thread running.

Hmm, how do you determine that only one thread is running ?

What if an extension uses threads that are not under Python
control, e.g. when embedding the JVM or when using a CORBA
ORB ?

>> Turning the existing APIs into no-ops is certainly not a good
>> idea, since that will change application performance for both
>> use cases.
> 
> The new GIL will change performance far more anyway. Trying to simulate
> the old behaviour is doomed to failure. If we want to keep the current
> performance characteristics, we'd better not backport the new GIL (which
> I'm fine with by the way).

I don't follow you.

If an application currently sets the check
interval to a low value, Python should switch to other threads
more often, ie. the switch interval needs to be low.

If an application currently sets the check interval to a high
value, Python should switch to other threads less often, ie.
the switch interval needs to be higher.

Both cases can be mapped to the switch interval, so why not
do it ?

--

___
Python tracker 

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

[issue7753] newgil backport

[Ross Cohen]

Ross Cohen  added the comment:

Thanks Neil for fixing up the patch.

As for Marc-Andre's comments, I'm happy to backport any further
changes which happen on the py3k branch. I'd like to keep this as a
strict backport, only changing things as necessary to get it to work
with the older codebase.

Ross

--

___
Python tracker 

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

[issue7753] newgil backport

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> Just use some conversion formula, e.g. switching interval in micro
> seconds = constant * byte code check interval. We can then determine
> a constant to match todays CPU performance.

Well, there are two problems:
- opcode execution cost varies so wildly that trying to pick up an
average would be meaningless (it can vary by many order of magnitudes
between e.g. a POP_TOP and a CALL_FUNCTION calling a C extension method)
- the interval doesn't have the same effect in the new GIL as it has in
the old GIL; in the old GIL, it merely gives the OS a chance to switch
threads if it wants to (there are many missed opportunities, by a
proportion which will be system-dependent); in the new GIL, thread
switching is enforced which means it is not necessary to stop so often.

So we'd have a formula like:

new GIL interval = old GIL interval * opcode duration / proportion of
missed switching opportunities in the old GIL

where two of the three factors on the right side are totally
unpredictable :)

> Perhaps I'm missing some feature of the new GIL. Is there some
> documentation for it somewhere ?

Almost nothing besides what is found in ceval_gil.h and in the following
thread:
http://mail.python.org/pipermail/python-dev/2009-October/093321.html
Dave Beazley did a high-level presentation about it:
http://www.dabeaz.com/python/NewGIL.pdf

> > Well, if you don't use any threads you don't have to change the setting
> > in the first place :-). You might want to do it in order to
> > "micro-optimize" your app (i.e. save 1-2% on CPU-bound code), but this
> > is unnecessary with the new GIL, since the interval is ignored when
> > there's only one thread running.
> 
> Hmm, how do you determine that only one thread is running ?

Actually, I don't determine it, it's a side effect of how the GIL is
implemented. If no thread is waiting for the GIL, the main thread isn't
"asked" to drop it.

> What if an extension uses threads that are not under Python
> control, e.g. when embedding the JVM or when using a CORBA
> ORB ?

These don't wait for the GIL, hopefully :-)

--

___
Python tracker 

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

[issue7753] newgil backport

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

On second thought, you're right: while sys.setcheckinterval() could
be made to work with the switching interval, sys.getcheckinterval()
could not be made to return anything useful.

Still, please have a look at the other issues mentioned. They
apply to new GIL in general, regardless of whether implemented
in 3.x or 2.7.

It would also be interesting to see the affect on other threaded
applications, not just the "benchmark" mentioned on the python-dev
thread.

Since there aren't all that many Python 3.x applications in the wild,
it's probably a good idea to check in the patch and then run a few
Python 2.x apps with and without it.

How does pybench react to the patch ? It's single-threaded at the
moment, so a good test of how a single-threaded application would
behave with the patch.

Thanks,
-- 
Marc-Andre Lemburg
eGenix.com



::: Try our new mxODBC.Connect Python Database Interface for free ! 

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/

--

___
Python tracker 

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

[issue7753] newgil backport

[Marc-Andre Lemburg]

Marc-Andre Lemburg  added the comment:

Antoine Pitrou wrote:
>> Perhaps I'm missing some feature of the new GIL. Is there some
>> documentation for it somewhere ?
> 
> Almost nothing besides what is found in ceval_gil.h and in the following
> thread:
> http://mail.python.org/pipermail/python-dev/2009-October/093321.html
> Dave Beazley did a high-level presentation about it:
> http://www.dabeaz.com/python/NewGIL.pdf

Thanks. Dave's slides help a lot. The logic certainly sounds like
a major improvement !

>>> Well, if you don't use any threads you don't have to change the setting
>>> in the first place :-). You might want to do it in order to
>>> "micro-optimize" your app (i.e. save 1-2% on CPU-bound code), but this
>>> is unnecessary with the new GIL, since the interval is ignored when
>>> there's only one thread running.
>>
>> Hmm, how do you determine that only one thread is running ?
> 
> Actually, I don't determine it, it's a side effect of how the GIL is
> implemented. If no thread is waiting for the GIL, the main thread isn't
> "asked" to drop it.
> 
>> What if an extension uses threads that are not under Python
>> control, e.g. when embedding the JVM or when using a CORBA
>> ORB ?
> 
> These don't wait for the GIL, hopefully :-)

Well, they might call back into Python, but I guess that's not
supported anyway, not even in 2.x, since such a thread wouldn't
have a properly setup Python thread state.

--

___
Python tracker 

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

[issue4698] Solaris buildbot failure on trunk in test_hostshot

[Neil Schemenauer]

Changes by Neil Schemenauer :


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

[issue1220756] Re-importing embedded thread dumps core

[Neil Schemenauer]

Changes by Neil Schemenauer :


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

[issue7759] mhlib fails on Btrfs filesystem (test_mhlib failure)

[Neil Schemenauer]

New submission from Neil Schemenauer :

Btrfs does not maintain a link count for directories (MacOS does the same I 
think). That confuses mhlib.py because it uses os.stat().st_nlinks as an 
optimization.

The attached patch removes the optimization and make test_mhlib pass on Btrfs 
(and probably HFS+) filesystems.

--
files: mhlib_nlinks.txt
messages: 98169
nosy: nascheme
priority: normal
severity: normal
status: open
title: mhlib fails on Btrfs filesystem (test_mhlib failure)
type: behavior
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15975/mhlib_nlinks.txt

___
Python tracker 

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

[issue2611] Extend buildbot web interface to allow for forced tests to be run on a slave in verbose mode.

[Ezio Melotti]

Changes by Ezio Melotti :


--
priority:  -> normal
stage:  -> needs patch

___
Python tracker 

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

[issue7736] os.listdir hangs since opendir() and closedir() do not release GIL

[Nikolaus Rath]

Nikolaus Rath  added the comment:

The patch works fine for me too. Also, I did not discover any other such 
problems for other syscalls (but I did not systematically try all os.* 
functions).

--

___
Python tracker 

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

[issue7760] use_errno=True does not work

[Nikolaus Rath]

New submission from Nikolaus Rath :

On my system (Ubuntu Karmic, Python 2.6.4 (r264:75706, Dec  7 2009, 18:45:15), 
Kernel 2.6.31-17-generic, libc6 2.10.1-0ubuntu16) the attached test script 
produces the following output:

Traceback (most recent call last):
  File "test1.py", line 27, in 
raise OSError(err, os.strerror(err), path)
OSError: [Errno 0] Success: '/does/not/exist'

So the function call failed, but the errno provided by ctypes is zero.

(There are two variants of construction the getxattr() foreign function in the 
script and both produce the same result).

--
assignee: theller
components: ctypes
files: test1.py
messages: 98171
nosy: Nikratio, theller
severity: normal
status: open
title: use_errno=True does not work
type: behavior
versions: Python 2.6, Python 3.1
Added file: http://bugs.python.org/file15976/test1.py

___
Python tracker 

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

[issue7760] use_errno=True does not work

[Brian Curtin]

Changes by Brian Curtin :


--
priority:  -> normal
stage:  -> needs patch

___
Python tracker 

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

[issue7564] test_ioctl may fail when run in background

[STINNER Victor]

STINNER Victor  added the comment:

test_ioctl() gets the process group ID of the foreground process group on 
/dev/tty. If Python is in foreground, it's equal to the process group ID 
(os.getpgrp()) or to the session ID (os.getsid(0)). If Python is in background, 
yes, the test fail.

test_ioctl_mutate() contains test_ioctl() but also ensure that the input buffer 
is not modified by the ioctl.

If you would like to run test_ioctl.py in background, you will have to disable 
these 2 tests: ignore the tests if the process is in background. Detect if a 
process is in foreground or background is exactly the goal of test_ioctl()...

--
nosy: +haypo

___
Python tracker 

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

[issue7267] format method: c presentation type broken

[STINNER Victor]

STINNER Victor  added the comment:

('%c' % 255) == chr(255) == '\xff'

'%c' % 256 raise an "OverflowError: unsigned byte integer is greater than 
maximum" and chr(256) raise a "ValueError: chr() arg not in range(256)". I 
prefer the second error ;-)

str.format() should follow the same behaviour.

str is a byte string: it can be used to create a network packet or encode data 
into a byte stream. '%c' is useful for that, and str.format() should keep this 
nice feature.

--

___
Python tracker 

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

[issue7761] telnetlib Telnet.interact fails on Windows but not Linux

[Michael Newman]

New submission from Michael Newman :

Telnet.interact() is failing on Python 3.1.1 Windows, but works fine on Python 
2.6.4 Windows and also works on Python 3.1.1 Linux. See 3 examples below:

--- Test #1 (fails): Telnet.interact on Python 3.1.1 Windows --- 

Python 3.1.1 (r311:74483, Aug 17 2009, 17:02:12) [MSC v.1500 32 bit (Intel)] on 
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from telnetlib import Telnet
>>> tn = Telnet("scn.org", 23)
>>> tn.interact()
Unhandled exception in thread started by >
Traceback (most recent call last):
  File "C:\python31\lib\telnetlib.py", line 566, in listener
sys.stdout.write(data)
TypeError: must be str, not bytes
# (I press enter again):
Traceback (most recent call last):
  File "", line 1, in 
  File "C:\python31\lib\telnetlib.py", line 528, in interact
self.mt_interact()
  File "C:\python31\lib\telnetlib.py", line 555, in mt_interact
self.write(line)
  File "C:\python31\lib\telnetlib.py", line 277, in write
if IAC in buffer:
TypeError: 'in ' requires string as left operand, not bytes

--- Test #2 (works): Telnet.interact on Python 2.6.4 Windows ---

Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from telnetlib import Telnet
>>> tn = Telnet("scn.org", 23)
>>> tn.interact()

Seattle Community Network Sun Solaris 1.1.1.B
Please login as 'visitor' if you are a visitor


SunOS UNIX (scn)

login:

--- Test #3 (works): Telnet.interact on Python 3.1.1 Linux ---

m...@ebx2009:~$ python3.1
Python 3.1.1 (r311:74480, Oct 18 2009, 19:21:53) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from telnetlib import Telnet
>>> tn = Telnet("scn.org", 23)
>>> tn.interact()

Seattle Community Network Sun Solaris 1.1.1.B
Please login as 'visitor' if you are a visitor


SunOS UNIX (scn)

login:

--
components: Library (Lib), Windows
messages: 98174
nosy: mnewman
severity: normal
status: open
title: telnetlib Telnet.interact fails on Windows but not Linux
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

[issue7723] sqlite only accept buffer() for BLOB objects (input/output)

[Pablo Mouzo]

Pablo Mouzo  added the comment:

I'm attaching a correction to sqlite3 documentation, removing all 'buffer' 
references and setting bytes as BLOB equivalent.

--
keywords: +patch
nosy: +pablomouzo
Added file: http://bugs.python.org/file15977/issue7723-py3k-docs.diff

___
Python tracker 

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

[issue6045] Fix dbm interfaces

[Pablo Mouzo]

Changes by Pablo Mouzo :


--
nosy: +pablomouzo

___
Python tracker 

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

[issue7762] (C API) PyUnicode_Tailmatch documentation

[July Tikhonov]

New submission from July Tikhonov :

It mentions "Return value: New reference.", but I have no idea of what it can 
mean in this function, since the return type is 'int'.

http://docs.python.org/dev/py3k/c-api/unicode.html#PyUnicode_Tailmatch

--
assignee: georg.brandl
components: Documentation
messages: 98176
nosy: georg.brandl, july
severity: normal
status: open
title: (C API) PyUnicode_Tailmatch documentation
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

[issue7763] (C API) PyUnicode_Tailmatch documentation

[July Tikhonov]

New submission from July Tikhonov :

It mentions "Return value: New reference.", but I have no idea of what it can 
mean in this function, since the return type is 'int'.

http://docs.python.org/dev/py3k/c-api/unicode.html#PyUnicode_Tailmatch

--
assignee: georg.brandl
components: Documentation
messages: 98177
nosy: georg.brandl, july
severity: normal
status: open
title: (C API) PyUnicode_Tailmatch documentation
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