[ python-Bugs-1167751 ] Argument genexp corner case

[SourceForge.net]

Bugs item #1167751, was opened at 2005-03-22 04:47
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167751&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: Parser/Compiler
Group: Python 2.5
Status: Closed
Resolution: Fixed
Priority: 8
Submitted By: John Ehresman (jpe)
Assigned to: Anthony Baxter (anthonybaxter)
Summary: Argument genexp corner case

Initial Comment:
The following raises an unexpected exception; I would
expect it to either work or raise a SyntaxError.  It
seems that the grammar parses it, but the compiler does
not do the right thing.

>>> def foo(a): pass

>>> foo(a = i for i in range(10))

Traceback (most recent call last):
  File "", line 1, in ?
NameError: name 'i' is not defined

foo(a = (i for i in range(10)) works.

--

>Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-10-21 17:55

Message:
Logged In: YES 
user_id=29957

I can't see a problem with backporting this to 2.4


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-21 16:27

Message:
Logged In: YES 
user_id=33168

Checked in as:
 * Python/graminit.c 2.41
 * Lib/test/test_genexps.py 1.10
 * Grammar/Grammar 1.55
 * Misc/NEWS 1.1392 and 1.1391

Leaving it up to Anthony whether this should be backported.

--

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-10-11 23:43

Message:
Logged In: YES 
user_id=1038590

The problem is definitely on the parser end though:

Py> compiler.parse("foo(x=i for i in range(10))")
Module(None, Stmt([Discard(CallFunc(Name('foo'),
[Keyword('x', Name('i'))], None, None))]))

It's getting to what looks like a valid keyword argument in
"x=i" and throwing the rest of it away, when it should be
flagging a syntax error (the parser's limited lookahead
should be enough to spot the erroneous 'for' keyword and
bail out).

The problem's actually worse than the OP noted: consider
what will happen if there is a variable "i" visible from the
location of the function call (e.g. from a list
comprehension or for loop in a nested scope). Good luck
tracking that one down. . .


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-11 14:10

Message:
Logged In: YES 
user_id=33168

I definitely agree this is a big problem.

Here's what the code above generates:
2   0 LOAD_GLOBAL  0 (foo)
  3 LOAD_CONST   1 ('a')
  6 LOAD_GLOBAL  1 (i)
  9 CALL_FUNCTION  256
 12 POP_TOP
 13 LOAD_CONST   0 (None)
 16 RETURN_VALUE

If I put parens around the genexp, I get:
2   0 LOAD_GLOBAL  0 (foo)
  3 LOAD_CONST   1 ('a')
  6 LOAD_CONST   2 ( at 0x2a960baae8, file "", line 2>)
  9 MAKE_FUNCTION0
 12 LOAD_GLOBAL  1 (range)
 15 LOAD_CONST   3 (10)
 18 CALL_FUNCTION1
 21 GET_ITER
 22 CALL_FUNCTION1
 25 CALL_FUNCTION  256
 28 POP_TOP
 29 LOAD_CONST   0 (None)
 32 RETURN_VALUE


--

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

[ python-Bugs-1167751 ] Argument genexp corner case

[SourceForge.net]

Bugs item #1167751, was opened at 2005-03-22 04:47
Message generated for change (Settings changed) made by anthonybaxter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1167751&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: Parser/Compiler
Group: Python 2.5
Status: Closed
Resolution: Fixed
Priority: 8
Submitted By: John Ehresman (jpe)
>Assigned to: Neal Norwitz (nnorwitz)
Summary: Argument genexp corner case

Initial Comment:
The following raises an unexpected exception; I would
expect it to either work or raise a SyntaxError.  It
seems that the grammar parses it, but the compiler does
not do the right thing.

>>> def foo(a): pass

>>> foo(a = i for i in range(10))

Traceback (most recent call last):
  File "", line 1, in ?
NameError: name 'i' is not defined

foo(a = (i for i in range(10)) works.

--

Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-10-21 17:55

Message:
Logged In: YES 
user_id=29957

I can't see a problem with backporting this to 2.4


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-21 16:27

Message:
Logged In: YES 
user_id=33168

Checked in as:
 * Python/graminit.c 2.41
 * Lib/test/test_genexps.py 1.10
 * Grammar/Grammar 1.55
 * Misc/NEWS 1.1392 and 1.1391

Leaving it up to Anthony whether this should be backported.

--

Comment By: Nick Coghlan (ncoghlan)
Date: 2005-10-11 23:43

Message:
Logged In: YES 
user_id=1038590

The problem is definitely on the parser end though:

Py> compiler.parse("foo(x=i for i in range(10))")
Module(None, Stmt([Discard(CallFunc(Name('foo'),
[Keyword('x', Name('i'))], None, None))]))

It's getting to what looks like a valid keyword argument in
"x=i" and throwing the rest of it away, when it should be
flagging a syntax error (the parser's limited lookahead
should be enough to spot the erroneous 'for' keyword and
bail out).

The problem's actually worse than the OP noted: consider
what will happen if there is a variable "i" visible from the
location of the function call (e.g. from a list
comprehension or for loop in a nested scope). Good luck
tracking that one down. . .


--

Comment By: Neal Norwitz (nnorwitz)
Date: 2005-10-11 14:10

Message:
Logged In: YES 
user_id=33168

I definitely agree this is a big problem.

Here's what the code above generates:
2   0 LOAD_GLOBAL  0 (foo)
  3 LOAD_CONST   1 ('a')
  6 LOAD_GLOBAL  1 (i)
  9 CALL_FUNCTION  256
 12 POP_TOP
 13 LOAD_CONST   0 (None)
 16 RETURN_VALUE

If I put parens around the genexp, I get:
2   0 LOAD_GLOBAL  0 (foo)
  3 LOAD_CONST   1 ('a')
  6 LOAD_CONST   2 ( at 0x2a960baae8, file "", line 2>)
  9 MAKE_FUNCTION0
 12 LOAD_GLOBAL  1 (range)
 15 LOAD_CONST   3 (10)
 18 CALL_FUNCTION1
 21 GET_ITER
 22 CALL_FUNCTION1
 25 CALL_FUNCTION  256
 28 POP_TOP
 29 LOAD_CONST   0 (None)
 32 RETURN_VALUE


--

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

[ python-Bugs-792570 ] SimpleXMLRPCServer cannot handle large requests

[SourceForge.net]

Bugs item #792570, was opened at 2003-08-21 17:37
Message generated for change (Comment added) made by noplay
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=792570&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.2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Marc-André Morissette (morissette)
Assigned to: Nobody/Anonymous (nobody)
Summary: SimpleXMLRPCServer cannot handle large requests

Initial Comment:
SimpleXMLRPCServer throws a WSAEINTR ioerror on 
large XML-RPC requests.

Under Windows, the socket.read() method cannot seem 
to handle large (tens of megabytes) reads (could be a 
Python specific problem). This means that very large 
XML-RPC requests can cause the exception.

Here is a tentative patch against 2.2.3 to fix the 
problem. It should be easy to port it to 2.3

---
 /cygdrive/c/Python22/Lib/SimpleXMLRPCServer.py  
2003-07-09 14:16:52.0 -0400
+++ /cygdrive/z/SimpleXMLRPCServer.py   2003-08-21 
11:01:19.0 -0400
@@ -73,6 +73,8 @@
 import SocketServer
 import BaseHTTPServer
 import sys
+import cStringIO

 class SimpleXMLRPCRequestHandler
(BaseHTTPServer.BaseHTTPRequestHandler):
 """Simple XML-RPC request handler class.
@@ -95,7 +97,14 @@

 try:
 # get arguments
-data = self.rfile.read(int(self.headers["content-
length"]))
+max_chunk_size = 1000
+content_length = int(self.headers["content-
length"])
+buffer = cStringIO.StringIO()
+for offset in range(0, content_length, 
max_chunk_size):
+chunk_size = min(content_length - offset, 
max_chunk_size)
+buffer.write(self.rfile.read(chunk_size))
+data = buffer.getvalue()
+buffer.close()
 params, method = xmlrpclib.loads(data)

 # generate response



--

Comment By: julien duponchelle (noplay)
Date: 2005-10-21 11:36

Message:
Logged In: YES 
user_id=446148

I have the same problem with Python2.4 with windows and
linux version.

If XML-RPC server reads to large buffer, it returns only a
part of the buffer.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-06-01 14:26

Message:
Logged In: YES 
user_id=1188172

Marc-Andre, can you still reproduce this with Python 2.4?

--

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

[ python-Bugs-1333982 ] Bugs of the new AST compiler

[SourceForge.net]

Bugs item #1333982, was opened at 2005-10-21 10: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=1333982&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: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bugs of the new AST compiler

Initial Comment:
The newly merged AST branch is likely to expose
a number of small problems before it stabilizes,
so here is a tentative bug tracker entry to
collect such small problems.


--

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

[ python-Bugs-1333982 ] Bugs of the new AST compiler

[SourceForge.net]

Bugs item #1333982, was opened at 2005-10-21 10:08
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&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: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bugs of the new AST compiler

Initial Comment:
The newly merged AST branch is likely to expose
a number of small problems before it stabilizes,
so here is a tentative bug tracker entry to
collect such small problems.


--

>Comment By: Armin Rigo (arigo)
Date: 2005-10-21 10:13

Message:
Logged In: YES 
user_id=4771

A scoping problem (comparing with the old compiler):

class X:
print hello

The variable 'hello' is incorrectly looked up with
LOAD_GLOBAL instead of LOAD_NAME.  It causes a crash
in PyPy in a case where the name 'hello' is stored
into the class implicitely (via locals()).  It can
probably be discussed if the bug is in PyPy, but it
is a difference in behavior.

--

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

[ python-Bugs-1333982 ] Bugs of the new AST compiler

[SourceForge.net]

Bugs item #1333982, was opened at 2005-10-21 10:08
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&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: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bugs of the new AST compiler

Initial Comment:
The newly merged AST branch is likely to expose
a number of small problems before it stabilizes,
so here is a tentative bug tracker entry to
collect such small problems.


--

>Comment By: Armin Rigo (arigo)
Date: 2005-10-21 10:22

Message:
Logged In: YES 
user_id=4771

import a as b, c

the 'c' part gets completely forgotten and there is
no 'IMPORT_NAME c' in the bytecode.

--

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 10:13

Message:
Logged In: YES 
user_id=4771

A scoping problem (comparing with the old compiler):

class X:
print hello

The variable 'hello' is incorrectly looked up with
LOAD_GLOBAL instead of LOAD_NAME.  It causes a crash
in PyPy in a case where the name 'hello' is stored
into the class implicitely (via locals()).  It can
probably be discussed if the bug is in PyPy, but it
is a difference in behavior.

--

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

[ python-Bugs-1327110 ] wrong TypeError traceback in generator expressions

[SourceForge.net]

Bugs item #1327110, was opened at 2005-10-14 21:25
Message generated for change (Comment added) made by mwh
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1327110&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 Interpreter Core
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Yusuke Shinyama (euske)
Assigned to: Michael Hudson (mwh)
Summary: wrong TypeError traceback in generator expressions

Initial Comment:
In the following session, the TypeError traceback of '
'.join( foo(i) for i in range(10) ) is wrong. The cause
is not because of being a generator, but of its
manually created exception.
--
Python 2.4.2 (#1, Oct 14 2005, 16:08:57)
[GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on
linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> def foo(x): raise TypeError('foo!')
...
>>> def bar(x): raise ValueError('bar!')
...
>>> ' '.join( foo(i) for i in range(10) )
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: sequence expected, generator found
>>> ' '.join( bar(i) for i in range(10) )
Traceback (most recent call last):
  File "", line 1, in ?
  File "", line 1, in 
  File "", line 1, in bar
ValueError: bar!


--

>Comment By: Michael Hudson (mwh)
Date: 2005-10-21 12:46

Message:
Logged In: YES 
user_id=6656

Ok, this is checked in as:

Objects/stringobject.c revision 2.235
Objects/unicodeobject.c revision 2.235
Lib/test/test_string.py revision 1.28
Lib/test/string_tests.py revision 1.46

Thanks for the report.

--

Comment By: Michael Hudson (mwh)
Date: 2005-10-16 15:28

Message:
Logged In: YES 
user_id=6656

Agreed.

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-16 15:24

Message:
Logged In: YES 
user_id=80475

I don't think this should be backported.

--

Comment By: Michael Hudson (mwh)
Date: 2005-10-16 13:25

Message:
Logged In: YES 
user_id=6656

Oh come on, this is just a bad idea (esp so in this case; the error message 
that you get for e.g. ''.join(1) is "iteration over non-sequence" which pretty 
clear -- I think this may have improved since the introduction of the 
PySequence_Fast API).

Here's a patch (with tests) that I'll check in after Jeremy has merged the 
ast-branch unless you talk very fast :)

--

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-10-14 21:57

Message:
Logged In: YES 
user_id=80475

This isn't an error -- it was a design decision.  It is not
unusual to have a situation arise in Python where a high
level routine competes with a low level routine over which
is in the best position to provide the most useful error
message.  The low level routine typically knows the
proximate cause.  The high level routine typically knows
what the user was trying to do.  

In the case of str.join(), the high level routine usually
makes the most informative error message; however, it is
sometimes off the mark.

Will revisit the design decision to see if it should be
changed.  Lowering the priority because the code is working
as designed, the error type is correct, and it is not clear
that any change is warranted.

--

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

[ python-Bugs-1333982 ] Bugs of the new AST compiler

[SourceForge.net]

Bugs item #1333982, was opened at 2005-10-21 10:08
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&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: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bugs of the new AST compiler

Initial Comment:
The newly merged AST branch is likely to expose
a number of small problems before it stabilizes,
so here is a tentative bug tracker entry to
collect such small problems.


--

>Comment By: Armin Rigo (arigo)
Date: 2005-10-21 11:54

Message:
Logged In: YES 
user_id=4771

any reason why lambda functions have a __name__ of
'lambda' now instead of '' ?

--

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 10:22

Message:
Logged In: YES 
user_id=4771

import a as b, c

the 'c' part gets completely forgotten and there is
no 'IMPORT_NAME c' in the bytecode.

--

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 10:13

Message:
Logged In: YES 
user_id=4771

A scoping problem (comparing with the old compiler):

class X:
print hello

The variable 'hello' is incorrectly looked up with
LOAD_GLOBAL instead of LOAD_NAME.  It causes a crash
in PyPy in a case where the name 'hello' is stored
into the class implicitely (via locals()).  It can
probably be discussed if the bug is in PyPy, but it
is a difference in behavior.

--

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

[ python-Bugs-1333982 ] Bugs of the new AST compiler

[SourceForge.net]

Bugs item #1333982, was opened at 2005-10-21 10:08
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&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: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bugs of the new AST compiler

Initial Comment:
The newly merged AST branch is likely to expose
a number of small problems before it stabilizes,
so here is a tentative bug tracker entry to
collect such small problems.


--

>Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:01

Message:
Logged In: YES 
user_id=4771

For reference, an optimization that got lost:

def f():
'a'
'b'

'a' is the docstring, but the 'b' previously did not show
up anywhere in the code object.  Now there is the
LOAD_CONST/POP_TOP pair.

--

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 11:54

Message:
Logged In: YES 
user_id=4771

any reason why lambda functions have a __name__ of
'lambda' now instead of '' ?

--

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 10:22

Message:
Logged In: YES 
user_id=4771

import a as b, c

the 'c' part gets completely forgotten and there is
no 'IMPORT_NAME c' in the bytecode.

--

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 10:13

Message:
Logged In: YES 
user_id=4771

A scoping problem (comparing with the old compiler):

class X:
print hello

The variable 'hello' is incorrectly looked up with
LOAD_GLOBAL instead of LOAD_NAME.  It causes a crash
in PyPy in a case where the name 'hello' is stored
into the class implicitely (via locals()).  It can
probably be discussed if the bug is in PyPy, but it
is a difference in behavior.

--

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

[ python-Bugs-1333982 ] Bugs of the new AST compiler

[SourceForge.net]

Bugs item #1333982, was opened at 2005-10-21 10:08
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&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: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bugs of the new AST compiler

Initial Comment:
The newly merged AST branch is likely to expose
a number of small problems before it stabilizes,
so here is a tentative bug tracker entry to
collect such small problems.


--

>Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:15

Message:
Logged In: YES 
user_id=4771

The Python rules about which names get mangled are a bit
insane.  I share mwh's view that mangling should never have
been invented in the first place, but well:

>>> def f():
...   __x = 5
...   class X:
... def g(self):
...   return __x
...   return X
... 
Fatal Python error: unknown scope for _X__x in X(135832776)
in 


--

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:01

Message:
Logged In: YES 
user_id=4771

For reference, an optimization that got lost:

def f():
'a'
'b'

'a' is the docstring, but the 'b' previously did not show
up anywhere in the code object.  Now there is the
LOAD_CONST/POP_TOP pair.

--

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 11:54

Message:
Logged In: YES 
user_id=4771

any reason why lambda functions have a __name__ of
'lambda' now instead of '' ?

--

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 10:22

Message:
Logged In: YES 
user_id=4771

import a as b, c

the 'c' part gets completely forgotten and there is
no 'IMPORT_NAME c' in the bytecode.

--

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 10:13

Message:
Logged In: YES 
user_id=4771

A scoping problem (comparing with the old compiler):

class X:
print hello

The variable 'hello' is incorrectly looked up with
LOAD_GLOBAL instead of LOAD_NAME.  It causes a crash
in PyPy in a case where the name 'hello' is stored
into the class implicitely (via locals()).  It can
probably be discussed if the bug is in PyPy, but it
is a difference in behavior.

--

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

[ python-Bugs-1333982 ] Bugs of the new AST compiler

[SourceForge.net]

Bugs item #1333982, was opened at 2005-10-21 10:08
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&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: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bugs of the new AST compiler

Initial Comment:
The newly merged AST branch is likely to expose
a number of small problems before it stabilizes,
so here is a tentative bug tracker entry to
collect such small problems.


--

>Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:33

Message:
Logged In: YES 
user_id=4771

I would suspect the following one to be due to incorrect
handling of EXTENDED_ARG -- it's from a PyPy test about that:

longexpr = 'x = x or ' + '-x' * 2500
code = '''
def f(x):
%s
%s
%s
%s
%s
%s
%s
%s
%s
%s
while x:
x -= 1
# EXTENDED_ARG/JUMP_ABSOLUTE here
return x
''' % ((longexpr,)*10)

exec code
f(5)
SystemError: unknown opcode

dis.dis() shows that the target of both the SETUP_LOOP and
the JUMP_IF_FALSE at the start of the loop are wrong.

--

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:15

Message:
Logged In: YES 
user_id=4771

The Python rules about which names get mangled are a bit
insane.  I share mwh's view that mangling should never have
been invented in the first place, but well:

>>> def f():
...   __x = 5
...   class X:
... def g(self):
...   return __x
...   return X
... 
Fatal Python error: unknown scope for _X__x in X(135832776)
in 


--

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:01

Message:
Logged In: YES 
user_id=4771

For reference, an optimization that got lost:

def f():
'a'
'b'

'a' is the docstring, but the 'b' previously did not show
up anywhere in the code object.  Now there is the
LOAD_CONST/POP_TOP pair.

--

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 11:54

Message:
Logged In: YES 
user_id=4771

any reason why lambda functions have a __name__ of
'lambda' now instead of '' ?

--

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 10:22

Message:
Logged In: YES 
user_id=4771

import a as b, c

the 'c' part gets completely forgotten and there is
no 'IMPORT_NAME c' in the bytecode.

--

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 10:13

Message:
Logged In: YES 
user_id=4771

A scoping problem (comparing with the old compiler):

class X:
print hello

The variable 'hello' is incorrectly looked up with
LOAD_GLOBAL instead of LOAD_NAME.  It causes a crash
in PyPy in a case where the name 'hello' is stored
into the class implicitely (via locals()).  It can
probably be discussed if the bug is in PyPy, but it
is a difference in behavior.

--

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

[ python-Bugs-1333982 ] Bugs of the new AST compiler

[SourceForge.net]

Bugs item #1333982, was opened at 2005-10-21 10:08
Message generated for change (Comment added) made by arigo
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1333982&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: Parser/Compiler
Group: AST
Status: Open
Resolution: None
Priority: 5
Submitted By: Armin Rigo (arigo)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bugs of the new AST compiler

Initial Comment:
The newly merged AST branch is likely to expose
a number of small problems before it stabilizes,
so here is a tentative bug tracker entry to
collect such small problems.


--

>Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:45

Message:
Logged In: YES 
user_id=4771

The following (similarly strange-looking) code snippets
compiled successfully before, now they give SyntaxErrors:


def f():
class g:
exec "hi"
x

def f(x):
class g:
exec "hi"
x

def f():
class g:
from a import *
x

def f(x):
class g:
from a import *
x


--

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:33

Message:
Logged In: YES 
user_id=4771

I would suspect the following one to be due to incorrect
handling of EXTENDED_ARG -- it's from a PyPy test about that:

longexpr = 'x = x or ' + '-x' * 2500
code = '''
def f(x):
%s
%s
%s
%s
%s
%s
%s
%s
%s
%s
while x:
x -= 1
# EXTENDED_ARG/JUMP_ABSOLUTE here
return x
''' % ((longexpr,)*10)

exec code
f(5)
SystemError: unknown opcode

dis.dis() shows that the target of both the SETUP_LOOP and
the JUMP_IF_FALSE at the start of the loop are wrong.

--

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:15

Message:
Logged In: YES 
user_id=4771

The Python rules about which names get mangled are a bit
insane.  I share mwh's view that mangling should never have
been invented in the first place, but well:

>>> def f():
...   __x = 5
...   class X:
... def g(self):
...   return __x
...   return X
... 
Fatal Python error: unknown scope for _X__x in X(135832776)
in 


--

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 12:01

Message:
Logged In: YES 
user_id=4771

For reference, an optimization that got lost:

def f():
'a'
'b'

'a' is the docstring, but the 'b' previously did not show
up anywhere in the code object.  Now there is the
LOAD_CONST/POP_TOP pair.

--

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 11:54

Message:
Logged In: YES 
user_id=4771

any reason why lambda functions have a __name__ of
'lambda' now instead of '' ?

--

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 10:22

Message:
Logged In: YES 
user_id=4771

import a as b, c

the 'c' part gets completely forgotten and there is
no 'IMPORT_NAME c' in the bytecode.

--

Comment By: Armin Rigo (arigo)
Date: 2005-10-21 10:13

Message:
Logged In: YES 
user_id=4771

A scoping problem (comparing with the old compiler):

class X:
print hello

The variable 'hello' is incorrectly looked up with
LOAD_GLOBAL instead of LOAD_NAME.  It causes a crash
in PyPy in a case where the name 'hello' is stored
into the class implicitely (via locals()).  It can
probably be discussed if the bug is in PyPy, but it
is a difference in behavior.

--

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

[ python-Bugs-1257525 ] Encodings iso8859_1 and latin_1 are redundant

[SourceForge.net]

Bugs item #1257525, was opened at 2005-08-12 14:22
Message generated for change (Settings changed) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1257525&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.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: liturgist (liturgist)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Encodings iso8859_1 and latin_1 are redundant

Initial Comment:
./lib/encodings contains both:

iso8859_1.py
latin_1.py

Only one should be present.  Martin says that latin_1
is faster.  Using the 'iso' name would correlate better
with the other ISO encodings provided.

If the latin_1 code is faster, then it should be in the
iso8859_1.py file.  If an automated process produces
the 'iso*' encodings, then it should either produce the
faster code or stop producing iso8859_1.

Regardless, one of the files should be removed.

--

>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-10-21 16:03

Message:
Logged In: YES 
user_id=38388

I've added an alias entry from iso8859_1 to latin_1.


--

Comment By: Eray Ozkural (exa)
Date: 2005-10-11 23:22

Message:
Logged In: YES 
user_id=1454

i understand that there ought to be one fast implementation, but i 
suppose both names should be available. 
 

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-08-12 16:30

Message:
Logged In: YES 
user_id=38388

To answer your questions:

Yes, the encoding is the same for both latin-1 and iso8859-1.

Specifying latin-1 instead of iso8859-1 will allow the code
to use short-cuts.

You have to grep for 'latin-1'.

--

Comment By: liturgist (liturgist)
Date: 2005-08-12 16:01

Message:
Logged In: YES 
user_id=197677

Where could one see some of the "shortcuts" in the Unicode
integration code that make using "latin_1" faster in the
runtime?  I greped *.py and *.c, but could not readily
identify any candidates.

--

Comment By: liturgist (liturgist)
Date: 2005-08-12 15:12

Message:
Logged In: YES 
user_id=197677

Ok.  How about if we specify iso8859_1 as "(see latin_1)" in
the documentation?

The code will work the same regardless of which encoding
name the developer uses.  Right?

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-08-12 14:49

Message:
Logged In: YES 
user_id=38388

Good point.

The iso8859_1.py codec should be removed and added as alias
to latin-1.

Martin is right: the latin-1 codec is not only faster, but
the Unicode integration code also has a lot of short-cuts
for the "latin-1" encoding, so overall performance is better
if you use that name for the encoding.


--

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

[ python-Bugs-1324237 ] ISO8859-9 broken

[SourceForge.net]

Bugs item #1324237, was opened at 2005-10-11 23:35
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1324237&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Eray Ozkural (exa)
Assigned to: M.-A. Lemburg (lemburg)
Summary: ISO8859-9 broken

Initial Comment:
Probably not limited to ISO8859-9.  
 
The problem is that the encodings returned by getlocale()   
and getpreferredencoding() are not guaranteed to work   
with, say, encode method of string.   
   
I'm on MDK10.2 and i switch to Turkish locale 
>>> locale.setlocale(locale.LC_ALL, '')
'tr_TR'
There is nothing in sys.stdout.encoding!
>>> sys.stdout.encoding
>>>
So I take a look at the encoding:
>>> locale.getlocale()
['tr_TR', 'ISO8859-9']
>>> locale.getpreferredencoding()
'ISO-8859-9'
Too bad I cannot use either encoding to encode innocent
unicode strings
>>> a = unicode('André','latin-1')
>>> print a.encode(locale.getpreferredencoding())   
Traceback (most recent call last):   
  File "", line 1, in ?   
LookupError: unknown encoding: ISO-8859-9   
>>> print a.encode(locale.getlocale()[1])   
Traceback (most recent call last):   
  File "", line 1, in ?   
LookupError: unknown encoding: ISO8859-9   
   
So I take a look at python page and I see that all encoding  
names are in lowercase. That's no good, because:  
>>> locale.getpreferredencoding().lower()  
'\xfdso-8859-9'  
  
(see bug 1193061 )  
  
So I have to do this by hand! But of course this is  
unacceptable for any locale aware application.  
>>> print a.encode('iso-8859-9')  
André  
  
Expected:  
  1. I expect the encoding string returned by  
getpreferredencoding and getlocale to be *identical*  
  2. I expect the encoding string returned to *work* with  
encode method and in general *any* function that accepts  
locales.  
  
Got:  
  1. Different, ad hoc strings  
  2. Not all aliases present, only lowercases present, no 
reliable way to find a canonical locale name.  
  
Recommendations:  
  a. Please consider the Java-like solution to make Locale  
into a class or an enum, something reliable, rather than  
just a string.  
  b. Please test the locale functions in locales other than  
US (that is not really a locale anyway)  
  
  

--

>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-10-21 16:12

Message:
Logged In: YES 
user_id=38388

Something in your installation must be broken: it seems the
system cannot find the ISO-8859-9 codec. Note that the
.encode() method uses the codec registry for the lookup of
the codec. The lookup itself is done case-insensitive and
subject to a few other normalizations (see
encodings/__init__.py).

Please check your system and then report back whether you
still see the reported error.

Thanks.

--

Comment By: Eray Ozkural (exa)
Date: 2005-10-11 23:46

Message:
Logged In: YES 
user_id=1454

BTW, I put this into Unicode category, because the bugs in it 
seemed relevant to localization. Thank you very much for your 
consideration. 
 

--

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

[ python-Bugs-1324237 ] ISO8859-9 broken

[SourceForge.net]

Bugs item #1324237, was opened at 2005-10-11 23:35
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1324237&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Eray Ozkural (exa)
Assigned to: M.-A. Lemburg (lemburg)
Summary: ISO8859-9 broken

Initial Comment:
Probably not limited to ISO8859-9.  
 
The problem is that the encodings returned by getlocale()   
and getpreferredencoding() are not guaranteed to work   
with, say, encode method of string.   
   
I'm on MDK10.2 and i switch to Turkish locale 
>>> locale.setlocale(locale.LC_ALL, '')
'tr_TR'
There is nothing in sys.stdout.encoding!
>>> sys.stdout.encoding
>>>
So I take a look at the encoding:
>>> locale.getlocale()
['tr_TR', 'ISO8859-9']
>>> locale.getpreferredencoding()
'ISO-8859-9'
Too bad I cannot use either encoding to encode innocent
unicode strings
>>> a = unicode('André','latin-1')
>>> print a.encode(locale.getpreferredencoding())   
Traceback (most recent call last):   
  File "", line 1, in ?   
LookupError: unknown encoding: ISO-8859-9   
>>> print a.encode(locale.getlocale()[1])   
Traceback (most recent call last):   
  File "", line 1, in ?   
LookupError: unknown encoding: ISO8859-9   
   
So I take a look at python page and I see that all encoding  
names are in lowercase. That's no good, because:  
>>> locale.getpreferredencoding().lower()  
'\xfdso-8859-9'  
  
(see bug 1193061 )  
  
So I have to do this by hand! But of course this is  
unacceptable for any locale aware application.  
>>> print a.encode('iso-8859-9')  
André  
  
Expected:  
  1. I expect the encoding string returned by  
getpreferredencoding and getlocale to be *identical*  
  2. I expect the encoding string returned to *work* with  
encode method and in general *any* function that accepts  
locales.  
  
Got:  
  1. Different, ad hoc strings  
  2. Not all aliases present, only lowercases present, no 
reliable way to find a canonical locale name.  
  
Recommendations:  
  a. Please consider the Java-like solution to make Locale  
into a class or an enum, something reliable, rather than  
just a string.  
  b. Please test the locale functions in locales other than  
US (that is not really a locale anyway)  
  
  

--

>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-10-21 16:18

Message:
Logged In: YES 
user_id=38388

Something in your installation must be broken: it seems the
system cannot find the ISO-8859-9 codec. 

Note that the .encode() method uses the codec registry for
the lookup of the codec. The lookup itself is done
case-insensitive and subject to a few other normalizations
(see encodings/__init__.py).

Please check your system and then report back whether you
still see the reported error.

Thanks.

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-10-21 16:12

Message:
Logged In: YES 
user_id=38388

Something in your installation must be broken: it seems the
system cannot find the ISO-8859-9 codec. Note that the
.encode() method uses the codec registry for the lookup of
the codec. The lookup itself is done case-insensitive and
subject to a few other normalizations (see
encodings/__init__.py).

Please check your system and then report back whether you
still see the reported error.

Thanks.

--

Comment By: Eray Ozkural (exa)
Date: 2005-10-11 23:46

Message:
Logged In: YES 
user_id=1454

BTW, I put this into Unicode category, because the bugs in it 
seemed relevant to localization. Thank you very much for your 
consideration. 
 

--

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

[ python-Bugs-1324237 ] ISO8859-9 broken

[SourceForge.net]

Bugs item #1324237, was opened at 2005-10-11 23:35
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1324237&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.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Eray Ozkural (exa)
Assigned to: M.-A. Lemburg (lemburg)
Summary: ISO8859-9 broken

Initial Comment:
Probably not limited to ISO8859-9.  
 
The problem is that the encodings returned by getlocale()   
and getpreferredencoding() are not guaranteed to work   
with, say, encode method of string.   
   
I'm on MDK10.2 and i switch to Turkish locale 
>>> locale.setlocale(locale.LC_ALL, '')
'tr_TR'
There is nothing in sys.stdout.encoding!
>>> sys.stdout.encoding
>>>
So I take a look at the encoding:
>>> locale.getlocale()
['tr_TR', 'ISO8859-9']
>>> locale.getpreferredencoding()
'ISO-8859-9'
Too bad I cannot use either encoding to encode innocent
unicode strings
>>> a = unicode('André','latin-1')
>>> print a.encode(locale.getpreferredencoding())   
Traceback (most recent call last):   
  File "", line 1, in ?   
LookupError: unknown encoding: ISO-8859-9   
>>> print a.encode(locale.getlocale()[1])   
Traceback (most recent call last):   
  File "", line 1, in ?   
LookupError: unknown encoding: ISO8859-9   
   
So I take a look at python page and I see that all encoding  
names are in lowercase. That's no good, because:  
>>> locale.getpreferredencoding().lower()  
'\xfdso-8859-9'  
  
(see bug 1193061 )  
  
So I have to do this by hand! But of course this is  
unacceptable for any locale aware application.  
>>> print a.encode('iso-8859-9')  
André  
  
Expected:  
  1. I expect the encoding string returned by  
getpreferredencoding and getlocale to be *identical*  
  2. I expect the encoding string returned to *work* with  
encode method and in general *any* function that accepts  
locales.  
  
Got:  
  1. Different, ad hoc strings  
  2. Not all aliases present, only lowercases present, no 
reliable way to find a canonical locale name.  
  
Recommendations:  
  a. Please consider the Java-like solution to make Locale  
into a class or an enum, something reliable, rather than  
just a string.  
  b. Please test the locale functions in locales other than  
US (that is not really a locale anyway)  
  
  

--

>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-10-21 16:25

Message:
Logged In: YES 
user_id=38388

SF has problems again it seems...

Anyway, I tried to set the TR_tr locale on my system and got
a surprising result:

>>> import locale
>>> locale.setlocale(locale.LC_ALL, 'tr_TR')
'tr_TR'
>>> locale.getpreferredencoding().lower()
'ans\xfd_x3.4-1968'
>>> locale.getpreferredencoding()
'ANSI_X3.4-1968'

So I think the problem lies with the fact that
string.lower() is locale dependent and the GLIBC folks chose
a highly incompatible way of dealing with the special
Turkish situation of the capital "I" mapping to lower-case.

While this kind of mapping may make sense for text
processing in applications it certainly does not make sense
when dealing with programming code or things that need to be
specified in plain ASCII.

In short: the encoding used for the TR_tr locale is not
ASCII-compatible and thus not suitable for Python source code.

I'm not sure what to say to this. My only advice is to *not*
set the global locale setting to TR_tr, but only do this
when it comes to actually processsing text in an application.

Alternatively, you could write you application text using
Unicode and the use the ISO-8859-9 codec to encode it for I/O.

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-10-21 16:18

Message:
Logged In: YES 
user_id=38388

Something in your installation must be broken: it seems the
system cannot find the ISO-8859-9 codec. 

Note that the .encode() method uses the codec registry for
the lookup of the codec. The lookup itself is done
case-insensitive and subject to a few other normalizations
(see encodings/__init__.py).

Please check your system and then report back whether you
still see the reported error.

Thanks.

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-10-21 16:12

Message:
Logged In: YES 
user_id=38388

Something in your installation must be broken: it seems the
system cannot find the ISO-8859-9 codec. Note that the
.encode() method uses the codec registry for the lookup of
the codec. The lookup itself is done case-insensitive and
subject to a few other normalizations (see
encodings/__init__.py).

Please check your system and then report back whether you
still s

[ python-Bugs-1313051 ] mac_roman codec missing "apple" codepoint

[SourceForge.net]

Bugs item #1313051, was opened at 2005-10-04 18:37
Message generated for change (Settings changed) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1313051&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.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tony Nelson (tony_nelson)
Assigned to: Nobody/Anonymous (nobody)
Summary: mac_roman codec missing "apple" codepoint

Initial Comment:
The mac_roman codec is missing a single codepoint for
the trademarked Apple logo (0xF0 <=> 0xF8FF per Apple
docs), which prevents round-tripping of mac_roman text
through Unicode.  Adding the codepoint as a private
encoding (per Apple) has no trademark implications,
only the character itself, in a font, would have such
issues.

I'm using Python 2.3, but AFAICT it is an issue in
later Python versions as well.

--

>Comment By: M.-A. Lemburg (lemburg)
Date: 2005-10-21 16:27

Message:
Logged In: YES 
user_id=38388

This should be resolved with the new codec in CVS.


--

Comment By: Tony Nelson (tony_nelson)
Date: 2005-10-05 04:16

Message:
Logged In: YES 
user_id=1356214

>Tony: Python is not damaging your data - the codec will
>raise an exception in case that particular character is
>converted to Unicode.

Right, crashing the unsuspecting user's program and
destroying the data utterly.  Anyway, it doesn't damage /my/
data because I add the missing codepoint to the codec:

# Fix missing Apple logo in mac_roman.
import encodings.mac_roman
if not encodings.mac_roman.decoding_map[0xF0]:
encodings.mac_roman.decoding_map[0xF0] = 0xF8FF
encodings.mac_roman.encoding_map[0xF8FF] = 0xF0

It just damages data for all the other users of the codec.

>Please recreate the codec using gencodec.py (which you can
>find the Tools/ directory) and add it as attachement to this
>bug report. Thanks.

Umm, I take it you want me to download a mapping file first.
 Here is a new mac_roman.py.


--

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-10-04 23:48

Message:
Logged In: YES 
user_id=38388

Tony, comment like yours are not very helpful.

Python's codecs rely on facts defined by standards bodies,
e.g. the Unicode consortium, ISO, etc.. If you don't present
proof of your claim then there's nothing much we can do
about your particular problem.

Fortunately, proof isn't hard to find in this case:

http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMAN.TXT

Looks like Apple added the mapping sometime after the codec
was created.

Walter: it is common for companies to add their logos as
private Unicode characters. This happens a lot in the Asian
world. Of course, interop isn't great, but at least you
don't lose information by converting to Unicode.

Tony: Python is not damaging your data - the codec will
raise an exception in case that particular character is
converted to Unicode.

Please recreate the codec using gencodec.py (which you can
find the Tools/ directory) and add it as attachement to this
bug report. Thanks.


--

Comment By: Tony Nelson (tony_nelson)
Date: 2005-10-04 22:41

Message:
Logged In: YES 
user_id=1356214

It isn't Python's job to tell people what characters they
are allowed to use.  Apple defined the codepoint and its
mapping to Unicode.  Python is not the Unicode Police, and
should not damage the data it was given just to prove a
point.  Damaging the user's data isn't very "batteries
included".

--

Comment By: Walter Dörwald (doerwalter)
Date: 2005-10-04 20:07

Message:
Logged In: YES 
user_id=89016

The codepoint 0xF8FF is in the Private Use Area, so this is
not an official Unicode character, and for other uses 0xF8FF
might mean something completely different. So I think this
mapping shouldn't be added to mac_roman.

--

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

[ python-Bugs-1334662 ] int(string, base) wrong answers

[SourceForge.net]

Bugs item #1334662, was opened at 2005-10-22 00: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=1334662&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 Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Nobody/Anonymous (nobody)
Summary: int(string, base) wrong answers

Initial Comment:
This affects all Python releases to date.  See



for discussion.  The overflow check in PyOS_strtoul() is 
too clever, and causes these wrong results on a 32-bit 
box (on a box with sizeof(long) == 8, other examples 
would fail):

int('10200202220122211', 3) = 0
int('32244002423141', 5) = 0
int('1550104015504', 6) = 0
int('211301422354', 7) = 0
int('12068657454', 9) = 0
int('1904440554', 11) = 0
int('9ba461594', 12) = 0
int('535a79889', 13) = 0
int('2ca5b7464', 14) = 0
int('1a20dcd81', 15) = 0
int('a7ffda91', 17) = 0
int('704he7g4', 18) = 0
int('4f5aff66', 19) = 0
int('3723ai4g', 20) = 0
int('281d55i4', 21) = 0
int('1fj8b184', 22) = 0
int('1606k7ic', 23) = 0
int('mb994ag', 24) = 0
int('hek2mgl', 25) = 0
int('dnchbnm', 26) = 0
int('b28jpdm', 27) = 0
int('8pfgih4', 28) = 0
int('76beigg', 29) = 0
int('5qmcpqg', 30) = 0
int('4q0jto4', 31) = 0
int('3aokq94', 33) = 0
int('2qhxjli', 34) = 0
int('2br45qb', 35) = 0
int('1z141z4', 36) = 0


--

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