[ python-Bugs-1772890 ] Py Lib Ref, 3.6.1 String Methods startswith() typo
Bugs item #1772890, was opened at 2007-08-13 02:10 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772890&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: 3rd Party Status: Open Resolution: None Priority: 5 Private: No Submitted By: arxaaron (arxaaron) Assigned to: Nobody/Anonymous (nobody) Summary: Py Lib Ref, 3.6.1 String Methods startswith() typo Initial Comment: Python Library Reference Section 3.6.1 "String Methods" = startswith(prefix[, start[, end]]) Return True if string starts with the prefix, otherwise return False. prefix can also be a tuple of __suffixes__ to look for. With optional start, test string beginning at that position. With optional end, stop comparing string at that position. = ...Believe "suffixes" should be corrected to "prefixes" (Likely a copy and paste oversight from the description for mirror method " endswith(suffix[, start[, end]])") Typo report of Jan. 2007 noted as closed, but error is still present. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772890&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772916 ] xmlrpclib crash when PyXML installed
Bugs item #1772916, was opened at 2007-08-13 18:15 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib crash when PyXML installed Initial Comment: The xmlrpclib module in the standard library will use a 3rd party C extension called "sgmlop" if it is present. The last version of PyXML (0.8.4) includes this module, but it causes crashes with Python 2.5 due to the use of mismatched memory allocation/deallocation functions (PyObject_NEW and PyMem_DEL). It is unlikely that sgmlop will be fixed, as PyXML is no longer maintained. Therefore sgmlop support should be removed from xmlrpclib. (In case you're wondering why anyone would install PyXML with Python 2.5 anyway: there are still some 3rd party libraries which depend upon PyXML, such as ZSI and twisted). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772890 ] Py Lib Ref, 3.6.1 String Methods startswith() typo
Bugs item #1772890, was opened at 2007-08-13 07:10 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772890&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: 3rd Party Status: Closed Resolution: Duplicate Priority: 5 Private: No Submitted By: arxaaron (arxaaron) Assigned to: Nobody/Anonymous (nobody) Summary: Py Lib Ref, 3.6.1 String Methods startswith() typo Initial Comment: Python Library Reference Section 3.6.1 "String Methods" = startswith(prefix[, start[, end]]) Return True if string starts with the prefix, otherwise return False. prefix can also be a tuple of __suffixes__ to look for. With optional start, test string beginning at that position. With optional end, stop comparing string at that position. = ...Believe "suffixes" should be corrected to "prefixes" (Likely a copy and paste oversight from the description for mirror method " endswith(suffix[, start[, end]])") Typo report of Jan. 2007 noted as closed, but error is still present. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-13 09:39 Message: Logged In: YES user_id=849994 Originator: NO It is fixed, but in the development docs. The 2.5 docs will get updated with 2.5.2. -- Comment By: Georg Brandl (gbrandl) Date: 2007-08-13 09:39 Message: Logged In: YES user_id=849994 Originator: NO It is fixed, but in the development docs. The 2.5 docs will get updated with 2.5.2. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772890&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772890 ] Py Lib Ref, 3.6.1 String Methods startswith() typo
Bugs item #1772890, was opened at 2007-08-13 07:10 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772890&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: 3rd Party >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: arxaaron (arxaaron) Assigned to: Nobody/Anonymous (nobody) Summary: Py Lib Ref, 3.6.1 String Methods startswith() typo Initial Comment: Python Library Reference Section 3.6.1 "String Methods" = startswith(prefix[, start[, end]]) Return True if string starts with the prefix, otherwise return False. prefix can also be a tuple of __suffixes__ to look for. With optional start, test string beginning at that position. With optional end, stop comparing string at that position. = ...Believe "suffixes" should be corrected to "prefixes" (Likely a copy and paste oversight from the description for mirror method " endswith(suffix[, start[, end]])") Typo report of Jan. 2007 noted as closed, but error is still present. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-08-13 09:39 Message: Logged In: YES user_id=849994 Originator: NO It is fixed, but in the development docs. The 2.5 docs will get updated with 2.5.2. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772890&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772916 ] xmlrpclib crash when PyXML installed
Bugs item #1772916, was opened at 2007-08-13 03:15 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib crash when PyXML installed Initial Comment: The xmlrpclib module in the standard library will use a 3rd party C extension called "sgmlop" if it is present. The last version of PyXML (0.8.4) includes this module, but it causes crashes with Python 2.5 due to the use of mismatched memory allocation/deallocation functions (PyObject_NEW and PyMem_DEL). It is unlikely that sgmlop will be fixed, as PyXML is no longer maintained. Therefore sgmlop support should be removed from xmlrpclib. (In case you're wondering why anyone would install PyXML with Python 2.5 anyway: there are still some 3rd party libraries which depend upon PyXML, such as ZSI and twisted). -- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-13 06:06 Message: Logged In: YES user_id=1115903 Originator: NO I'm assuming that stuff won't be removed from 2.5 because it's in maintenance, so should this be removed or changed to raise a deprecation warning in 2.6? As an aside, how about removing references to _xmlrpclib (which appears to have been removed long ago) as well? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1770416 ] Decimal.__int__ overflows for large values
Bugs item #1770416, was opened at 2007-08-08 17:43
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Jason G (aryx)
Assigned to: Facundo Batista (facundobatista)
Summary: Decimal.__int__ overflows for large values
Initial Comment:
This also affects Decimal.__hash__, since it [indirectly] calls Decimal.__int__.
>>> from decimal import Decimal as D
>>> e = D("1e1234567890987654321")
>>> int(e)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/decimal.py", line 1501, in __int__
s = ''.join(map(str, self._int)) + '0'*self._exp
OverflowError: cannot fit 'long' into an index-sized integer
>>> e = D("1e1234567890")
>>> int(e)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python2.5/decimal.py", line 1501, in __int__
s = ''.join(map(str, self._int)) + '0'*self._exp
MemoryError
Also, for values that do work this is incredibly slow if they are still fairly
large.
--
>Comment By: Facundo Batista (facundobatista)
Date: 2007-08-13 12:10
Message:
Logged In: YES
user_id=752496
Originator: NO
hash will NOT be changed as is requested in this bug:
>>> import decimal
>>> d = decimal.Decimal(1)
>>> hash(d)
1
>>> hash(1)
1
>>> hash(d.as_tuple())
-790594979
>>>
See this requirement from PEP 327:
hash(n) == hash(Decimal(n)) # Only if n is int, long, or Decimal
Regarding the overflow, this must to be fixed... I'll take a look to
marketdickinson patch...
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-08-13 01:50
Message:
Logged In: YES
user_id=703403
Originator: NO
See patch #1772851
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-08-12 16:43
Message:
Logged In: YES
user_id=703403
Originator: NO
Mark Dickinson (marketdickinson) stupidly claimed that:
hash(n) == hash(n % (2**32-1))
It's not true. Sorry for the noise.
--
Comment By: Mark Dickinson (marketdickinson)
Date: 2007-08-12 14:57
Message:
Logged In: YES
user_id=703403
Originator: NO
Doesn't using hash(D.as_tuple()) break the principle that if two objects
compare equal then they should have equal hash?
An alternative to converting to long before hashing is to use the fact
that for the current hash implementation for long we have
hash(n) == hash(n % (2**32-1)) (except when n is a multiple of 2**32-1).
For a Decimal d that's integral, one should be
able to compute d % (2**32-1) very quickly: if d = c*10**e then just use
(c * pow(10, e, 2**32-1)) % (2**32-1), which should be acceptably fast even
when d = 123456789E999.
The only tricky bit is that on a 64-bit system all those 2**32-1 need to
be replaced by 2**64-1. Though now I come to think of it,
since 2**32-1 is a factor of 2**64-1 it would be enough just to do
everything modulo 2**64-1 even on a 32-bit system.
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-08-09 14:37
Message:
Logged In: YES
user_id=849994
Originator: NO
Assigning to Facundo, he's actively working on decimal ATM.
--
Comment By: ajaksu (ajaksu2)
Date: 2007-08-09 14:21
Message:
Logged In: YES
user_id=1200609
Originator: NO
I see. Inheriting from Decimal and overloading __hash__ is a way to solve
your problem, but it's IMHO a shallow bug and worth reporting.
I just tried hash(D.as_tuple()) and it is blazing fast. I think that
unless the official line is "don't touch decimal.py until X", this change
to hashing would be useful and (AFAICT) harmless enough to fit in e.g.
2.5.2. To avoid incompatibilities, __hash__ could check for Overflow and
only use .as_tuple for values higher than the previous maximum (keeping,
unfortunately, __hash__ slow for values below).
Could the current status of Decimal be made a bit more clear? Are bug
reports/patches welcome? Is bugging Facundo or RHettinger welcome? :)
If getting __int__ a bit faster and able to convert sans huge strings is
desired, I've updated that old function (see below) and AFAIK it could be
used to replace Lib/decimal.py/Decimal.[__int__,__long__]. It gets about
ten times faster on best cases and is about as slow on worst cases (could
be much worse if "long(rint_part + rdec_part)/exponent" is a STUPID thing
to do, but seems easy to avoid). As the original
[ python-Bugs-1770009 ] decimal.Decimal("trash") produces informationless exception
Bugs item #1770009, was opened at 2007-08-08 09:44
Message generated for change (Comment added) made by facundobatista
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770009&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: John Machin (sjmachin)
Assigned to: Facundo Batista (facundobatista)
Summary: decimal.Decimal("trash") produces informationless exception
Initial Comment:
Python 2.5.1 (r251:54863, Apr 18 2007, 08:51:08) [MSC v.1310 32 bit (Intel)] on
win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import decimal
>>> decimal.Decimal("-$123,456.78")
Traceback (most recent call last):
File "", line 1, in
File "C:\python25\lib\decimal.py", line 614, in __new__
self._sign, self._int, self._exp = context._raise_error(ConversionSyntax)
File "C:\python25\lib\decimal.py", line 2325, in _raise_error
raise error, explanation
decimal.InvalidOperation
It should do something like float does ... better message, and show the
offending arg:
>>> float("-$123,456.78")
Traceback (most recent call last):
File "", line 1, in
ValueError: invalid literal for float(): -$123,456.78
>>>
--
>Comment By: Facundo Batista (facundobatista)
Date: 2007-08-13 12:17
Message:
Logged In: YES
user_id=752496
Originator: NO
Yes, I will.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-08-10 00:36
Message:
Logged In: YES
user_id=33168
Originator: NO
Facundo, could you take a look?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770009&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772916 ] xmlrpclib crash when PyXML installed
Bugs item #1772916, was opened at 2007-08-13 18:15 Message generated for change (Comment added) made by ldeller You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib crash when PyXML installed Initial Comment: The xmlrpclib module in the standard library will use a 3rd party C extension called "sgmlop" if it is present. The last version of PyXML (0.8.4) includes this module, but it causes crashes with Python 2.5 due to the use of mismatched memory allocation/deallocation functions (PyObject_NEW and PyMem_DEL). It is unlikely that sgmlop will be fixed, as PyXML is no longer maintained. Therefore sgmlop support should be removed from xmlrpclib. (In case you're wondering why anyone would install PyXML with Python 2.5 anyway: there are still some 3rd party libraries which depend upon PyXML, such as ZSI and twisted). -- >Comment By: lplatypus (ldeller) Date: 2007-08-14 11:07 Message: Logged In: YES user_id=1534394 Originator: YES Choice of XML parser is an implementation detail of xmlrpclib not visible to users of the module. This change would not affect the behaviour of xmlrpclib (other than to fix a crash introduced in Python 2.5). Does this mean that a DeprecationWarning would not be necessary? Does it also mean that the fix might qualify for the maintenance branch? Adding a DeprecationWarning in 2.6 without removing use of sgmlop is pointless, because the DeprecationWarning would be followed by a process crash anyway. -- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-13 21:06 Message: Logged In: YES user_id=1115903 Originator: NO I'm assuming that stuff won't be removed from 2.5 because it's in maintenance, so should this be removed or changed to raise a deprecation warning in 2.6? As an aside, how about removing references to _xmlrpclib (which appears to have been removed long ago) as well? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772916 ] xmlrpclib crash when PyXML installed
Bugs item #1772916, was opened at 2007-08-13 03:15 Message generated for change (Comment added) made by alanmcintyre You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: lplatypus (ldeller) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib crash when PyXML installed Initial Comment: The xmlrpclib module in the standard library will use a 3rd party C extension called "sgmlop" if it is present. The last version of PyXML (0.8.4) includes this module, but it causes crashes with Python 2.5 due to the use of mismatched memory allocation/deallocation functions (PyObject_NEW and PyMem_DEL). It is unlikely that sgmlop will be fixed, as PyXML is no longer maintained. Therefore sgmlop support should be removed from xmlrpclib. (In case you're wondering why anyone would install PyXML with Python 2.5 anyway: there are still some 3rd party libraries which depend upon PyXML, such as ZSI and twisted). -- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-13 22:32 Message: Logged In: YES user_id=1115903 Originator: NO I tried out xmlrpclib on the trunk (2.6) with sgmlop-1.1.1 and it works just fine. At the moment I don't have time to try out PyXML, but seeing that the most recent sgmlop works with xmlrpclib makes me lean towards not removing sgmlop support (not that I have a say about it, but still). How did you install PyXML? If it wasn't from source or from an installer compiled for 2.5, that might be a problem. If PyXML installed from source or compiled for 2.5 still causes this problem, it could be that it needs to be updated to the current sgmlop. -- Comment By: lplatypus (ldeller) Date: 2007-08-13 20:07 Message: Logged In: YES user_id=1534394 Originator: YES Choice of XML parser is an implementation detail of xmlrpclib not visible to users of the module. This change would not affect the behaviour of xmlrpclib (other than to fix a crash introduced in Python 2.5). Does this mean that a DeprecationWarning would not be necessary? Does it also mean that the fix might qualify for the maintenance branch? Adding a DeprecationWarning in 2.6 without removing use of sgmlop is pointless, because the DeprecationWarning would be followed by a process crash anyway. -- Comment By: Alan McIntyre (alanmcintyre) Date: 2007-08-13 06:06 Message: Logged In: YES user_id=1115903 Originator: NO I'm assuming that stuff won't be removed from 2.5 because it's in maintenance, so should this be removed or changed to raise a deprecation warning in 2.6? As an aside, how about removing references to _xmlrpclib (which appears to have been removed long ago) as well? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1772916 ] xmlrpclib crash when PyXML installed
Bugs item #1772916, was opened at 2007-08-13 18:15
Message generated for change (Comment added) made by ldeller
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: lplatypus (ldeller)
Assigned to: Nobody/Anonymous (nobody)
Summary: xmlrpclib crash when PyXML installed
Initial Comment:
The xmlrpclib module in the standard library will use a 3rd party C extension
called "sgmlop" if it is present.
The last version of PyXML (0.8.4) includes this module, but it causes crashes
with Python 2.5 due to the use of mismatched memory allocation/deallocation
functions (PyObject_NEW and PyMem_DEL).
It is unlikely that sgmlop will be fixed, as PyXML is no longer maintained.
Therefore sgmlop support should be removed from xmlrpclib.
(In case you're wondering why anyone would install PyXML with Python 2.5
anyway: there are still some 3rd party libraries which depend upon PyXML, such
as ZSI and twisted).
--
>Comment By: lplatypus (ldeller)
Date: 2007-08-14 16:23
Message:
Logged In: YES
user_id=1534394
Originator: YES
Yes the standalone sgmlop-1.1.1 looks fine: in its sgmlop.c I can see that
matching allocator and deallocator functions are used.
I installed PyXML-0.8.4 from source ("python setup.py install" on Win32
which picked up the C compiler from MSVS7.1). The cause of the problem is
quite visible in the PyXML source code (see that PyObject_NEW and PyMem_DEL
are used together):
http://pyxml.cvs.sourceforge.net/pyxml/xml/extensions/sgmlop.c?view=markup
Interestingly PyXML-0.8.4 was released more recently than sgmlop-1.1.1. I
guess they weren't keeping in sync with each other.
--
Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-08-14 13:32
Message:
Logged In: YES
user_id=1115903
Originator: NO
I tried out xmlrpclib on the trunk (2.6) with sgmlop-1.1.1 and it works
just fine. At the moment I don't have time to try out PyXML, but seeing
that the most recent sgmlop works with xmlrpclib makes me lean towards not
removing sgmlop support (not that I have a say about it, but still).
How did you install PyXML? If it wasn't from source or from an installer
compiled for 2.5, that might be a problem. If PyXML installed from source
or compiled for 2.5 still causes this problem, it could be that it needs to
be updated to the current sgmlop.
--
Comment By: lplatypus (ldeller)
Date: 2007-08-14 11:07
Message:
Logged In: YES
user_id=1534394
Originator: YES
Choice of XML parser is an implementation detail of xmlrpclib not visible
to users of the module. This change would not affect the behaviour of
xmlrpclib (other than to fix a crash introduced in Python 2.5). Does this
mean that a DeprecationWarning would not be necessary? Does it also mean
that the fix might qualify for the maintenance branch?
Adding a DeprecationWarning in 2.6 without removing use of sgmlop is
pointless, because the DeprecationWarning would be followed by a process
crash anyway.
--
Comment By: Alan McIntyre (alanmcintyre)
Date: 2007-08-13 21:06
Message:
Logged In: YES
user_id=1115903
Originator: NO
I'm assuming that stuff won't be removed from 2.5 because it's in
maintenance, so should this be removed or changed to raise a deprecation
warning in 2.6?
As an aside, how about removing references to _xmlrpclib (which appears to
have been removed long ago) as well?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1772916&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
