[issue2855] lookkey should INCREF/DECREF startkey around PyObject_RichCompareBool
Raymond Hettinger [EMAIL PROTECTED] added the comment: Fixed r63806. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2855 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2903] Add __name__ in globals of generated namedtuple namespace
Raymond Hettinger [EMAIL PROTECTED] added the comment: Added the simpler first part of the patch in r63807. Thanks for the submission. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2903 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3008] Let bin() show floats
New submission from Raymond Hettinger [EMAIL PROTECTED]: Let bin() show floating point values. This would contribute quite a bit to people's understanding of floating point arithmetic. It has a nice education value and it makes it easier to diagnose floating point mysteries. def vis(f): Show binary representation of a floating point number: vis(math.pi) '0b11.001001110110101010001000110110100011' vis(-0.375) '-0b0.011' f, sign = (f, '') if f = 0 else (-f, '-') n, d = f.as_integer_ratio() if isinstance(f, float) else (f, 1) n, d = map(lambda x: bin(x)[2:], (n, d)) n = n.rjust(len(d), '0') s = list(n) s.insert(len(n) - len(d) + 1, '.') return sign + '0b' + ''.join(s) -- components: Interpreter Core messages: 67525 nosy: rhettinger severity: normal status: open title: Let bin() show floats type: feature request versions: Python 2.6, Python 3.0 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2999] Py30a5: str.replace() tiny doc error
Georg Brandl [EMAIL PROTECTED] added the comment: Thanks, fixed in r63808. -- resolution: - fixed status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2999 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2999] Py30a5: str.replace() tiny doc error
Georg Brandl [EMAIL PROTECTED] added the comment: Fixed all return types in docstrings of str, bytes, bytearray in r63809. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2999 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2985] xmlrpclib doesn't support 64bit integer replies
Georg Brandl [EMAIL PROTECTED] added the comment: As long as long integers aren't in the official spec, the current status is fine - liberal in accepting, and strict in sending. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2985 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2954] [PATCH] Make bisect module functions accept an optional comparison callable
Leandro Lucarella [EMAIL PROTECTED] added the comment: Is there any way to find the duplicated issue to see the resolution and find out why it has been rejected? Thank you. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2954 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3008] Let bin() show floats
Alexander Belopolsky [EMAIL PROTECTED] added the comment:
On Fri, May 30, 2008 at 10:52 AM, Antoine Pitrou [EMAIL PROTECTED] wrote:
Antoine Pitrou [EMAIL PROTECTED] added the comment:
Well it's quite simple. Imagine you have a function f() which takes an
integer parameter named x, and somewhere applies bin() to this parameters.
This is too abstract. Depending on what f() is designed to do,
accepting floats may or may not be the right thing. For example, if
bin is used inside f() only to produce some log output, but
otherwise f() works on any number, promiscuous bin() will actually
make an application using f() more robust.
Right now, if you call f(1.0) instead of f(1), you will get a TypeError,
which is easy to detect: you then fix the call to f(1), and bin()
produces the expected result ('0b1').
There is no right now. Builtin bin is new in 2.6.
..
There is a reason Python recently introduced a stronger distinction
between ints and floats (for instance the __index__ method, which bin()
seems to use currently), I don't see the logic behind trying to undo it.
I think you are mistaken. Python always distinguished between floats
and integers
Traceback (most recent call last):
File stdin, line 1, in ?
TypeError: list indices must be integers
int.__index__
Traceback (most recent call last):
File stdin, line 1, in ?
AttributeError: type object 'int' has no attribute '__index__'
__index__ was introduced in order to allow user-defined class
instances to be used as indices without affecting the way floats are
treated.
And it's not like printing the bin() representation of a float has any
actually use (besides education, but education can use its own tools
rather than builtin functions).
That's exactly my point. Builtin bin being new, I cannot comment on
its actual use, but I've only used hex() in interactive sessions as an
easy to type alternative to the finger-twisting 0x%x % incantation.
(IMO, {0:b}.format(..) is even worse.) In the scripts, however, you
would rarely need to create a string representation of single number.
More often you will need to embed a number in a larger message and
thus you will use % or str.format instead of bin/hex/oct anyways.
BTW, google code search quickly revealed the following antipattern:
log.msg(real checksum: %s%hex(hdr[19]))
(twisted-Zope-3.2.2/twisted/words/protocols/toc.py)
Surely real checksum: %x % hdr[19] would be a better choice. (The
0x prefix generated by hex is just noise in the log output.)
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3008
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3008] Let bin() show floats
Alexander Belopolsky [EMAIL PROTECTED] added the comment:
While writing my previous comments I did not realize that '%x' % accepts
floats:
%x % 3.1415
'3'
Float support has been even improved somewhat since 2.5:
Python 2.5 (r25:51908, Nov 24 2006, 11:03:50)
'%x' % 1e10
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: int argument required
The new stile formatting, however does not allow floats with either :x
or :b formats:
{0:x}.format(1.)
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: Unknown conversion type x
{0:b}.format(1.)
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: Unknown conversion type b
I don't think anything needs to be done about it given that % formatting
is being deprecated while new style format is doing the right thing IMO.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3008
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3008] Let bin() show floats
Antoine Pitrou [EMAIL PROTECTED] added the comment: I think you are mistaken. Python always distinguished between floats and integers Sorry, my bad. For example, if bin is used inside f() only to produce some log output, but otherwise f() works on any number, promiscuous bin() will actually make an application using f() more robust. First I'm not sure bizarre log output should be considered more robust. Second if you are outputting the bin() of an integer as part of a log output, it probably means the integer should be understood as a kind of bitfield, and then I don't see how accepting float values is more robust (again). Anyway Python doesn't accept floats for bit-wise operators (e.g. 1.0128 raises TypeError). I still find this proposal undesirable, for several reasons: 1. while taking the binary representation of an integer has a real meaning, taking the binary representation of a float only exposes an implementation detail, that is the internal layout of float numbers. 2. if two numbers (one integer and one float) are equal, it sounds expectable that calling a function on them will produce similar output (or fail). Of course, this is not always the case, str(1) and str(1.0) are different. But they are not wildly different and the difference is still easily understood. While getting something like '0b11.001001110110101010001000110110100011' while you were waiting for '0b11' is disturbing. 3. I'm skeptical about the educational value. People who don't know about the internal layout of float numbers won't very likely feel enlightened by a string of 1s and 0s. Showing a bunch of bits does not really explain a structure. One related feature, though, would be to know whether a string representation of a float is exact or not. If we allowed repr() to lose its round-trippability, this could be implemented by making repr(0.5) return 0.5 (exact) and repr(0.1) return 0.10001 (inexact). Or this could be a dedicated method. While writing my previous comments I did not realize that '%x' % accepts floats: And witness how it does something rather intuitive (convert the argument to int) rather than show the internal layout of the float number in hexadecimal form :-) ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3008] Let bin() show floats
Alexander Belopolsky [EMAIL PROTECTED] added the comment: On Fri, May 30, 2008 at 1:47 PM, Antoine Pitrou [EMAIL PROTECTED] wrote: .. 2. if two numbers (one integer and one float) are equal, it sounds expectable that calling a function on them will produce similar output (or fail). .. While getting something like '0b11.001001110110101010001000110110100011' while you were waiting for '0b11' is disturbing. I fail to see how the proposed bin(..) can produce '0b11.00100..' from a float that compares equal to 3. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3008] Let bin() show floats
Alexander Belopolsky [EMAIL PROTECTED] added the comment: On Fri, May 30, 2008 at 1:47 PM, Antoine Pitrou [EMAIL PROTECTED] wrote: .. 1. while taking the binary representation of an integer has a real meaning, taking the binary representation of a float only exposes an implementation detail, that is the internal layout of float numbers. You may have misunderstood the proposal. I read the proposal as producing the true mathematical radix 2 representation of a float rather than its 64-bit memory layout. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3008] Let bin() show floats
Alexander Belopolsky [EMAIL PROTECTED] added the comment: What would you say to adding float-capable bin/oct/hex (+ maybe tobase) to the math module? ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3008] Let bin() show floats
Antoine Pitrou [EMAIL PROTECTED] added the comment: I read the proposal as producing the true mathematical radix 2 representation of a float rather than its 64-bit memory layout. The term layout was probably badly chosen. Still, the explicit motivation for producing that representation is that it it supposed to educate people about the actual implementation of floats. Other than that, a radix 2 representation is quite an obscure (and almost never used) way of representing float objects. Binary representation of integers in comparison is more widely understood and more frequently used, which -- I suppose -- justifies the existence of a builtin function to obtain it. I fail to see how the proposed bin(..) can produce '0b11.00100..' from a float that compares equal to 3. Oops, you are right. bin(3.0) would produce '0b11.', which is indeed more readable. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3008] Let bin() show floats
Raymond Hettinger [EMAIL PROTECTED] added the comment: Better to just build-out bin() and be done with it. FWIW, the action on ints and floats is similar to how str() handles numeric inputs: str(3) -- '3' str(3.0) -- '3.0' bin(3) -- '0b11' bin(3.0) -- '0b11.0' -- assignee: - rhettinger ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3008] Let bin() show floats
Alexander Belopolsky [EMAIL PROTECTED] added the comment: Another problem with bin() on floats is that it will be a one-way street because as far as I know, there is no function to convert a binary string back to a float. My last thought on this issue is that it will be helpful to add tobase(f, n) and frombase(s,n) functions to math module (and I withdraw my suggestion of using %g-like notation due to the conflict between E for exponent and E for 0xE). On the other hand, there is no need to mess up with builtin bin/oct/hex because with math.tobase float-capable extensions will be trivially implementable. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue708007] TelnetPopen3, TelnetBase, Expect split
Guido van Rossum [EMAIL PROTECTED] added the comment: Since Pexpect is alive and well, doesn't it satisfy your needs? What's the point of trying to push an alternative implementation that has lingered for 7 years now? -- nosy: +gvanrossum ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue708007 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3008] Let bin() show floats
Alexander Belopolsky [EMAIL PROTECTED] added the comment: On Fri, May 30, 2008 at 2:32 PM, Antoine Pitrou [EMAIL PROTECTED] wrote: then why not make it a method of float? .. because you rarely want to make your functions accept 1.0, but reject 1 and using f.bin() in your function will give it this property. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3008 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2507] Exception state lives too long in 3.0
Changes by Adam Olsen [EMAIL PROTECTED]: -- nosy: +Rhamphoryncus ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2507 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Thomas Heller [EMAIL PROTECTED] added the comment:
Here is a patch implementing the plan. This text could serve as a start for the
documentation, but it also describes the current implementation. Usage recipes
should probably be added:
/*
ctypes maintains a module-global, but thread-local, variable that contains
an error number; called 'ctypes_errno' for this discussion. This variable
is a private copy of the stdlib 'errno' value; it is swapped with the
'errno' variable on several occasions.
Foreign functions created with CDLL(..., use_errno=True), when called, swap
the values just before they are actual function call, and swapped again
afterwards. The 'use_errno' parameter defaults to False, in this case
ctypes_errno is not touched.
The values are also swapped immeditately before and after ctypes callback
functions are called, if the callbacks are constructed using the new
optional use_errno parameter for CFUNCTYPE(..., use_errno=TRUE) or
WINFUNCTYPE(..., use_errno=True).
Two new ctypes functions are provided to access the 'ctypes_errno' value
from Python:
- ctypes.set_errno(value) sets ctypes_errno to 'value', the previous
ctypes_errno value is returned.
- ctypes.get_errno() returns the current ctypes_errno value.
The same scheme is implemented on Windows for GetLastError() and
SetLastError(), and the CDLL and WinDLL optional parameter is named
'use_LastError', and also defaults to False.
On Windows, TlsSetValue and TlsGetValue calls are used to provide thread
local storage for the variables; ctypes compiled with __GNUC__ uses __thread
variables.
*/
Added file: http://bugs.python.org/file10480/ctypes-errno-3.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1798
___Index: Lib/ctypes/__init__.py
===
--- Lib/ctypes/__init__.py (revision 63822)
+++ Lib/ctypes/__init__.py (working copy)
@@ -33,7 +33,9 @@
DEFAULT_MODE = RTLD_GLOBAL
from _ctypes import FUNCFLAG_CDECL as _FUNCFLAG_CDECL, \
- FUNCFLAG_PYTHONAPI as _FUNCFLAG_PYTHONAPI
+ FUNCFLAG_PYTHONAPI as _FUNCFLAG_PYTHONAPI, \
+ FUNCFLAG_USE_ERRNO as _FUNCFLAG_USE_ERRNO, \
+ FUNCFLAG_USE_LASTERROR as _FUNCFLAG_USE_LASTERROR
WINOLEAPI - HRESULT
@@ -73,8 +75,8 @@
return create_string_buffer(init, size)
_c_functype_cache = {}
-def CFUNCTYPE(restype, *argtypes):
-CFUNCTYPE(restype, *argtypes) - function prototype.
+def CFUNCTYPE(restype, *argtypes, **kw):
+CFUNCTYPE(restype, *argtypes, **kw) - function prototype.
restype: the result type
argtypes: a sequence specifying the argument types
@@ -88,14 +90,21 @@
prototype((ordinal number, dll object)[, paramflags]) - foreign function
exported by ordinal
prototype((function name, dll object)[, paramflags]) - foreign function
exported by name
+flags = _FUNCFLAG_CDECL
+if kw.pop(use_errno, False):
+flags |= _FUNCFLAG_USE_ERRNO
+if kw.pop(use_LastError, False):
+flags |= _FUNCFLAG_USE_LASTERROR
+if kw:
+raise ValueError(unexpected keyword argument(s) %s % kw.keys())
try:
-return _c_functype_cache[(restype, argtypes)]
+return _c_functype_cache[(restype, argtypes, flags)]
except KeyError:
class CFunctionType(_CFuncPtr):
_argtypes_ = argtypes
_restype_ = restype
-_flags_ = _FUNCFLAG_CDECL
-_c_functype_cache[(restype, argtypes)] = CFunctionType
+_flags_ = flags
+_c_functype_cache[(restype, argtypes, flags)] = CFunctionType
return CFunctionType
if _os.name in (nt, ce):
@@ -106,16 +115,23 @@
_FUNCFLAG_STDCALL = _FUNCFLAG_CDECL
_win_functype_cache = {}
-def WINFUNCTYPE(restype, *argtypes):
+def WINFUNCTYPE(restype, *argtypes, **kw):
# docstring set later (very similar to CFUNCTYPE.__doc__)
+flags = _FUNCFLAG_STDCALL
+if kw.pop(use_errno, False):
+flags |= _FUNCFLAG_USE_ERRNO
+if kw.pop(use_LastError, False):
+flags |= _FUNCFLAG_USE_LASTERROR
+if kw:
+raise ValueError(unexpected keyword argument(s) %s % kw.keys())
try:
-return _win_functype_cache[(restype, argtypes)]
+return _win_functype_cache[(restype, argtypes, flags)]
except KeyError:
class WinFunctionType(_CFuncPtr):
_argtypes_ = argtypes
_restype_ = restype
-_flags_ = _FUNCFLAG_STDCALL
-_win_functype_cache[(restype, argtypes)] = WinFunctionType
+_flags_ = flags
+_win_functype_cache[(restype, argtypes, flags)] = WinFunctionType
return WinFunctionType
if WINFUNCTYPE.__doc__:
WINFUNCTYPE.__doc__ = CFUNCTYPE.__doc__.replace(CFUNCTYPE,
WINFUNCTYPE)
@@
[issue3011] locale module alias table needs to be updated
New submission from Marc-Andre Lemburg [EMAIL PROTECTED]: It's missing a lot of entries of the type [EMAIL PROTECTED] and was last updated in 2004. -- assignee: lemburg components: Library (Lib) messages: 67551 nosy: lemburg severity: normal status: open title: locale module alias table needs to be updated type: behavior versions: Python 2.6 ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3011 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1798] Add ctypes calling convention that allows safe access of errno
Thomas Heller [EMAIL PROTECTED] added the comment: Thomas Heller schrieb: Here is a patch implementing the plan. ctypes-errno-3.patch, in case of doubt. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1798 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3011] locale module alias table needs to be updated
Marc-Andre Lemburg [EMAIL PROTECTED] added the comment: It may be worth to backport the change to 2.5, since it causes problems with current Linux distributions that use the @euro extension as default. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3011 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2936] ctypes.util.find_library() doesn't consult LD_LIBRARY_PATH
Thomas Heller [EMAIL PROTECTED] added the comment: The question is, which linker? I think it should be ld.so, which links on demand, and does pay attention to LD_LIBRARY_PATH. I'm not sure what the point of find_library() is, otherwise. The best explanation is in the python docs: http://docs.python.org/lib/ctypes-finding-shared-libraries.html ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue2936 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3012] disutils fails with GNU ld (GNU Binutils) 2.18.50.20080523
New submission from John Arbash Meinel [EMAIL PROTECTED]:
I just upgraded my cygwin installation to the latest versions. Which
seems to include
GNU ld (GNU Binutils) 2.18.50.20080523
and
GNU dllwrap (GNU Binutils) 2.18.50.20080523
It seems that their version notation is now Major.Minor.Micro.Date
The problem is that in 'cygwincompiler.py' it does:
result = re.search('(\d+\.\d+(\.\d+)*)',out_string)
if result:
ld_version = StrictVersion(result.group(1))
Which matches the full version string. However StrictVersion only
supports A.B.CdE formats. So the .Date breaks the parser.
My workaround was to change the regex to be:
result = re.search('(\d+\.\d+(\.\d+)?)(\.\d+)*',out_string)
So it will still match an unlimited number of '.DDD' as it used to, but
now it only preserves the first 3 to pass to StrictVersion.
This may not be the correct fix, as a better fix might be to use
something else instead of StrictVersion (since these version numbers
explicitly *don't* match what StrictVersion expects.)
--
messages: 67556
nosy: jameinel
severity: normal
status: open
title: disutils fails with GNU ld (GNU Binutils) 2.18.50.20080523
type: compile error
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3012
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3013] disutils fails with GNU ld (GNU Binutils) 2.18.50.20080523
New submission from John Arbash Meinel [EMAIL PROTECTED]:
I just upgraded my cygwin installation to the latest versions. Which
seems to include
GNU ld (GNU Binutils) 2.18.50.20080523
and
GNU dllwrap (GNU Binutils) 2.18.50.20080523
It seems that their version notation is now Major.Minor.Micro.Date
The problem is that in 'cygwincompiler.py' it does:
result = re.search('(\d+\.\d+(\.\d+)*)',out_string)
if result:
ld_version = StrictVersion(result.group(1))
Which matches the full version string. However StrictVersion only
supports A.B.CdE formats. So the .Date breaks the parser.
My workaround was to change the regex to be:
result = re.search('(\d+\.\d+(\.\d+)?)(\.\d+)*',out_string)
So it will still match an unlimited number of '.DDD' as it used to, but
now it only preserves the first 3 to pass to StrictVersion.
This may not be the correct fix, as a better fix might be to use
something else instead of StrictVersion (since these version numbers
explicitly *don't* match what StrictVersion expects.)
--
messages: 67557
nosy: jameinel
severity: normal
status: open
title: disutils fails with GNU ld (GNU Binutils) 2.18.50.20080523
type: compile error
versions: Python 2.5
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3013
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3013] disutils fails with GNU ld (GNU Binutils) 2.18.50.20080523
Changes by John Arbash Meinel [EMAIL PROTECTED]: -- components: +Distutils ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3013 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3012] disutils fails with GNU ld (GNU Binutils) 2.18.50.20080523
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- resolution: - duplicate status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3012 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3012] disutils fails with GNU ld (GNU Binutils) 2.18.50.20080523
John Arbash Meinel [EMAIL PROTECTED] added the comment: can you link the bug that this is a dupe of? I did a search and didn't find anything. ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3012 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3012] disutils fails with GNU ld (GNU Binutils) 2.18.50.20080523
Benjamin Peterson [EMAIL PROTECTED] added the comment: Your own: #3013. :) -- nosy: +benjamin.peterson ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3012 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3013] disutils fails with GNU ld (GNU Binutils) 2.18.50.20080523
Changes by Benjamin Peterson [EMAIL PROTECTED]: -- keywords: +easy priority: - high ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3013 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3014] file_dealloc() assumes errno is set when EOF is returned
New submission from johansen [EMAIL PROTECTED]:
We're using Python to build the new packaging system for OpenSolaris.
Yesterday, a user reported that when they ran the pkg command, piped the
output to grep, and then typed ^C, sometimes they'd get this error:
$ pkg list | grep office
^Cclose failed: [Errno 11] Resource temporarily unavailable
We assumed that this might be a problem in the signal handling we've
employed to catch SIGPIPE; however, it turns out that the problem is in
the file_dealloc() code.
For the perversely curious, additional details may be found in the
original bug located here:
http://defect.opensolaris.org/bz/show_bug.cgi?id=2083
Essentially we found the following:
The error message is emitted from fileobject.c: file_dealloc()
The relevant portion of the routine looks like this:
static void
file_dealloc(PyFileObject *f)
{
int sts = 0;
if (f-weakreflist != NULL)
PyObject_ClearWeakRefs((PyObject *) f);
if (f-f_fp != NULL f-f_close != NULL) {
Py_BEGIN_ALLOW_THREADS
sts = (*f-f_close)(f-f_fp);
Py_END_ALLOW_THREADS
if (sts == EOF)
#ifdef HAVE_STRERROR
PySys_WriteStderr(close failed: [Errno %d] %s\n,
errno, strerror(errno));
In the cases we encountered, the function pointer f_close is actually a
call to sysmodule.c: _check_and_flush()
That routine looks like this:
static int
_check_and_flush (FILE *stream)
{
int prev_fail = ferror (stream);
return fflush (stream) || prev_fail ? EOF : 0;
}
check_and_flush calls ferror(3C) and then fflush(3C) on the FILE stream
associated with the file object. There's just one problem here. If it
finds an error that was previously encountered on the file stream,
there's no guarantee that errno will be valid. Should an error be
encountered in fflush(3C), errno will get set; however, the contents of
errno are undefined should fflush() return successfully.
Here's what happens in the code I observed:
I set a write watchpoint on errno and observed the different times it
was accessed. After sifting through a bunch of red-herrings, I found
that a call to PyThread_acquire_lock() that sets errno to 11 (EAGAIN).
This occurs when PyThread_acquire_lock() calls sem_trywait(3C) and finds
the semaphore already locked. Errno doesn't get accessed again until a
call to libc.so.1`isseekable() that simply saves and restores the
existing errno.
Since we've taken a ^C (SIGINT), the interpreter begins the finalization
process and eventually calls file_dealloc(). This routine calls
_check_and_flush(). In the case that I observed, ferror(3C)
returns a non-zero value but fflush(3C) completes successfully. This
causes the routine to return EOF to the caller. file_dealloc() assumes
that since it received an EOF an error occurred and it should call
strerror(errno). However, since this is just returning the state of a
previous error, errno is invalid.
This is what causes the spurious EAGAIN message. Just to be sure, I
traced the return value and errno of failed syscalls that were invoked
by the interpreter. I was unable to observe any syscalls returning
EAGAIN. This is because (at least on OpenSolaris) sem_trywait(3C) calls
sema_trywait(3C). The sema_trywait returns EBUSY if the semaphore is
held and sem_trywait converts this to EAGAIN. None of these errors are
passed out of the kernel.
It's not clear to me whether _check_and_flush(), file_dealloc(), or both
need modification. At a minimum, it's not safe for file_dealloc() to
assume that errno is set correctly if the function underneath it is
using ferror(3C) to find the presence of an error on the stream.
--
components: Interpreter Core
messages: 67560
nosy: johansen
severity: normal
status: open
title: file_dealloc() assumes errno is set when EOF is returned
type: behavior
versions: Python 2.4
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3014
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3015] tkinter with wantobjects=False has been broken for some time
New submission from Guilherme Polo [EMAIL PROTECTED]: This affects only py3k, but apparently tkinter has been in this situation for more than 9 months now. I see these lines at _tkinter.c: const char *s = Tcl_GetStringResult(self-interp); const char *p = s; res = PyUnicode_FromStringAndSize(s, (int)(p-s)); and I was wondering how could res not end up being an empty string always ? Then I did some quick tests here and the return is always an empty string, when wantobjects is set to False. Maybe the second line should be: const char *p = strchr(s, '\0'); I've attached this correction. Not sure if it is the best way to solve the problem. -- components: Tkinter files: tkinter_wantobjects.diff keywords: patch messages: 67562 nosy: gpolo severity: normal status: open title: tkinter with wantobjects=False has been broken for some time versions: Python 3.0 Added file: http://bugs.python.org/file10482/tkinter_wantobjects.diff ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3015 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3016] tarfile.py incurs exception from self.chmod() when tarball has g+s
New submission from Zooko O'Whielacronx [EMAIL PROTECTED]: As reported at https://bugs.launchpad.net/pyopenssl/+bug/236190 , tarfile.py incurs an Operation not permitted exception (on Mac OS 10.4) when it tries to untar the pyOpenSSL-0.6.tar.gz tarball, because that tarball has directories in it marked as having the g+s bit. (Why this leads to an Operation not permitted exception, I don't know.) -- messages: 67563 nosy: zooko severity: normal status: open title: tarfile.py incurs exception from self.chmod() when tarball has g+s type: behavior ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3016 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1764087] tiny addition to peephole optimizer
Raymond Hettinger [EMAIL PROTECTED] added the comment: This was previously rejected for two reasons. 1) It provided almost no measureable speed-up (the code for LOAD_FAST and DUP_TOP is substantially the same, the only real difference is the time to fetch the oparg). 2) The optimization typically crosses lines of source code, making it difficult to follow in a trace or disassembly. -- resolution: - rejected status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1764087 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1764986] generic and more efficient removal of unreachable code
Raymond Hettinger [EMAIL PROTECTED] added the comment: Not too excited about this. It adds to compilation time but doesn't save any runtime. It's not at all common for production code to have unreachable code at RAISE_VARARGS or BREAK_LOOP, so I see no reason to complexify to the peepholer to handle this case. -- nosy: +rhettinger resolution: - rejected status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1764986 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1765558] small improvement for peephole conditional jump optimizer
Raymond Hettinger [EMAIL PROTECTED] added the comment: This one does give a real speedup in the case of jumping to a UNARY_NOT followed by another conditional jump. My only issue is that it doesn't make it's transformation all at once. It relies on a subsequent pass to not change its assumptions. This tightly couples two pieces of peephole logic that are best left fully orthogonal lest we introduct maintenance problems. The fragility is compounded because a new basic block is formed and that is not recorded in the structure designed to track the blocks. At some point, many of the peephole optimizations are going to be moved upstream into a AST optimizer. That is a more appropriate place for this kind of transformation. Am closing this because it makes the code too fragile, but I think the idea was inspired and the implementation was clever. Thanks for the patch. -- nosy: +rhettinger resolution: - rejected status: open - closed ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue1765558 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3015] tkinter with wantobjects=False has been broken for some time
Martin v. Löwis [EMAIL PROTECTED] added the comment: I think in Python 3, the whole wantobjects=False case should go. It was a compatibility measure to support applications that didn't expect Tcl objects; for Python 3, only a single case should be supported. -- nosy: +loewis ___ Python tracker [EMAIL PROTECTED] http://bugs.python.org/issue3015 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
