[ python-Bugs-620739 ] missing mappings in locale tables

[SourceForge.net]

Bugs item #620739, was opened at 2002-10-09 14:39
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Fredrik Lundh (effbot)
Assigned to: Fredrik Lundh (effbot)
Summary: missing mappings in locale tables

Initial Comment:
(via mail from Oleg Deribas)

Here are two missed mappings in locale.py for russian 
and ukrainian languages:

0x0422: "uk_UA", # Ukrainian (Ukraine)
0x0419: "ru_RU", # Russian (Russia)

locale_alias table also misses mapping for ukrainian:

'uk':'uk_UA.CP1251',
'uk_uk': 'uk_UA.CP1251',

Is it possible to include this in sources?


--

>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-02-15 10:31

Message:
Logged In: YES 
user_id=38388

We already have locale_alias table mappings for the Ukraine,
albeit different ones.

I'll look into updating the windows_locale table to include
all the identifiers from
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/nls_238z.asp,
the official source for these ids.

--

Comment By: Martin v. Löwis (loewis)
Date: 2005-02-15 00:19

Message:
Logged In: YES 
user_id=21627

I think that would be appropriate.

--

Comment By: Fredrik Lundh (effbot)
Date: 2005-02-14 23:17

Message:
Logged In: YES 
user_id=38376

(should I mark this as "won't fix" and close it?)

--

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-20 21:25

Message:
Logged In: YES 
user_id=21627

The problem with the OEMCP is more complex, given the chcp
utility (i.e. that the console code page may vary from
console to console), see patch 612627. So I don't think we
should keep a database of OEM code pages.

--

Comment By: Oleg Deribas (older)
Date: 2002-10-20 21:02

Message:
Logged In: YES 
user_id=281684

There is also problem with default charset on windows. It
have different charsets for GUI and textmode (OEM and ANSI).
So for Ukrainian it is 1251 and 866 codepages accordingly.
And windows uses non-POSIX locale names like ukr_ukr.1251
instead of uk_UA.CP1251

--

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-09 19:38

Message:
Logged In: YES 
user_id=21627

I withdraw my question on windows_locale.

As for uk_uk, it appears to be completely bogus. The country
code for the Ukraine is UA, not UK (this is semi-officially,
i.e. IANA-assigned, the United Kingdom).

As for associating CP1251 with them: I don't care; I find
the whole notion of "getdefaultlocale" broken. People can
also arrange their systems to use uk_UA with UTF-8 if they
want to, or iso-8859-5 (although the latter is reportedly
insufficient for Ukrainian).

Fredrik, feel free to add whatever you think appropriate.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-10-09 17:54

Message:
Logged In: YES 
user_id=80475

In some non-python projects (found through a google 
search), uk_uk is an encoding alias for KOI8-U.


--

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-09 14:55

Message:
Logged In: YES 
user_id=21627

I'm sure many more are missing also, Microsoft has currently
143 language identifiers.

Assuming this goes into windows_locale, why does it have a a
codeset in it?

--

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

[ python-Bugs-620739 ] missing mappings in locale tables

[SourceForge.net]

Bugs item #620739, was opened at 2002-10-09 14:39
Message generated for change (Settings changed) made by effbot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=620739&group_id=5470

Category: Python Library
Group: None
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Fredrik Lundh (effbot)
>Assigned to: M.-A. Lemburg (lemburg)
Summary: missing mappings in locale tables

Initial Comment:
(via mail from Oleg Deribas)

Here are two missed mappings in locale.py for russian 
and ukrainian languages:

0x0422: "uk_UA", # Ukrainian (Ukraine)
0x0419: "ru_RU", # Russian (Russia)

locale_alias table also misses mapping for ukrainian:

'uk':'uk_UA.CP1251',
'uk_uk': 'uk_UA.CP1251',

Is it possible to include this in sources?


--

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-02-15 10:31

Message:
Logged In: YES 
user_id=38388

We already have locale_alias table mappings for the Ukraine,
albeit different ones.

I'll look into updating the windows_locale table to include
all the identifiers from
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/intl/nls_238z.asp,
the official source for these ids.

--

Comment By: Martin v. Löwis (loewis)
Date: 2005-02-15 00:19

Message:
Logged In: YES 
user_id=21627

I think that would be appropriate.

--

Comment By: Fredrik Lundh (effbot)
Date: 2005-02-14 23:17

Message:
Logged In: YES 
user_id=38376

(should I mark this as "won't fix" and close it?)

--

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-20 21:25

Message:
Logged In: YES 
user_id=21627

The problem with the OEMCP is more complex, given the chcp
utility (i.e. that the console code page may vary from
console to console), see patch 612627. So I don't think we
should keep a database of OEM code pages.

--

Comment By: Oleg Deribas (older)
Date: 2002-10-20 21:02

Message:
Logged In: YES 
user_id=281684

There is also problem with default charset on windows. It
have different charsets for GUI and textmode (OEM and ANSI).
So for Ukrainian it is 1251 and 866 codepages accordingly.
And windows uses non-POSIX locale names like ukr_ukr.1251
instead of uk_UA.CP1251

--

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-09 19:38

Message:
Logged In: YES 
user_id=21627

I withdraw my question on windows_locale.

As for uk_uk, it appears to be completely bogus. The country
code for the Ukraine is UA, not UK (this is semi-officially,
i.e. IANA-assigned, the United Kingdom).

As for associating CP1251 with them: I don't care; I find
the whole notion of "getdefaultlocale" broken. People can
also arrange their systems to use uk_UA with UTF-8 if they
want to, or iso-8859-5 (although the latter is reportedly
insufficient for Ukrainian).

Fredrik, feel free to add whatever you think appropriate.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2002-10-09 17:54

Message:
Logged In: YES 
user_id=80475

In some non-python projects (found through a google 
search), uk_uk is an encoding alias for KOI8-U.


--

Comment By: Martin v. Löwis (loewis)
Date: 2002-10-09 14:55

Message:
Logged In: YES 
user_id=21627

I'm sure many more are missing also, Microsoft has currently
143 language identifiers.

Assuming this goes into windows_locale, why does it have a a
codeset in it?

--

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

[ python-Bugs-1122916 ] incorrect handle of declaration in markupbase

[SourceForge.net]

Bugs item #1122916, was opened at 2005-02-14 23:04
Message generated for change (Comment added) made by tungwaiyip
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1122916&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Wai Yip Tung (tungwaiyip)
Assigned to: Nobody/Anonymous (nobody)
Summary: incorrect handle of declaration in markupbase 

Initial Comment:
When parsing the document below using sgmllib:


hello


The incorrect declaration is returned with hello as one 
single character data:

  "hello"

markupbase should have treated it as an error (to be 
consistent with it strict treatment in _scan_name).

I believe the line 73 of markupbase.py should be

if rawdata[j:j+2] in ("-", ""):

intead of 

if rawdata[j:j+1] in ("-", ""):

Also note that the condition in line 79 will not be true

if rawdata[j:j+1] == '--'


--

>Comment By: Wai Yip Tung (tungwaiyip)
Date: 2005-02-15 09:09

Message:
Logged In: YES 
user_id=561546

To clarify the syndrome, actually everything after the hello\r\n"

This means all the tags like  are not parsed as tags but 
as character data as soon as there is a https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1122916&group_id=5470
___
Python-bugs-list mailing list 
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[ python-Bugs-1123268 ] Typo in Curses-Function doc

[SourceForge.net]

Bugs item #1123268, was opened at 2005-02-15 11:12
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=1123268&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Aaron C. Spike (acspike)
Assigned to: Nobody/Anonymous (nobody)
Summary: Typo in Curses-Function doc

Initial Comment:
The description of the filter() method on
 says
"This may be used for enabling cgaracter-at-a-time line
editing without touching the rest of the screen."

cgaracter should likely be character



--

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

[ python-Feature Requests-1122279 ] Option to force variables to be declared

[SourceForge.net]

Feature Requests item #1122279, was opened at 2005-02-14 05:40
Message generated for change (Comment added) made by jimjjewett
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122279&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Zac Evans (karadoc)
Assigned to: Nobody/Anonymous (nobody)
Summary: Option to force variables to be declared

Initial Comment:
My most common python programming error is to spell a
variable different ways in different parts of a
program. Often this generates no warnings, and is a
difficult problem to track down.

The Zen of Python says that 'Explicit is better than
Implicit'. I would like it if I could set an option so
that I had to explicitly declare variables before I can
use them. eg.
x = 5
would generate a warning, but
x = int()
x = 5
would not.

I do believe that explicit is better than implicit with
respect to programming; and I know that this feature
would save me a _lot_ of debugging on my larger python
projects.

--

Comment By: Jim Jewett (jimjjewett)
Date: 2005-02-15 12:57

Message:
Logged In: YES 
user_id=764593

For various reasons, this won't soon get into the core.

Meanwhile, there are some tools like pychecker which may 
help.

I've also found that declaring __slots__ makes the errors 
surface a little bit faster, when I'm dealing with attributes.  
(The most common reason for me to need the variable 
name in widely separated places.)

--

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

[ python-Feature Requests-1122279 ] Option to force variables to be declared

[SourceForge.net]

Feature Requests item #1122279, was opened at 2005-02-14 02:40
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1122279&group_id=5470

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Zac Evans (karadoc)
Assigned to: Nobody/Anonymous (nobody)
Summary: Option to force variables to be declared

Initial Comment:
My most common python programming error is to spell a
variable different ways in different parts of a
program. Often this generates no warnings, and is a
difficult problem to track down.

The Zen of Python says that 'Explicit is better than
Implicit'. I would like it if I could set an option so
that I had to explicitly declare variables before I can
use them. eg.
x = 5
would generate a warning, but
x = int()
x = 5
would not.

I do believe that explicit is better than implicit with
respect to programming; and I know that this feature
would save me a _lot_ of debugging on my larger python
projects.

--

>Comment By: Brett Cannon (bcannon)
Date: 2005-02-15 11:29

Message:
Logged In: YES 
user_id=357491

This will never get in as proposed for technical reasons.  What is the 
difference between ``x=5`` and ``x=int()``?  To the compiler they are 
just assignments to a variable, one just happens to involve a function 
call.  The only way to get the feature you want is to somehow have a 
more specific way of declaring variables, like a 'var' keyword or 
something and that will probably never go.

As Jim suggested, PyChecker is great for this kind of thing.  There are 
things in the works to help lead to PyChecker being added to the 
standard library so your problem should get a partial solution included in 
Python some time in the future.

--

Comment By: Jim Jewett (jimjjewett)
Date: 2005-02-15 09:57

Message:
Logged In: YES 
user_id=764593

For various reasons, this won't soon get into the core.

Meanwhile, there are some tools like pychecker which may 
help.

I've also found that declaring __slots__ makes the errors 
surface a little bit faster, when I'm dealing with attributes.  
(The most common reason for me to need the variable 
name in widely separated places.)

--

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

[ python-Bugs-1123354 ] test_peepholer failing on HEAD

[SourceForge.net]

Bugs item #1123354, was opened at 2005-02-15 14:49
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=1123354&group_id=5470

Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Raymond Hettinger (rhettinger)
Summary: test_peepholer failing on HEAD

Initial Comment:
On WinXP with current CVS HEAD:

FAIL: test_folding_of_binops_on_constants 
(__main__.TestTranforms)
--

Traceback (most recent call last):
  File "../lib/test/test_peepholer.py", line 134, in 
test_folding_of_binops_on_constants
self.assert_('(1000)' in asm)
AssertionError

and asm contains the big string 'x'*1000 instead.

--

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

[ python-Bugs-1123354 ] test_peepholer failing on HEAD

[SourceForge.net]

Bugs item #1123354, was opened at 2005-02-15 14:49
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123354&group_id=5470

Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Raymond Hettinger (rhettinger)
Summary: test_peepholer failing on HEAD

Initial Comment:
On WinXP with current CVS HEAD:

FAIL: test_folding_of_binops_on_constants 
(__main__.TestTranforms)
--

Traceback (most recent call last):
  File "../lib/test/test_peepholer.py", line 134, in 
test_folding_of_binops_on_constants
self.assert_('(1000)' in asm)
AssertionError

and asm contains the big string 'x'*1000 instead.

--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-02-15 17:49

Message:
Logged In: YES 
user_id=80475

Can you confirm that it works after deleting the pyc file? 
If so, I'll bump the magic number.

--

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

[ python-Bugs-1123354 ] test_peepholer failing on HEAD

[SourceForge.net]

Bugs item #1123354, was opened at 2005-02-15 14:49
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123354&group_id=5470

Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Raymond Hettinger (rhettinger)
Summary: test_peepholer failing on HEAD

Initial Comment:
On WinXP with current CVS HEAD:

FAIL: test_folding_of_binops_on_constants 
(__main__.TestTranforms)
--

Traceback (most recent call last):
  File "../lib/test/test_peepholer.py", line 134, in 
test_folding_of_binops_on_constants
self.assert_('(1000)' in asm)
AssertionError

and asm contains the big string 'x'*1000 instead.

--

>Comment By: Tim Peters (tim_one)
Date: 2005-02-15 18:03

Message:
Logged In: YES 
user_id=31435

Well, I'm using rt.bat from PCbuild to run the tests.  That 
deletes all the .pyc and .pyo files reachable from Lib before 
running the tests.  So, no, deleting .pyc doesn't matter here.

...\PCbuild>python rmpyc.py
81 .pyc deleted, 0 .pyo deleted

...\PCbuild>dir/s/b ..\Lib\*.pyc ..\Lib\*.pyo
File Not Found

...\PCbuild>rt test_peepholer
Deleting .pyc/.pyo files ...
14 .pyc deleted, 0 .pyo deleted

...\PCbuild>python  -E -tt ../lib/test/regrtest.py 
test_peepholer
test_peepholer
test test_peepholer failed -- Traceback (most recent call 
last):
  File "C:\Code\python\lib\test\test_peepholer.py", line 134, 
in test_folding_of_binops_on_constants
self.assert_('(1000)' in asm)
AssertionError

1 test failed:
test_peepholer
About to run again without deleting .pyc/.pyo first:
Press any key to continue . . .
Terminate batch job (Y/N)? y

Is it possible, e.g., that you have an unchecked-in change on 
your development machine?

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-02-15 17:49

Message:
Logged In: YES 
user_id=80475

Can you confirm that it works after deleting the pyc file? 
If so, I'll bump the magic number.

--

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

[ python-Bugs-1123354 ] test_peepholer failing on HEAD

[SourceForge.net]

Bugs item #1123354, was opened at 2005-02-15 14:49
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123354&group_id=5470

Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Raymond Hettinger (rhettinger)
Summary: test_peepholer failing on HEAD

Initial Comment:
On WinXP with current CVS HEAD:

FAIL: test_folding_of_binops_on_constants 
(__main__.TestTranforms)
--

Traceback (most recent call last):
  File "../lib/test/test_peepholer.py", line 134, in 
test_folding_of_binops_on_constants
self.assert_('(1000)' in asm)
AssertionError

and asm contains the big string 'x'*1000 instead.

--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-02-15 18:48

Message:
Logged In: YES 
user_id=80475

Hmm, I don't see how we could get different results.  After
a fresh cvs up and recompilation, I get:

C:\py25>cvs st Python/compile.c
===
File: compile.c Status: Up-to-date

   Working revision:2.344
   Repository revision: 2.344  
/cvsroot/python/python/dist/src/Python/compile.
,v
   Sticky Tag:  (none)
   Sticky Date: (none)
   Sticky Options:  (none)


C:\py25>cvs st Lib/test/test_peepholer.py
===
File: test_peepholer.py Status: Up-to-date

   Working revision:1.11
   Repository revision: 1.11   
/cvsroot/python/python/dist/src/Lib/test/test_pe
epholer.py,v
   Sticky Tag:  (none)
   Sticky Date: (none)
   Sticky Options:  (none)


C:\py25\Lib\test>python -tt test_peepholer.py
test_elim_extra_return (__main__.TestTranforms) ... ok
test_elim_inversion_of_is_or_in (__main__.TestTranforms) ... ok
test_folding_of_binops_on_constants (__main__.TestTranforms)
... ok
test_folding_of_tuples_of_constants (__main__.TestTranforms)
... ok
test_none_as_constant (__main__.TestTranforms) ... ok
test_pack_unpack (__main__.TestTranforms) ... ok
test_unot (__main__.TestTranforms) ... ok
test_while_one (__main__.TestTranforms) ... ok

--
Ran 8 tests in 0.170s

OK


C:\py25>python
Python 2.5a0 (#46, Feb 15 2005, 18:32:36) [MSC v.1200 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> from dis import dis
>>> dis(compile('a="x"*1000', '', 'single'))
  1   0 LOAD_CONST   0 ('x')
  3 LOAD_CONST   1 (1000)
  6 BINARY_MULTIPLY
  7 STORE_NAME   0 (a)
 10 LOAD_CONST   2 (None)
 13 RETURN_VALUE


--

Comment By: Tim Peters (tim_one)
Date: 2005-02-15 18:03

Message:
Logged In: YES 
user_id=31435

Well, I'm using rt.bat from PCbuild to run the tests.  That 
deletes all the .pyc and .pyo files reachable from Lib before 
running the tests.  So, no, deleting .pyc doesn't matter here.

...\PCbuild>python rmpyc.py
81 .pyc deleted, 0 .pyo deleted

...\PCbuild>dir/s/b ..\Lib\*.pyc ..\Lib\*.pyo
File Not Found

...\PCbuild>rt test_peepholer
Deleting .pyc/.pyo files ...
14 .pyc deleted, 0 .pyo deleted

...\PCbuild>python  -E -tt ../lib/test/regrtest.py 
test_peepholer
test_peepholer
test test_peepholer failed -- Traceback (most recent call 
last):
  File "C:\Code\python\lib\test\test_peepholer.py", line 134, 
in test_folding_of_binops_on_constants
self.assert_('(1000)' in asm)
AssertionError

1 test failed:
test_peepholer
About to run again without deleting .pyc/.pyo first:
Press any key to continue . . .
Terminate batch job (Y/N)? y

Is it possible, e.g., that you have an unchecked-in change on 
your development machine?

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-02-15 17:49

Message:
Logged In: YES 
user_id=80475

Can you confirm that it works after deleting the pyc file? 
If so, I'll bump the magic number.

--

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

[ python-Bugs-1121475 ] Decorated functions are unpickleable

[SourceForge.net]

Bugs item #1121475, was opened at 2005-02-12 11:48
Message generated for change (Comment added) made by bcannon
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121475&group_id=5470

Category: Python Library
Group: Python 2.4
>Status: Closed
>Resolution: Wont Fix
Priority: 5
Submitted By: S Joshua Swamidass (sswamida)
Assigned to: Nobody/Anonymous (nobody)
Summary: Decorated functions are unpickleable

Initial Comment:
The decorator feature renders functions impossible to 
pickle if you end up wrapping the function in either a 
trivial lambda or a callable class. This is a 
significant/artificial limitation of the decorator which 
should not exist and prevents decorators from being 
used for many of my purposes. 

==
Examples:
==

>>> def dec(f):
... return lambda a: f(a)
...
>>> @dec
... def func(a):
... return a
...
>>> import pickle
>>> pickle.dumps(func)
Traceback (most recent call last):
...
pickle.PicklingError: Can't pickle  at 
0x40160ae4>: it's not found as __main__.



>>> class C:
... def __init__(self, f):
... self.f=f
... def __call__(self, a):
... return f(a)
...
>>> def dec(f):
... return C(f)
>>> @dec
>>> def func(a):
...return a
>>> import pickle
>>> pickle.dumps(func)
Traceback (most recent call last):
   .
pickle.PicklingError: Can't pickle : it's not the same object as __main__.func


==
I've found a syntacically ugly ways of working around 
the class wrapper bug that don't use decorators. 
Perhaps this could be used to create a decorator patch:
==

>>> class C:
... def __init__(self, f):
... self.f=f
... def __call__(self, a):
... return f(a)
...
>>> def _func(a):
...return a
>>> func=C(_func)
>>>
>>> import pickle
>>> pickle.dumps(func)
(No error)


--

>Comment By: Brett Cannon (bcannon)
Date: 2005-02-15 17:21

Message:
Logged In: YES 
user_id=357491

If you read the pickle docs it says you can only pickle "functions defined 
at the top level of a module".  The lambdas are you having your 
decorator return are not defined at the module level and thus do not 
meet that requirement.

The same basic issue goes with your callable class.  The function you are 
storing in self.f is not the same as was is defined at the module level 
since self.f is 'func' prior to wrapping while what 'func' has at the global 
level is an instance of 'C'.

The reason your example works is because '_func` is defined at the 
module level and thus pickle can find it to pickle.  Decorators skip the 
intermediate step of storing the undecorated function at the module 
level.

It would be better to use the pickling protocol to define methods to allow 
your callable class to help with the pickling process.

And just so you know, your class examples should be calling self.f 
instead of f.

Closing as "won't fix".

--

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

[ python-Bugs-1121475 ] Decorated functions are unpickleable

[SourceForge.net]

Bugs item #1121475, was opened at 2005-02-12 11:48
Message generated for change (Comment added) made by sswamida
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1121475&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Closed
>Resolution: None
Priority: 5
Submitted By: S Joshua Swamidass (sswamida)
Assigned to: Nobody/Anonymous (nobody)
Summary: Decorated functions are unpickleable

Initial Comment:
The decorator feature renders functions impossible to 
pickle if you end up wrapping the function in either a 
trivial lambda or a callable class. This is a 
significant/artificial limitation of the decorator which 
should not exist and prevents decorators from being 
used for many of my purposes. 

==
Examples:
==

>>> def dec(f):
... return lambda a: f(a)
...
>>> @dec
... def func(a):
... return a
...
>>> import pickle
>>> pickle.dumps(func)
Traceback (most recent call last):
...
pickle.PicklingError: Can't pickle  at 
0x40160ae4>: it's not found as __main__.



>>> class C:
... def __init__(self, f):
... self.f=f
... def __call__(self, a):
... return f(a)
...
>>> def dec(f):
... return C(f)
>>> @dec
>>> def func(a):
...return a
>>> import pickle
>>> pickle.dumps(func)
Traceback (most recent call last):
   .
pickle.PicklingError: Can't pickle : it's not the same object as __main__.func


==
I've found a syntacically ugly ways of working around 
the class wrapper bug that don't use decorators. 
Perhaps this could be used to create a decorator patch:
==

>>> class C:
... def __init__(self, f):
... self.f=f
... def __call__(self, a):
... return f(a)
...
>>> def _func(a):
...return a
>>> func=C(_func)
>>>
>>> import pickle
>>> pickle.dumps(func)
(No error)


--

>Comment By: S Joshua Swamidass (sswamida)
Date: 2005-02-15 17:45

Message:
Logged In: YES 
user_id=786138

Yes, everything you said is correct, though i think this is not 
ideal behavior. If we decorate a function at the top level of a 
module, shouldn't it be pickleable? If not, then as my original 
point was, decorated functions are not compatible with pickle.

Is there any case you can give me where a decorated 
function is defined in the top level of a module and can be 
pickled? I can't think of one, but i could be wrong.



--

Comment By: Brett Cannon (bcannon)
Date: 2005-02-15 17:21

Message:
Logged In: YES 
user_id=357491

If you read the pickle docs it says you can only pickle "functions defined 
at the top level of a module".  The lambdas are you having your 
decorator return are not defined at the module level and thus do not 
meet that requirement.

The same basic issue goes with your callable class.  The function you are 
storing in self.f is not the same as was is defined at the module level 
since self.f is 'func' prior to wrapping while what 'func' has at the global 
level is an instance of 'C'.

The reason your example works is because '_func` is defined at the 
module level and thus pickle can find it to pickle.  Decorators skip the 
intermediate step of storing the undecorated function at the module 
level.

It would be better to use the pickling protocol to define methods to allow 
your callable class to help with the pickling process.

And just so you know, your class examples should be calling self.f 
instead of f.

Closing as "won't fix".

--

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

[ python-Bugs-1123354 ] test_peepholer failing on HEAD

[SourceForge.net]

Bugs item #1123354, was opened at 2005-02-15 14:49
Message generated for change (Comment added) made by tim_one
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123354&group_id=5470

Category: Python Interpreter Core
>Group: Not a Bug
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Raymond Hettinger (rhettinger)
Summary: test_peepholer failing on HEAD

Initial Comment:
On WinXP with current CVS HEAD:

FAIL: test_folding_of_binops_on_constants 
(__main__.TestTranforms)
--

Traceback (most recent call last):
  File "../lib/test/test_peepholer.py", line 134, in 
test_folding_of_binops_on_constants
self.assert_('(1000)' in asm)
AssertionError

and asm contains the big string 'x'*1000 instead.

--

>Comment By: Tim Peters (tim_one)
Date: 2005-02-15 20:56

Message:
Logged In: YES 
user_id=31435

Peculiar!  I have the same CVS status output, and recompiled 
Python from scratch earlier just to be sure.

Oh, dang, I'm sorry.  Turns out my Visual Studio run was still 
pointing at the 24-maint branch checkout -- I wasn't 
recompiling the HEAD at all.  Works fine!  False alarm.  Sorry, 
Raymond!

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-02-15 18:48

Message:
Logged In: YES 
user_id=80475

Hmm, I don't see how we could get different results.  After
a fresh cvs up and recompilation, I get:

C:\py25>cvs st Python/compile.c
===
File: compile.c Status: Up-to-date

   Working revision:2.344
   Repository revision: 2.344  
/cvsroot/python/python/dist/src/Python/compile.
,v
   Sticky Tag:  (none)
   Sticky Date: (none)
   Sticky Options:  (none)


C:\py25>cvs st Lib/test/test_peepholer.py
===
File: test_peepholer.py Status: Up-to-date

   Working revision:1.11
   Repository revision: 1.11   
/cvsroot/python/python/dist/src/Lib/test/test_pe
epholer.py,v
   Sticky Tag:  (none)
   Sticky Date: (none)
   Sticky Options:  (none)


C:\py25\Lib\test>python -tt test_peepholer.py
test_elim_extra_return (__main__.TestTranforms) ... ok
test_elim_inversion_of_is_or_in (__main__.TestTranforms) ... ok
test_folding_of_binops_on_constants (__main__.TestTranforms)
... ok
test_folding_of_tuples_of_constants (__main__.TestTranforms)
... ok
test_none_as_constant (__main__.TestTranforms) ... ok
test_pack_unpack (__main__.TestTranforms) ... ok
test_unot (__main__.TestTranforms) ... ok
test_while_one (__main__.TestTranforms) ... ok

--
Ran 8 tests in 0.170s

OK


C:\py25>python
Python 2.5a0 (#46, Feb 15 2005, 18:32:36) [MSC v.1200 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> from dis import dis
>>> dis(compile('a="x"*1000', '', 'single'))
  1   0 LOAD_CONST   0 ('x')
  3 LOAD_CONST   1 (1000)
  6 BINARY_MULTIPLY
  7 STORE_NAME   0 (a)
 10 LOAD_CONST   2 (None)
 13 RETURN_VALUE


--

Comment By: Tim Peters (tim_one)
Date: 2005-02-15 18:03

Message:
Logged In: YES 
user_id=31435

Well, I'm using rt.bat from PCbuild to run the tests.  That 
deletes all the .pyc and .pyo files reachable from Lib before 
running the tests.  So, no, deleting .pyc doesn't matter here.

...\PCbuild>python rmpyc.py
81 .pyc deleted, 0 .pyo deleted

...\PCbuild>dir/s/b ..\Lib\*.pyc ..\Lib\*.pyo
File Not Found

...\PCbuild>rt test_peepholer
Deleting .pyc/.pyo files ...
14 .pyc deleted, 0 .pyo deleted

...\PCbuild>python  -E -tt ../lib/test/regrtest.py 
test_peepholer
test_peepholer
test test_peepholer failed -- Traceback (most recent call 
last):
  File "C:\Code\python\lib\test\test_peepholer.py", line 134, 
in test_folding_of_binops_on_constants
self.assert_('(1000)' in asm)
AssertionError

1 test failed:
test_peepholer
About to run again without deleting .pyc/.pyo first:
Press any key to continue . . .
Terminate batch job (Y/N)? y

Is it possible, e.g., that you have an unchecked-in change on 
your development machine?

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-02-15 17:49

Message:
Logged In: YES 
user_id=80475

Can you confirm that it works after deleting the pyc file? 
If so, I'll bump the magic number.

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123354&group_id=5470
___

[ python-Bugs-1123354 ] test_peepholer failing on HEAD

[SourceForge.net]

Bugs item #1123354, was opened at 2005-02-15 14:49
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1123354&group_id=5470

Category: Python Interpreter Core
Group: Not a Bug
Status: Closed
Resolution: Invalid
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Raymond Hettinger (rhettinger)
Summary: test_peepholer failing on HEAD

Initial Comment:
On WinXP with current CVS HEAD:

FAIL: test_folding_of_binops_on_constants 
(__main__.TestTranforms)
--

Traceback (most recent call last):
  File "../lib/test/test_peepholer.py", line 134, in 
test_folding_of_binops_on_constants
self.assert_('(1000)' in asm)
AssertionError

and asm contains the big string 'x'*1000 instead.

--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-02-15 21:58

Message:
Logged In: YES 
user_id=80475

C'est le vie.  :-)

--

Comment By: Tim Peters (tim_one)
Date: 2005-02-15 20:56

Message:
Logged In: YES 
user_id=31435

Peculiar!  I have the same CVS status output, and recompiled 
Python from scratch earlier just to be sure.

Oh, dang, I'm sorry.  Turns out my Visual Studio run was still 
pointing at the 24-maint branch checkout -- I wasn't 
recompiling the HEAD at all.  Works fine!  False alarm.  Sorry, 
Raymond!

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-02-15 18:48

Message:
Logged In: YES 
user_id=80475

Hmm, I don't see how we could get different results.  After
a fresh cvs up and recompilation, I get:

C:\py25>cvs st Python/compile.c
===
File: compile.c Status: Up-to-date

   Working revision:2.344
   Repository revision: 2.344  
/cvsroot/python/python/dist/src/Python/compile.
,v
   Sticky Tag:  (none)
   Sticky Date: (none)
   Sticky Options:  (none)


C:\py25>cvs st Lib/test/test_peepholer.py
===
File: test_peepholer.py Status: Up-to-date

   Working revision:1.11
   Repository revision: 1.11   
/cvsroot/python/python/dist/src/Lib/test/test_pe
epholer.py,v
   Sticky Tag:  (none)
   Sticky Date: (none)
   Sticky Options:  (none)


C:\py25\Lib\test>python -tt test_peepholer.py
test_elim_extra_return (__main__.TestTranforms) ... ok
test_elim_inversion_of_is_or_in (__main__.TestTranforms) ... ok
test_folding_of_binops_on_constants (__main__.TestTranforms)
... ok
test_folding_of_tuples_of_constants (__main__.TestTranforms)
... ok
test_none_as_constant (__main__.TestTranforms) ... ok
test_pack_unpack (__main__.TestTranforms) ... ok
test_unot (__main__.TestTranforms) ... ok
test_while_one (__main__.TestTranforms) ... ok

--
Ran 8 tests in 0.170s

OK


C:\py25>python
Python 2.5a0 (#46, Feb 15 2005, 18:32:36) [MSC v.1200 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> from dis import dis
>>> dis(compile('a="x"*1000', '', 'single'))
  1   0 LOAD_CONST   0 ('x')
  3 LOAD_CONST   1 (1000)
  6 BINARY_MULTIPLY
  7 STORE_NAME   0 (a)
 10 LOAD_CONST   2 (None)
 13 RETURN_VALUE


--

Comment By: Tim Peters (tim_one)
Date: 2005-02-15 18:03

Message:
Logged In: YES 
user_id=31435

Well, I'm using rt.bat from PCbuild to run the tests.  That 
deletes all the .pyc and .pyo files reachable from Lib before 
running the tests.  So, no, deleting .pyc doesn't matter here.

...\PCbuild>python rmpyc.py
81 .pyc deleted, 0 .pyo deleted

...\PCbuild>dir/s/b ..\Lib\*.pyc ..\Lib\*.pyo
File Not Found

...\PCbuild>rt test_peepholer
Deleting .pyc/.pyo files ...
14 .pyc deleted, 0 .pyo deleted

...\PCbuild>python  -E -tt ../lib/test/regrtest.py 
test_peepholer
test_peepholer
test test_peepholer failed -- Traceback (most recent call 
last):
  File "C:\Code\python\lib\test\test_peepholer.py", line 134, 
in test_folding_of_binops_on_constants
self.assert_('(1000)' in asm)
AssertionError

1 test failed:
test_peepholer
About to run again without deleting .pyc/.pyo first:
Press any key to continue . . .
Terminate batch job (Y/N)? y

Is it possible, e.g., that you have an unchecked-in change on 
your development machine?

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-02-15 17:49

Message:
Logged In: YES 
user_id=80475

Can you confirm that it works after deleting the pyc file? 
If so, I'll bump the magi

[ python-Bugs-1123660 ] add SHA256/384/512 to lib

[SourceForge.net]

Bugs item #1123660, was opened at 2005-02-16 04:14
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=1123660&group_id=5470

Category: Python Library
Group: Feature Request
Status: Open
Resolution: None
Priority: 5
Submitted By: paul rubin (phr)
Assigned to: Nobody/Anonymous (nobody)
Summary: add SHA256/384/512 to lib

Initial Comment:
According to
http://www.schneier.com/blog/archives/2005/02/sha1_broken.html
some Chinese researchers have just announced a break
against SHA1.  These are the same guys who broke MD5 a
few months ago and the SHA1 break, while not exactly
expected, is also not really shocking at this point. 
The break allows finding a free collision in the full
SHA1 in O(2**69) operations, still an awful lot in
practice.  So nobody should panic.  But it means that
new applications probably want to use SHA256, SHA384,
or SHA512, which were standardized by NIST at the same
time AES was standardized, as successors to SHA1.  The
hash lengths are 256, 384, or 512 bits respectively,
and correspond to 2x the AES key lengths of 128, 192,
or 384 bits.  Their design is strengthened from SHA1 to
resist attacks like this.  On the other hand, they are
slower than SHA1.

Anyway, there are various free implementations of the
algorithms around (libtomcrypt.org has some public
domain versions) so it should be straightforward enough
to transplant the Python C API wrapper from sha.c to it.

I think it's reasonable to put these all into the
existing sha module, rather than make a new module. 
They could be called by adding an optional arg to sha.new:
x = sha.new(data, 256).digest()
would find the sha256 digest, etc.  

Note that sha512 and sha384 are the same algorithm,
with different initial parameters and with 128 bits
discarded for sha384. 

--

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

[ python-Bugs-1123695 ] attempting to use urllib2 on some URLs fails starting on 2.4

[SourceForge.net]

Bugs item #1123695, was opened at 2005-02-16 01:06
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=1123695&group_id=5470

Category: Python Library
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Stephan Sokolow (ssokolow)
Assigned to: Nobody/Anonymous (nobody)
Summary: attempting to use urllib2 on some URLs fails starting on 2.4

Initial Comment:
The following will work correctly on Python 2.3.3 but fails 
on Python 2.4 
 
Python 2.4 (#1, Dec  4 2004, 01:33:42) 
[GCC 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)] on linux2 
Type "help", "copyright", "credits" or "license" for more 
information. 
>>> import urllib2 
>>> 
urllib2.urlopen('http://www.fanfiction.net/s/636805/10/').read() 
Traceback (most recent call last): 
  File "", line 1, in ? 
  File "/usr/local/lib/python2.4/socket.py", line 285, in read 
data = self._sock.recv(recv_size) 
  File "/usr/local/lib/python2.4/httplib.py", line 456, in read 
return self._read_chunked(amt) 
  File "/usr/local/lib/python2.4/httplib.py", line 495, in 
_read_chunked 
chunk_left = int(line, 16) 
ValueError: invalid literal for int(): 

--

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

[ python-Bugs-1123716 ] descrintro describes __new__ and __init__ behavior wrong

[SourceForge.net]

Bugs item #1123716, was opened at 2005-02-15 23:48
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=1123716&group_id=5470

Category: Documentation
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Steven Bethard (bediviere)
Assigned to: Nobody/Anonymous (nobody)
Summary: descrintro describes __new__ and __init__ behavior wrong

Initial Comment:
The current descrintro.html says:

"__new__ must return an object... If you return an
existing object, the constructor call will still call
its __init__ method. If you return an object of a
different class, its __init__ method will be called..."

This suggests that __new__ will call __init__ of the
object even if the object is a different type.  The
code in typeobject.c disagrees with this:

static PyObject *
type_call(PyTypeObject *type, PyObject *args, PyObject
*kwds)
{
...
/* If the returned object is not an instance of type,
   it won't be initialized. */
if (!PyType_IsSubtype(obj->ob_type, type))
return obj;
...
}

Suggested fix:

"__new__ must return an object... If you return an
existing object, the constructor call will still call
its __init__ method unless the object is an instance of
a different class..."

--

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

[ python-Bugs-1115989 ] xmlrpclib: wrong decoding in '_stringify'

[SourceForge.net]

Bugs item #1115989, was opened at 2005-02-04 07:25
Message generated for change (Comment added) made by effbot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115989&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Dieter Maurer (dmaurer)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xmlrpclib: wrong decoding in '_stringify'

Initial Comment:
'_stringify' tries to convert a unicode string 
into a pure ascii string by 'str(string)'. 
 
This can lead to catastrophic behaviour when 
Python's "defaultencoding" is not "ascii". 
 
The attached patch uses "string.encode('ascii')" 
instead 
to become independent of the default encoding. 
 

--

>Comment By: Fredrik Lundh (effbot)
Date: 2005-02-16 08:08

Message:
Logged In: YES 
user_id=38376

(footnote: like any other global interpreter setting, changing 
the default encoding is a bad idea in general.   the 
setdefaultencoding hook was added for experimentation 
during unicode development, and the idea was to remove it 
when things had settled down.  too bad the documentation 
doesn't reflect this, though...).

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2005-02-11 19:06

Message:
Logged In: YES 
user_id=3066

Fixed for Python 2.4.1 and 2.5:

Lib/xmlrpclib.py  1.36.2.1, 1.40
Lib/test/test_xmlrpc.py  1.5.4.1, 1.7

I committed the attached patch and added a unit test. 
Python 2.3 got left out since this doesn't seem critical
enough to destabilize old applications.  I won't strongly
object if someone backports it to 2.3.6, if they actually
think there's going to be a 2.3.6.

--

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

[ python-Bugs-1123727 ] gensuitemodule.processfile fails

[SourceForge.net]

Bugs item #1123727, was opened at 2005-02-16 07:17
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=1123727&group_id=5470

Category: Macintosh
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Jurjen N.E. Bos (jneb)
Assigned to: Jack Jansen (jackjansen)
Summary: gensuitemodule.processfile fails

Initial Comment:
gensuitemodule.processfile fails for an application as trivial as 
Safari, while the same procedure works OK on version 2.3.

On version 2.3:
>>> from gensuitemodule import processfile; processfile('/
Applications/Safari.app')
[lots of dialogs]

On version 2.4, same machine:
>>> from gensuitemodule import processfile; processfile('/
Applications/Safari.app')
Traceback (most recent call last):
  File "", line 1, in ?
  File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
python2.4/plat-mac/gensuitemodule.py", line 222, in processfile
verbose=verbose)
  File "/Library/Frameworks/Python.framework/Versions/2.4/lib/
python2.4/plat-mac/gensuitemodule.py", line 436, in compileaete
creatorsignature, dummy = MacOS.GetCreatorAndType(fname)
Error: (-43, 'File not found')
I'm pretty conviced the application did not move in the 20 seconds 
between those two invocations :-)

Any suggestions?

- Jurjen

--

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

[ python-Bugs-1115989 ] xmlrpclib: wrong decoding in '_stringify'

[SourceForge.net]

Bugs item #1115989, was opened at 2005-02-04 01:25
Message generated for change (Comment added) made by fdrake
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115989&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Dieter Maurer (dmaurer)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xmlrpclib: wrong decoding in '_stringify'

Initial Comment:
'_stringify' tries to convert a unicode string 
into a pure ascii string by 'str(string)'. 
 
This can lead to catastrophic behaviour when 
Python's "defaultencoding" is not "ascii". 
 
The attached patch uses "string.encode('ascii')" 
instead 
to become independent of the default encoding. 
 

--

>Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2005-02-16 02:22

Message:
Logged In: YES 
user_id=3066

Agreed.  It's use in the test was simply to duplicate the 
environment the xmlrpclib code failed in. 
 
Getting all the right people to agree that it should be 
completely removed and the default encoding always set to 
ASCII is a separate issue, though.  This bug was a 
consequence of the existing, documented flexibility.  As 
long as that exists, the standard library has to deal with 
it. 
 

--

Comment By: Fredrik Lundh (effbot)
Date: 2005-02-16 02:08

Message:
Logged In: YES 
user_id=38376

(footnote: like any other global interpreter setting, changing 
the default encoding is a bad idea in general.   the 
setdefaultencoding hook was added for experimentation 
during unicode development, and the idea was to remove it 
when things had settled down.  too bad the documentation 
doesn't reflect this, though...).

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2005-02-11 13:06

Message:
Logged In: YES 
user_id=3066

Fixed for Python 2.4.1 and 2.5:

Lib/xmlrpclib.py  1.36.2.1, 1.40
Lib/test/test_xmlrpc.py  1.5.4.1, 1.7

I committed the attached patch and added a unit test. 
Python 2.3 got left out since this doesn't seem critical
enough to destabilize old applications.  I won't strongly
object if someone backports it to 2.3.6, if they actually
think there's going to be a 2.3.6.

--

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

[ python-Bugs-1115989 ] xmlrpclib: wrong decoding in '_stringify'

[SourceForge.net]

Bugs item #1115989, was opened at 2005-02-04 07:25
Message generated for change (Comment added) made by effbot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1115989&group_id=5470

Category: Python Library
Group: Python 2.3
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Dieter Maurer (dmaurer)
Assigned to: Fred L. Drake, Jr. (fdrake)
Summary: xmlrpclib: wrong decoding in '_stringify'

Initial Comment:
'_stringify' tries to convert a unicode string 
into a pure ascii string by 'str(string)'. 
 
This can lead to catastrophic behaviour when 
Python's "defaultencoding" is not "ascii". 
 
The attached patch uses "string.encode('ascii')" 
instead 
to become independent of the default encoding. 
 

--

>Comment By: Fredrik Lundh (effbot)
Date: 2005-02-16 08:32

Message:
Logged In: YES 
user_id=38376

Adding a brief "avoid, if possible; may break external libraries, 
may go away in the future; use encoded streams and explicit 
encodings instead" note to the "sys" documentation might be 
a good idea, though.

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2005-02-16 08:22

Message:
Logged In: YES 
user_id=3066

Agreed.  It's use in the test was simply to duplicate the 
environment the xmlrpclib code failed in. 
 
Getting all the right people to agree that it should be 
completely removed and the default encoding always set to 
ASCII is a separate issue, though.  This bug was a 
consequence of the existing, documented flexibility.  As 
long as that exists, the standard library has to deal with 
it. 
 

--

Comment By: Fredrik Lundh (effbot)
Date: 2005-02-16 08:08

Message:
Logged In: YES 
user_id=38376

(footnote: like any other global interpreter setting, changing 
the default encoding is a bad idea in general.   the 
setdefaultencoding hook was added for experimentation 
during unicode development, and the idea was to remove it 
when things had settled down.  too bad the documentation 
doesn't reflect this, though...).

--

Comment By: Fred L. Drake, Jr. (fdrake)
Date: 2005-02-11 19:06

Message:
Logged In: YES 
user_id=3066

Fixed for Python 2.4.1 and 2.5:

Lib/xmlrpclib.py  1.36.2.1, 1.40
Lib/test/test_xmlrpc.py  1.5.4.1, 1.7

I committed the attached patch and added a unit test. 
Python 2.3 got left out since this doesn't seem critical
enough to destabilize old applications.  I won't strongly
object if someone backports it to 2.3.6, if they actually
think there's going to be a 2.3.6.

--

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