[issue1000] x

2007-08-08 Thread Georg Brandl

Changes by Georg Brandl:


--
severity: normal
status: open
title: x

__
Tracker <[EMAIL PROTECTED]>

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



[ python-Bugs-1770009 ] decimal.Decimal("trash") produces informationless exception

2007-08-08 Thread SourceForge.net
Bugs item #1770009, was opened at 2007-08-08 22:44
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=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: Nobody/Anonymous (nobody)
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
>>>

--

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-1730114 ] cStringIO no longer accepts array.array objects

2007-08-08 Thread SourceForge.net
Bugs item #1730114, was opened at 2007-06-03 01:01
Message generated for change (Comment added) made by gbrandl
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730114&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: Extension Modules
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: reedobrien (reedobrien)
Assigned to: Georg Brandl (gbrandl)
Summary: cStringIO no longer accepts array.array objects

Initial Comment:
It worked fine in 2.5 and 2.4.4

Python 2.5.1 (r251:54863, Jun  2 2007, 19:09:15) 
Type "copyright", "credits" or "license" for more information.

In [1]: from cStringIO import StringIO

In [2]: from array import array

In [3]: a = array('B', [0,1,2])

In [4]: StringIO(a)
---
 Traceback (most recent call last)

/Users/reedobrien/ in ()

: expected a character buffer object


Recompiling with the 2.5 cStringIO.c it works.

Python 2.5.1 (r251:54863, Jun  2 2007, 20:06:12) 
Type "copyright", "credits" or "license" for more information.

In [1]: from array import array

In [2]: from cStringIO import StringIO

In [3]: a = array('B', [0,1,2])

In [4]: StringIO(a)
Out[4]: 



I blame Visual Studio. 
I don't know enough c to fix it.

--

>Comment By: Georg Brandl (gbrandl)
Date: 2007-08-08 13:04

Message:
Logged In: YES 
user_id=849994
Originator: NO

Fixed by reverting the offending change. Added a note in the docs.
Committed revisions 56830, 56831 (2.5).

--

Comment By: Georg Brandl (gbrandl)
Date: 2007-06-06 18:12

Message:
Logged In: YES 
user_id=849994
Originator: NO

I'll look at it.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2007-06-03 06:40

Message:
Logged In: YES 
user_id=80475
Originator: NO

Georgbot, I believe this was your checkin.

--

Comment By: reedobrien (reedobrien)
Date: 2007-06-03 05:49

Message:
Logged In: YES 
user_id=995094
Originator: YES

It appears this is the change that broke it.
http://svn.python.org/view/python/branches/release25-maint/Modules/cStringIO.c?rev=52302&r1=51333&r2=52302

This is the log entry from that changeset:
Bug #1548891: The cStringIO.StringIO() constructor now encodes unicode
arguments with the system default encoding just like the write()
method does, instead of converting it to a raw buffer.
 (backport from rev. 52301)


Perhaps the cPickle module should be used instead...

BUT at first glance the following seems to make both work:
  if (PyUnicode_Check(s)) 
{
if (PyObject_AsCharBuffer(s, (const char **)&buf, &size) != 0)
{
PyErr_Format(PyExc_TypeError, "expected character 
buffer, %.200s
found",
s->ob_type->tp_name); 
return NULL;
}
}
  else
{
if (PyObject_AsReadBuffer(s, (const void **)&buf, &size) != 0)
return NULL;
}

But the more I think about it the more I think cPickle is more appropriate
for this purpose.  In that case I should make a blurb for the docs about
not storing arbitrary data in cStringIO. 

Either way I am attaching the cStringIO.c file that worked for me...
File Added: cStringIO.c

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1730114&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1770190 ] platform.mac_ver() returning incorrect patch version

2007-08-08 Thread SourceForge.net
Bugs item #1770190, was opened at 2007-08-08 13:08
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=1770190&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: Macintosh
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Gus Tabares (gtabares)
Assigned to: Jack Jansen (jackjansen)
Summary: platform.mac_ver() returning incorrect patch version

Initial Comment:
Running on an Intel Mac OSX 10.4.10 machine:

>>> platform.mac_ver()
('10.4.9', ('', '', ''), 'i386')


I have reproduced this on 4 other (Intel Mac) machines. I don't have access to 
a 10.4.10 PPC machine.





--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770190&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

2007-08-08 Thread SourceForge.net
Bugs item #1770416, was opened at 2007-08-08 18:13
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=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: Nobody/Anonymous (nobody)
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.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770416&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1770190 ] platform.mac_ver() returning incorrect patch version

2007-08-08 Thread SourceForge.net
Bugs item #1770190, was opened at 2007-08-08 20:08
Message generated for change (Comment added) made by jackjansen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770190&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: Macintosh
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Gustavo Tabares (gtabares)
Assigned to: Jack Jansen (jackjansen)
Summary: platform.mac_ver() returning incorrect patch version

Initial Comment:
Running on an Intel Mac OSX 10.4.10 machine:

>>> platform.mac_ver()
('10.4.9', ('', '', ''), 'i386')


I have reproduced this on 4 other (Intel Mac) machines. I don't have access to 
a 10.4.10 PPC machine.





--

>Comment By: Jack Jansen (jackjansen)
Date: 2007-08-09 00:05

Message:
Logged In: YES 
user_id=45365
Originator: NO

Interesting problem! Mac_ver() basically uses gestalt() with a selector of
'sysv' and this will return '9' for the micro-version if it is 9 or
greater.
It could be fixed, according to
 by using three
calls to gestalt() with selectors 'sys1', 'sys2' and 'sys3', which will
return the three numbers correctly.

I'm not sure whether these selectors are always available, will
investigate.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770190&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1770551 ] words able to decode but unable to encode in GB18030

2007-08-08 Thread SourceForge.net
Bugs item #1770551, was opened at 2007-08-09 01:34
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=1770551&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: Unicode
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Z-flagship (zaex)
Assigned to: M.-A. Lemburg (lemburg)
Summary: words able to decode but unable to encode in GB18030

Initial Comment:
Here is a list of chinese characters that can be read from a file [in GB18030 
encoding], but unable to encode to GB18030 encoding

detailed:
used codecs.open(r'file name', encoding='GB18030') to read the characters from 
a file, and try to encode them word by word into GB18030 with 
word.encode('GB18030'). The action caused an exception with 'illegal multibyte 
sequence'

the attachment is also the list.

list:
䎬䎱䅟䌷䦟䦷䲠㧏㭎㘚㘎㱮䴔䴖䴗䦆㧟䙡䙌䴕䁖䎬䴙䥽䝼䞍䓖䲡䥇䦂䦅䴓㩳㧐㳠䲢䴘㖞䜣䥺䶮䜩䥺䲟䲣䦛䦶㑳㑇㥮㤘䏝䦃

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770551&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[ python-Bugs-1770551 ] words able to decode but unable to encode in GB18030

2007-08-08 Thread SourceForge.net
Bugs item #1770551, was opened at 2007-08-09 01:34
Message generated for change (Comment added) made by zaex
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770551&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: Unicode
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Z-flagship (zaex)
Assigned to: M.-A. Lemburg (lemburg)
Summary: words able to decode but unable to encode in GB18030

Initial Comment:
Here is a list of chinese characters that can be read from a file [in GB18030 
encoding], but unable to encode to GB18030 encoding

detailed:
used codecs.open(r'file name', encoding='GB18030') to read the characters from 
a file, and try to encode them word by word into GB18030 with 
word.encode('GB18030'). The action caused an exception with 'illegal multibyte 
sequence'

the attachment is also the list.

list:
䎬䎱䅟䌷䦟䦷䲠㧏㭎㘚㘎㱮䴔䴖䴗䦆㧟䙡䙌䴕䁖䎬䴙䥽䝼䞍䓖䲡䥇䦂䦅䴓㩳㧐㳠䲢䴘㖞䜣䥺䶮䜩䥺䲟䲣䦛䦶㑳㑇㥮㤘䏝䦃

--

>Comment By: Z-flagship (zaex)
Date: 2007-08-09 01:37

Message:
Logged In: YES 
user_id=1863611
Originator: YES

The Python is Python2.5 , my OS is windows XP professional sp2 version
2002

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1770551&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue1720897] fix 1668596: copy datafiles properly when package_dir is ' '

2007-08-08 Thread Martin v. Löwis

Martin v. Löwis added the comment:

URL test (http://www.python.org/sf/1668596)

--
nosy: +loewis

_
Tracker <[EMAIL PROTECTED]>

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