[issue3475] _elementtree.c import can fail silently

[Brian Harring]

Brian Harring  added the comment:

At this point, this affects 2.5, 2.6, and 3.1 (and the normal 1.0.5
release of cElementTree); what's required to get this fixed and queued
up for micro/minor releases?

Sidenote, the patch posted above still leaks a reference-

--
keywords: +patch
nosy: +ferringb
Added file: http://bugs.python.org/file15290/fix-celementtree.patch

___
Python tracker 

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

[issue7278] decimal.py: New instance vs. new reference

[Raymond Hettinger]

Raymond Hettinger  added the comment:

Stefan, this is a non-guaranteed implementation detail (for both ints
and decimals).

--
nosy: +rhettinger
resolution:  -> invalid
status: open -> closed

___
Python tracker 

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

[issue7286] odd exec() behavior or documentation

[Peter Mawhorter]

New submission from Peter Mawhorter :

The behavior of the built-in exec() function differs in Python3.1 from
the behavior in Python 2.6 when only a single argument is passed.
Additionally, the documentation for the function does not suggest the
behavior that it has. In Python2.6, an exec statement could both access
and change the values of local variables. In Python3.1, it can read
values from the local scope, but can't change them. Run the attached
script to see examples of this behavior. Note especially that in the
first function, the exec'd code changes the value of a variable called
'value'. However, the change isn't visible after the call to exec(),
because the value changed was a local variable and presumably, the
update is dropped after the exec() finishes. To me, this conflicts with
the statement in the documentation that "In all cases, if the optional
parts are omitted, the code is executed in the current scope." At the
very least, a sentence or two should be added to the documentation
explaining that exec() can't affect the value of local variables. In
addition, it's strange that, for example, in a function declaring
"global value", an exec() statement that modifies 'value' doesn't affect
the value of the global variable. In this sense, the code being exec'd
doesn't seem to be running in a perfect copy of the function's scope.

If it were up to me, I'd allow code being executed by an exec()
statement to modify the value of local variables, because that keeps
with the paradigm of the exec'd code being simply dynamic code that
behaves as if it were written in-line. It also means that programmers
who need to change things with an exec statement aren't limited to
pushing their changes through global variables, which can lead to
conflicts with name sharing (for example, what if my exec() statement is
in a recursive function?). Of course, implementing this may be
difficult... so it may be better just to add to the documentation to
explain this behavior of exec().

--
assignee: georg.brandl
components: Documentation, Interpreter Core
files: test.py
messages: 95036
nosy: georg.brandl, pmawhorter
severity: normal
status: open
title: odd exec() behavior or documentation
type: behavior
versions: Python 3.1
Added file: http://bugs.python.org/file15289/test.py

___
Python tracker 

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

[issue7285] multiprocessing module, example code error

[Benjamin Peterson]

Changes by Benjamin Peterson :


--
assignee: georg.brandl -> jnoller
nosy: +jnoller

___
Python tracker 

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

[issue7285] multiprocessing module, example code error

[Kouki Hashimoto]

New submission from Kouki Hashimoto :

Example codes on multiprocessing module occur errors.
I attached the patch to fix these errors.

http://docs.python.org/dev/py3k/library/multiprocessing.html#module-
multiprocessing
"16.6.2.10. Listeners and Clients" section

Fix points are
1. Listener argument "authkey" must be a byte string
2. Client argument "authkey" must be a byte string
3. send_bytes argument must be a byte string

This is the server code listed on the section.
$ cat mpserver.py
from multiprocessing.connection import Listener
from array import array
address = ('localhost', 6000) # family is deduced to be 'AF_INET'
listener = Listener(address, authkey='secret password')
conn = listener.accept()
print('connection accepted from', listener.last_accepted)
conn.send([2.25, None, 'junk', float])
conn.send_bytes('hello')
conn.send_bytes(array('i', [42, 1729]))
conn.close()
listener.close()

And the error is
$ python3.2 mpserver.py
Traceback (most recent call last):
  File "mpserver1.py", line 5, in 
listener = Listener(address, authkey='secret password')
  File 
"/Users/kosmos/local/stow/py3k/lib/python3.2/multiprocessing/connection.
py", line 100, in __init__
raise TypeError('authkey should be a byte string')
TypeError: authkey should be a byte string

My source code is svn revision 76151.
Regards.

---
Kouki Hashimoto
hsm...@gmail.com

--
assignee: georg.brandl
components: Documentation
files: multiprocessing.rst.diff
keywords: patch
messages: 95035
nosy: georg.brandl, hsmtkk
severity: normal
status: open
title: multiprocessing module, example code error
type: behavior
versions: Python 3.2
Added file: http://bugs.python.org/file15288/multiprocessing.rst.diff

___
Python tracker 

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

[issue7284] optparse - display version in usage by default

[anatoly techtonik]

New submission from anatoly techtonik :

It would be useful if optparse could display version right in usage help 
before command syntax. Right now it can only output either usage or 
version.

--
messages: 95034
nosy: techtonik
severity: normal
status: open
title: optparse - display version in usage by default
type: feature request

___
Python tracker 

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

[issue7283] test_site failure when .local/lib/pythonX.Y/site-packages hasn't been created yet

[Antoine Pitrou]

Changes by Antoine Pitrou :


--
title: test_site failure when Python gets installed along a symbolic link -> 
test_site failure when .local/lib/pythonX.Y/site-packages hasn't been created 
yet

___
Python tracker 

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

[issue7281] copysign() with NaN arguments on OpenSolaris

[Mark Dickinson]

Mark Dickinson  added the comment:

You may have let yourself in for something here.  :-)

Can you tell me what:

>>> import sys
>>> print sys.float_repr_style

gives for your Opensolaris/suncc/Python3.x combination?  If it prints 
'legacy', then I'd dearly like some help with making it read 'short' 
instead.  That would then make treatment of nans on that combination 
consistent with other platforms.

All I really need to know is how to set the x87 (I'm assuming you're on 
32-bit x86 here) FPU control word using suncc.  Oh, and a willing victim 
to test changes.  Look for HAVE_PY_SET_53BIT_PRECISION in 
Include/pyport.h for details.


Having said that, I don't really see this difference with nans as an 
actual bug.  Is it possible that float("nan") is simply giving a nan 
with its sign bit set here, and that float("-nan") is giving a nan with 
no sign bit set?  That would actually be quite unsurprising, since 
according to Intel's manuals, the 'default' NaN value returned by 
invalid operations has its sign bit set.  It would also be (I think) 
quite legal:  sign bits of NaNs don't make a lot of sense anyway, and I 
don't think Python should specify anything about the sign bit (or indeed 
the payload) of the NaN coming from float('nan').

In other words, I think it's not unreasonable to regard the sign of
copysign(x, y) as undefined whenever y is a nan.  (I'm fairly sure that 
MPFR takes this attitude, for example.)

--

___
Python tracker 

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

[issue7283] test_site failure when Python gets installed along a symbolic link

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Well, I'm not sure the symlink is actually the problem. Apparently the
".local" directory hadn't been created when the first test run.

--

___
Python tracker 

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

[issue7283] test_site failure when Python gets installed along a symbolic link

[Antoine Pitrou]

New submission from Antoine Pitrou :

On that buildbot, /var/lib/buildbot is a symlink to /home/buildbot and I
get the following failure:

==
FAIL: test_s_option (test.test_site.HelperFunctionsTests)
--
Traceback (most recent call last):
  File
"/home/buildbot/cpython-ucs2/3.x.pitrou-ubuntu/build/Lib/test/test_site.py",
line 107, in test_s_option
self.assertIn(usersite, sys.path)
AssertionError: '/var/lib/buildbot/.local/lib/python3.2/site-packages'
not found in ['/usr/local/lib/python32.zip',
'/home/buildbot/cpython-ucs2/3.x.pitrou-ubuntu/build/Lib',
'/home/buildbot/cpython-ucs2/3.x.pitrou-ubuntu/build/Lib/plat-linux2',
'/home/buildbot/cpython-ucs2/3.x.pitrou-ubuntu/build/Modules',
'/home/buildbot/cpython-ucs2/3.x.pitrou-ubuntu/build/build/lib.linux-x86_64-3.2-pydebug']

--

--
assignee: tarek
components: Tests
messages: 95031
nosy: pitrou, tarek
priority: normal
severity: normal
stage: needs patch
status: open
title: test_site failure when Python gets installed along a symbolic link
type: behavior
versions: Python 2.7, Python 3.2

___
Python tracker 

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

[issue7278] decimal.py: New instance vs. new reference

[Mark Dickinson]

Mark Dickinson  added the comment:

I don't think it should matter whether either 'id(x) == id(y)' returns 
True or False:  since both ints and Decimals are regarded as immutable, 
the implementation should be free to reuse (or not) existing objects at 
will.

There is a test in test_decimal.py that seems to expect that Decimal(x) 
always returns a copy.  I'm not quite sure why that test is there, 
though it may be because Decimal instances weren't always as immutable 
as they are now (some of the non-__new__ methods used to modify the 
Decimal fields directly).  In my opinion that test could be removed, but 
I'd like to consult with some of the other Decimal authors before doing 
so.

(An aside: it's important to note that operations on Decimal subclasses 
should always return *Decimal* instances, not instances of the subclass.
So any code like:

  if isinstance(x, Decimal): return x

should be regarded with suspicion.)

N.B. Some of your recent reports seem more like questions about the 
implementation rather than reports of possible bugs in Python;  I'm not 
sure that the bug tracker is the best medium for this.  python-dev might 
be more appropriate, or I'm happy to answer private emails.

--

___
Python tracker 

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

[issue7282] RLocks leak references when used in raw threads

[Antoine Pitrou]

New submission from Antoine Pitrou :

When you use an RLock from a thread which wasn't created through the
high-level `threading` API (but, for example, using
thread.start_new_thread()), the RLock creates a DummyThread object by
calling current_thread(), and that DummyThread is immortal (as well as
its attributes etc.). This implementation wart can easily lead to
reference leaks for unsuspecting users.

One simple solution is not to call current_thread() in RLock, but use
get_ident() instead. Patch attached.

--
components: Library (Lib)
files: rlock_leak.patch
keywords: patch
messages: 95029
nosy: pitrou
priority: normal
severity: normal
stage: patch review
status: open
title: RLocks leak references when used in raw threads
type: resource usage
versions: Python 2.7, Python 3.2
Added file: http://bugs.python.org/file15287/rlock_leak.patch

___
Python tracker 

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

[issue7187] importlib/_bootstrap.py write_bytecode raises an IOError if it can't open the .pyc file for writing

[Brett Cannon]

Brett Cannon  added the comment:

Committed to py3k in r76146 and r76147 for 3.1.

Thanks for the detailed report, Dave!

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

[issue7278] decimal.py: New instance vs. new reference

[Stefan Krah]

Changes by Stefan Krah :


--
type:  -> behavior

___
Python tracker 

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

[issue7279] decimal.py: == and != comparisons involving NaNs

[Stefan Krah]

Changes by Stefan Krah :


--
type:  -> behavior

___
Python tracker 

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

[issue7281] copysign() with NaN arguments on OpenSolaris

[Stefan Krah]

New submission from Stefan Krah :

Sorry to report so many obscure corner cases. With the combination
Opensolaris/suncc/Python3.x copysign() gives reversed results when the
second argument is a NaN. The bug is in the C99 copysign() function
(OpenSolaris/suncc), but Python2.6 seems to have a workaround: 

Python 3.2a0 (py3k:76144, Nov  7 2009, 18:50:00) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import *
>>> copysign(1.0, float("nan"))
-1.0
>>> copysign(1.0, float("-nan"))
1.0

Python 2.6.2 (r262:71600, Nov  7 2009, 19:29:52) [C] on sunos5
Type "help", "copyright", "credits" or "license" for more information.
>>> from math import copysign
>>> copysign(1.0, float("nan"))
1.0
>>> copysign(1.0, float("-nan"))
-1.0
>>>

--
messages: 95027
nosy: mark.dickinson, skrah
severity: normal
status: open
title: copysign() with NaN arguments on OpenSolaris
type: behavior
versions: 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

[issue4722] _winreg.QueryValue fault while reading mangled registry values

[Brian Curtin]

Brian Curtin  added the comment:

It happens to me on trunk with Windows XP. I also have access to Windows
Server 2003 where I can test this (haven't yet). Which version are you
running that you don't see this issue?

--

___
Python tracker 

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

[issue7280] PCBuild instruction says to use nasmw.exe but it no longer exist

[Baptiste Lepilleur]

New submission from Baptiste Lepilleur :

PCBuild requires nasmw.exe but it no longer exists in the latest version
of nasm. 

I had to rename nasm.exe to nasmw.exe. Would be nice to add this to the
readme to avoid confusion...

--
components: Build
files: nasm-doc.patch
keywords: patch
messages: 95025
nosy: blep
severity: normal
status: open
title: PCBuild instruction says to use nasmw.exe but it no longer exist
versions: Python 3.1
Added file: http://bugs.python.org/file15286/nasm-doc.patch

___
Python tracker 

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

[issue3001] RLock's are SLOW

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Yes, here is a new patch adding tp_repr.

--
Added file: http://bugs.python.org/file15285/rlock4.patch

___
Python tracker 

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

[issue3001] RLock's are SLOW

[Gregory P. Smith]

Gregory P. Smith  added the comment:

Can you make the C implementation's repr() show something similar to the 
Python implementation?

--

___
Python tracker 

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

[issue3001] RLock's are SLOW

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Here is an updated patch. I addressed all review comments, except the
one about acquire_restore() checking the return result of acquire(),
because I think it's really a weakness in the Python implementation.

--
Added file: http://bugs.python.org/file15284/rlock3.patch

___
Python tracker 

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

[issue3488] Provide compress/uncompress functions on the gzip module

[Anand B Pillai]

Anand B Pillai  added the comment:

Uploading rst documentation svn diff for module.

--
Added file: http://bugs.python.org/file15283/gzip.rst.svndiff

___
Python tracker 

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

[issue3488] Provide compress/uncompress functions on the gzip module

[Anand B Pillai]

Anand B Pillai  added the comment:

Uploading fresh gzip.py SVN diff with a minor change, i.e accepting a
regular string as argument, aka zlib.compress.

--
Added file: http://bugs.python.org/file15282/gzip.py.svndiff

___
Python tracker 

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

[issue3488] Provide compress/uncompress functions on the gzip module

[Anand B Pillai]

Changes by Anand B Pillai :


Removed file: http://bugs.python.org/file11050/gzip_svn_diff.patch

___
Python tracker 

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

[issue3488] Provide compress/uncompress functions on the gzip module

[Anand B Pillai]

Changes by Anand B Pillai :


Removed file: http://bugs.python.org/file11044/gzip.patch

___
Python tracker 

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

[issue3488] Provide compress/uncompress functions on the gzip module

[Anand B Pillai]

Changes by Anand B Pillai :


Removed file: http://bugs.python.org/file11035/gzip_patch.py

___
Python tracker 

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

[issue3001] RLock's are SLOW

[Antoine Pitrou]

Antoine Pitrou  added the comment:

> rlock_acquire_doc: "(...) return None once the lock is acquired".
> That's wrong, acquire() always return a boolean (True or False).

You're right, I should fix that docstring.

> rlock_release(): Is the assert(self->rlock_count > 0); really required?
> You're checking its value few lines before.

Right again :) I forgot this was unsigned.

> rlock_acquire_restore(): raise an error if the lock acquire failed,
> whereas rlock_acquire() doesn't. Why not raising an error in
> rlock_acquire() (especially if blocking is True)?

For rlock_acquire(), I mimicked what the Python code (_PyRLock.acquire)
does: if locking fails, it returns False instead. It is part of the API.

(and I agree this is not necessarily right, because failing to lock if
blocking is True would probably indicate a low-level system error, but
the purpose of the patch is not to change the API)

But you're right that the Python version of rlock_acquire_restore()
doesn't check the return code either, so I may remove this check from
the C code, although the rest of the method clearly assumes the lock has
been taken.

> rlock_acquire_restore(): (maybe) set owner to 0 if count is 0.
> 
> rlock_release_save(): may also reset self->rlock_owner to 0, as
> rlock_release().

As I said to Gregory, the current code doesn't rely on rlock_owner to be
reset but, yes, we could still add it out of safety.

> rlock_new(): why not reusing type instead of Py_TYPE(self) in
> "Py_TYPE(self)->tp_free(self)"?

Good point.

> __exit__: rlock_release() is defined as __exit__() with METH_VARARGS,
> but it has no argument. Can it be a problem?

I just mimicked the corresponding declarations in the non-recursive lock
object. Apparently it's safe on all architectures Python has been
running on for years, although I agree it looks strange.

> If your patch is commited, you can reconsider #3618 (possible deadlock
> in python IO implementation).

Indeed.

Thanks !

--

___
Python tracker 

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

[issue3001] RLock's are SLOW

[Antoine Pitrou]

Antoine Pitrou  added the comment:

Thanks for the review. I will make the suggested modifications.

http://codereview.appspot.com/150055/diff/1/4
File Modules/_threadmodule.c (right):

http://codereview.appspot.com/150055/diff/1/4#newcode221
Modules/_threadmodule.c:221: return PyBool_FromLong((long) r);
On 2009/11/07 07:48:05, gregory.p.smith wrote:
> This explicit (long) cast is unnecessary.

Right.

http://codereview.appspot.com/150055/diff/1/4#newcode246
Modules/_threadmodule.c:246: PyThread_release_lock(self->rlock_lock);
On 2009/11/07 07:48:05, gregory.p.smith wrote:
> reset self->rlock_owner to 0 before releasing the lock.

We always check rlock_count before rlock_owner anyway but, yes, I could
reset rlock_owner out of safety.

http://codereview.appspot.com/150055

--

___
Python tracker 

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

[issue7279] decimal.py: == and != comparisons involving NaNs

[Stefan Krah]

New submission from Stefan Krah :

I'm not sure this is a bug, but I am trying to understand the rationale
for mimicking IEEE 754 for == and != comparisons involving NaNs. The
comment in decimal.py says:

"Note: The Decimal standard doesn't cover rich comparisons for Decimals.
 In particular, the specification is silent on the subject of what
should happen for a comparison involving a NaN."


First, I think rich comparisons are covered with compare_total(), but
indeed that isn't very useful for == and !=. (It might be useful for
sorting a list of decimals.)

The standard compare() function returns NaN for comparisons involving
NaNs. In addition to that it signals for sNaNs. I'm interpreting this as
"the comparison is undefined". So, in terms of decimal return values,
the standard does define NaN comparisons.

The question remains how to translate "undefined" to a Python truth
value. I'd think that the natural thing is to raise an InvalidOperation
exception in the same way it is done for <, <=, >, >=.


This ...

Decimal("NaN") == 9  ==> InvalidOperation
Decimal("sNaN") == 9  ==> InvalidOperation

... is the behavior of compare_signal(). In my opinion this would follow
the principle of least surprise for the user.

--
messages: 95017
nosy: mark.dickinson, skrah
severity: normal
status: open
title: decimal.py: == and != comparisons involving NaNs

___
Python tracker 

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

[issue7268] 2to3 execfile conversion changes behavior

[Gabriel Genellina]

Gabriel Genellina  added the comment:

This is a patch for the execfile fixer, so it converts
execfile("fn")
into this:
exec(compile(open("fn").read()+'\n', "fn", 'exec'))

(Yes, it looks ugly. A better way would be to fix the compile() builtin 
so it does not require the last line of source to end with '\n')

This is my very first incursion into 2to3 so it may be terribly wrong...

--
keywords: +patch
Added file: http://bugs.python.org/file15281/lib2to3.diff

___
Python tracker 

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

[issue7278] decimal.py: New instance vs. new reference

[Stefan Krah]

New submission from Stefan Krah :

In the following case, Decimal() and int() behave differently. I wonder
if this is intentional:

>>> from decimal import *
>>> x = Decimal(2)
>>> y = Decimal(x)
>>> id(x) == id(y)
False
>>> 
>>> x = int(2)
>>> y = int(x)
>>> id(x) == id(y)
True
>>>

--
messages: 95015
nosy: mark.dickinson, skrah
severity: normal
status: open
title: decimal.py: New instance vs. new reference

___
Python tracker 

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

[issue3001] RLock's are SLOW

[STINNER Victor]

STINNER Victor  added the comment:

rlock_acquire_doc: "(...) return None once the lock is acquired".
That's wrong, acquire() always return a boolean (True or False).

rlock_release(): Is the assert(self->rlock_count > 0); really required?
You're checking its value few lines before.

rlock_acquire_restore(): raise an error if the lock acquire failed,
whereas rlock_acquire() doesn't. Why not raising an error in
rlock_acquire() (especially if blocking is True)? Or if the error can
never occur, remove the error checking in rlock_acquire_restore().

rlock_acquire_restore(): (maybe) set owner to 0 if count is 0.

rlock_release_save(): may also reset self->rlock_owner to 0, as
rlock_release().

rlock_new(): why not reusing type instead of Py_TYPE(self) in
"Py_TYPE(self)->tp_free(self)"?

__exit__: rlock_release() is defined as __exit__() with METH_VARARGS,
but it has no argument. Can it be a problem?

Anything, thanks for the faster RLock!

If your patch is commited, you can reconsider #3618 (possible deadlock
in python IO implementation).

--

___
Python tracker 

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

[issue7271] Typo in turtle module documentation.

[Georg Brandl]

Georg Brandl  added the comment:

Fixed in r76143.

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