[ python-Bugs-1382096 ] MacRoman Encoding Bug (OHM vs. OMEGA)

2005-12-16 Thread SourceForge.net
Bugs item #1382096, was opened at 2005-12-16 03:22
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382096&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: Sean B. Palmer (seanbpalmer)
Assigned to: M.-A. Lemburg (lemburg)
Summary: MacRoman Encoding Bug (OHM vs. OMEGA)

Initial Comment:
The file encodings/mac_roman.py in Python 2.4.1
contains the following incorrect character definition
on line 96: 

0x00bd: 0x2126, # OHM SIGN

This should read: 

0x00bd: 0x03A9, # GREEK CAPITAL LETTER OMEGA

Presumably this bug occurred due to a misreading, given
that OHM and OMEGA having the same glyph. Evidence that
the OMEGA interpretation is correct: 

0xBD   0x03A9   # GREEK CAPITAL LETTER OMEGA
-http://www.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ROMAN.TXT

Further evidence can be found by Googling for MacRoman
tables. This bug means that, for example, the following
code gives a UnicodeEncodeError when it shouldn't do: 

>>> u'\u03a9'.encode('macroman')

For a workaround, I've been using the following code: 

>>> import codecs
>>> from encodings import mac_roman
>>> mac_roman.decoding_map[0xBD] = 0x03A9
>>> mac_roman.encoding_map =
codecs.make_encoding_map(mac_roman.decoding_map)

And then, to use the example above: 

>>> u'\u03a9'.encode('macroman')
'\xbd'
>>> 

Thanks,

-- 
Sean B. Palmer


--

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

Message:
Logged In: YES 
user_id=38388

This has been fixed in CVS and Python 2.5 will include the fix. 

A backport is not possible, because we've changed the way
charmap codecs work in 2.5.


--

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



[ python-Bugs-1379994 ] "unicode_escape" and "raw_unicode_escape" encoding is broken

2005-12-16 Thread SourceForge.net
Bugs item #1379994, was opened at 2005-12-14 01:47
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379994&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: Mark Mc Mahon (markmcmahon)
>Assigned to: Hye-Shik Chang (perky)
Summary: "unicode_escape" and "raw_unicode_escape" encoding is broken

Initial Comment:
In Python 2.4.2 and Python 2.4.1 (Windows XP)

>>> "\t\t".encode("string_escape")
'\t\\t'

>>> "\t\t".encode("unicode_escape")
'\t\t'
>>> "\t\t".encode("raw_unicode_escape")
'\t\t'
>>> u"\t\t".encode("unicode_escape")
'\t\t'
>>> u"\t\t".encode("raw_unicode_escape")
'\t\t'

I would have expected all to produce the same result.

Also round-tripping with the encoding doesn't seem to work:
>>> "\t\t".encode('string_escape').decode('string_escape')
'\t\t'
>>>
u"\t\t".encode('unicode_escape').decode('unicode_escape')
u'\t\t'

Thanks
   Mark

--

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

Message:
Logged In: YES 
user_id=38388

Please add a test case and check in the patch.
Thanks.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-15 22:39

Message:
Logged In: YES 
user_id=1188172

Patch looks good.

--

Comment By: Hye-Shik Chang (perky)
Date: 2005-12-14 02:41

Message:
Logged In: YES 
user_id=55188

Attached a patch. It looks like a simple typo. :)

--

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



[ python-Bugs-1382562 ] --install-base not honored on win32

2005-12-16 Thread SourceForge.net
Bugs item #1382562, was opened at 2005-12-16 16:59
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=1382562&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: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: John Ehresman (jpe)
Assigned to: Nobody/Anonymous (nobody)
Summary: --install-base not honored on win32

Initial Comment:
The --install-base options isn't honored on win32
because code in install.finalize_others() in install.py
overwrites the value with either self.home,
self.prefix, or sys.prefix.

I was trying to use --install-base because --prefix
won't accept an absolute path on win32.  Does anyone
know the rationale for rejecting absolute paths on win32?

--

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



[ python-Bugs-1379393 ] StreamReader.readline doesn't advance on decode errors

2005-12-16 Thread SourceForge.net
Bugs item #1379393, was opened at 2005-12-13 11:35
Message generated for change (Comment added) made by doerwalter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379393&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Matthew Mueller (donut)
Assigned to: Walter Dörwald (doerwalter)
Summary: StreamReader.readline doesn't advance on decode errors

Initial Comment:
In previous versions of python, when there was a
unicode decode error, StreamReader.readline() would
advance to the next line.  In the current version(2.4.2
and trunk),  it doesn't.  Testing under Linux AMD64
(Ubuntu 5.10)

Attaching an example script.  In python2.3 it prints:

hi~
hi
error: 'utf8' codec can't decode byte 0x80 in position
2: unexpected code byte
error: 'utf8' codec can't decode byte 0x81 in position
2: unexpected code byte
all done


In python2.4 and trunk it prints:
hi~
hi
error: 'utf8' codec can't decode byte 0x80 in position
0: unexpected code byte
error: 'utf8' codec can't decode byte 0x80 in position
0: unexpected code byte
error: 'utf8' codec can't decode byte 0x80 in position
0: unexpected code byte
[repeats forever]


Maybe this isn't actually supposed to work (the docs
don't mention what should happen with strict error
checking..), but it would be nice, given the alternatives:
1. use errors='replace' and then search the result for
the replacement character. (ick)
2. define a custom error handler similar to ignore or
replace, that also sets some flag. (slightly less ick,
but more work.)


--

>Comment By: Walter Dörwald (doerwalter)
Date: 2005-12-16 18:25

Message:
Logged In: YES 
user_id=89016

IMHO the current behaviour is more consistent. To read the
broken utf-8 stream from the test script the appropriate
error handler should be used. What is the desired outcome?
If only the broken byte sequence should be skipped
errors="replace" is appropriate. To skip a complete line
that contains a broken byte sequence do something like in
the attached skipbadlines.py. The StreamReader can't know
which behaviour is wanted.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-15 22:42

Message:
Logged In: YES 
user_id=1188172

I don't know what should be correct. Walter?

--

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379393&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-1370948 ] Start and end parameters for list.count()

2005-12-16 Thread SourceForge.net
Feature Requests item #1370948, was opened at 2005-12-01 10:12
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1370948&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: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: Christoph Zwerschke (cito)
Assigned to: Nobody/Anonymous (nobody)
Summary: Start and end parameters for list.count()

Initial Comment:
For lists and strings, the index() method has start and
end parameters. For strings, the count() method has
start and end parameters as well. But for lists, the
count() method has no such parameters. I think it may
be a good idea to allow start and end parameters for
count() on lists as well, if only for consistency reasons.

--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-12-16 12:27

Message:
Logged In: YES 
user_id=80475

See discussion for patch 1382087.

--

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



[ python-Bugs-1283289 ] PyArg_ParseTupleAndKeywords gives misleading error message

2005-12-16 Thread SourceForge.net
Bugs item #1283289, was opened at 2005-09-06 21:12
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1283289&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: japierro (japierro)
>Assigned to: Martin v. Löwis (loewis)
Summary: PyArg_ParseTupleAndKeywords gives misleading error message

Initial Comment:
Python 2.3.3 on Windows XP

If the user supplies one valid and one invalid keyword to 
a function that defines two required keyword arguments, 
PyArg_ParseTupleAndKeywords will raise this 
exception:

TypeError: function takes exactly 2 arguments (1 given)

If, in getargs.c, vgetargskeywords, the check 
for "extraneous keywords" were done near the top of the 
function, a more meaningful exception would be thrown:

TypeError: 'bad' is an invalid keyword argument for this 
function


--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-16 20:43

Message:
Logged In: YES 
user_id=1188172

Any opinions?

--

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



[ python-Bugs-1382740 ] len() on class broken

2005-12-16 Thread SourceForge.net
Bugs item #1382740, was opened at 2005-12-16 13:18
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=1382740&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: Open
Resolution: None
Priority: 5
Submitted By: Kevin Quick (kquick)
Assigned to: Nobody/Anonymous (nobody)
Summary: len() on class broken

Initial Comment:
With the following python input:

class A:
@classmethod
def __len__(cls):
return 12

print '1',A.__len__()
print '2',A().__len__()
print '3',len(A())
print '4',len(A)

The output always breaks for '4' with 'TypeError: len 
of unsized object'

Same result for @staticmethod or normal instance method 
declaration.


--

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



[ python-Bugs-1382815 ] len() on class broken

2005-12-16 Thread SourceForge.net
Bugs item #1382815, was opened at 2005-12-16 14:38
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=1382815&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: Open
Resolution: None
Priority: 5
Submitted By: Kevin Quick (kquick)
Assigned to: Nobody/Anonymous (nobody)
Summary: len() on class broken

Initial Comment:
With the following python input:

class A:
@classmethod
def __len__(cls):
return 12

print '1',A.__len__()
print '2',A().__len__()
print '3',len(A())
print '4',len(A)

The output always breaks for '4' with 'TypeError: len 
of unsized object'

Same result for @staticmethod or normal instance method 
declaration.


--

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



[ python-Bugs-1382815 ] len() on class broken

2005-12-16 Thread SourceForge.net
Bugs item #1382815, was opened at 2005-12-16 22:38
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382815&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: Duplicate
Priority: 5
Submitted By: Kevin Quick (kquick)
Assigned to: Nobody/Anonymous (nobody)
Summary: len() on class broken

Initial Comment:
With the following python input:

class A:
@classmethod
def __len__(cls):
return 12

print '1',A.__len__()
print '2',A().__len__()
print '3',len(A())
print '4',len(A)

The output always breaks for '4' with 'TypeError: len 
of unsized object'

Same result for @staticmethod or normal instance method 
declaration.


--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-16 22:40

Message:
Logged In: YES 
user_id=1188172

Duplicate of #1382740.

--

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



[ python-Bugs-1382740 ] len() on class broken

2005-12-16 Thread SourceForge.net
Bugs item #1382740, was opened at 2005-12-16 21:18
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382740&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: Invalid
Priority: 5
Submitted By: Kevin Quick (kquick)
Assigned to: Nobody/Anonymous (nobody)
Summary: len() on class broken

Initial Comment:
With the following python input:

class A:
@classmethod
def __len__(cls):
return 12

print '1',A.__len__()
print '2',A().__len__()
print '3',len(A())
print '4',len(A)

The output always breaks for '4' with 'TypeError: len 
of unsized object'

Same result for @staticmethod or normal instance method 
declaration.


--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-16 22:43

Message:
Logged In: YES 
user_id=1188172

You want to use a metaclass:

class meta(type):
def __len__(cls):
return 12

class B:
__metaclass__ = B

print len(B)

--

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



[ python-Bugs-1382562 ] --install-base not honored on win32

2005-12-16 Thread SourceForge.net
Bugs item #1382562, was opened at 2005-12-16 17:59
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382562&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: Distutils
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: John Ehresman (jpe)
>Assigned to: Martin v. Löwis (loewis)
Summary: --install-base not honored on win32

Initial Comment:
The --install-base options isn't honored on win32
because code in install.finalize_others() in install.py
overwrites the value with either self.home,
self.prefix, or sys.prefix.

I was trying to use --install-base because --prefix
won't accept an absolute path on win32.  Does anyone
know the rationale for rejecting absolute paths on win32?

--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-16 22:47

Message:
Logged In: YES 
user_id=1188172

Martin, I think you are the Windows-install-guru...

--

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



[ python-Bugs-1355883 ] make depend/clean issues w/ ast

2005-12-16 Thread SourceForge.net
Bugs item #1355883, was opened at 2005-11-13 14:27
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1355883&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: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Skip Montanaro (montanaro)
Assigned to: Nobody/Anonymous (nobody)
Summary: make depend/clean issues w/ ast

Initial Comment:
I noticed two issues with the ast vis a vis building and
cleaning.  Haven't had a chance to look into them,
however...

1.  From a fresh checkout, execute configure, then
"make -j2".  It will run Parser/asdl_c.py twice
simultaneously.  This can obviously lead to
corrupt Python-ast.[ch] files.

2. Neither "make clean" nor "make distclean" delete
the Python-ast.[ch] files.  "make distclean" at least
should.  


--

>Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-16 22:49

Message:
Logged In: YES 
user_id=1188172

Is that still an issue?

--

Comment By: Thomas Lee (krumms)
Date: 2005-11-13 17:58

Message:
Logged In: YES 
user_id=315535

Fix for part 1 here:
http://sourceforge.net/tracker/index.php?func=detail&aid=1355971&group_id=5470&atid=305470


--

Comment By: Thomas Lee (krumms)
Date: 2005-11-13 17:45

Message:
Logged In: YES 
user_id=315535

Already on it :) Shall have a patch up shortly.

--

Comment By: Skip Montanaro (montanaro)
Date: 2005-11-13 17:44

Message:
Logged In: YES 
user_id=44345

I was thinking it might be something like that.  Perhaps asdl_c.py
should be modified to accept an output flag (--output=[hc] or -h/-c)
so it only generates one file or the other.


--

Comment By: Thomas Lee (krumms)
Date: 2005-11-13 17:24

Message:
Logged In: YES 
user_id=315535

The first problem is being caused by a simple
misunderstanding/oversight in Makefile.pre.in.

The rule for a target will be called for each target. In our
case, we have Python-ast.h and Python-ast.c in our list of
targets. So asdl_c.py gets called once for each target.

Hope this makes sense. :)

If not I can bang up a patch so you can at least see what
I'm on about.

--

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



[ python-Bugs-1381939 ] cElementTree only supports a few encodings

2005-12-16 Thread SourceForge.net
Bugs item #1381939, was opened at 2005-12-15 22:15
Message generated for change (Settings changed) made by effbot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1381939&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: XML
Group: Python 2.5
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Fredrik Lundh (effbot)
Assigned to: Fredrik Lundh (effbot)
Summary: cElementTree only supports a few encodings

Initial Comment:
The cElementTree driver only supports a small number 
of XML encodings compared to ElementTree (and other 
pyexpat-based tools).  This would be nice if this was 
fixed before 2.5 final.

In the meantime, a workaround can be found here:

http://effbot.org/zone/celementtree-encoding.htm

--

>Comment By: Fredrik Lundh (effbot)
Date: 2005-12-16 23:09

Message:
Logged In: YES 
user_id=38376

Fixed in revision 41724

--

Comment By: Fredrik Lundh (effbot)
Date: 2005-12-16 00:07

Message:
Logged In: YES 
user_id=38376

I've attached the relevant patch from CET 1.0.5 (in 
progress)

--

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



[ python-Bugs-1382740 ] len() on class broken

2005-12-16 Thread SourceForge.net
Bugs item #1382740, was opened at 2005-12-16 13:18
Message generated for change (Settings changed) made by kquick
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382740&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: Open
Resolution: Invalid
Priority: 5
Submitted By: Kevin Quick (kquick)
Assigned to: Nobody/Anonymous (nobody)
Summary: len() on class broken

Initial Comment:
With the following python input:

class A:
@classmethod
def __len__(cls):
return 12

print '1',A.__len__()
print '2',A().__len__()
print '3',len(A())
print '4',len(A)

The output always breaks for '4' with 'TypeError: len 
of unsized object'

Same result for @staticmethod or normal instance method 
declaration.


--

>Comment By: Kevin Quick (kquick)
Date: 2005-12-16 15:52

Message:
Logged In: YES 
user_id=6133

That would indeed solve '4', but has a non-orthogonality of 
attribute propagation that I don't understand and which 
seems inconsistent.

In my original:
  '1' demonstrates that __len__ is indeed in the dictionary
  for the class.
  '2' shows the expected attribute propagation effects: if
  at attribute is not found in the instance dictionary,
  the class dictionary is checked.
  '3' shows that len is implemented (generally) by looking
  for a __len__ method on the object in question.
  '4' confuses me, because it means that '3' isn't quite
  correct...

With your metaclass solution (using "__metaclass__ = meta" 
:) it does indeed make '4' work, and '1', but '2' and '3' 
now do not work, showing that instance-->class propagation
does not follow instance-->class-->metaclass.  Or something
...

Approaching this a different way:

My understanding of @classmethod (or perhaps more properly
@staticmethod) is that it allows "constant" methods that are
independent of the particular object instance.  So if I had:

class C:
  @staticmethod
  def f(): return 1

then both C.f() and C().f() are valid and return 1.

Why the len() translation to __len__ works *differently*
is strange.  I'm still defining a method, just one that
I want Python to use for any len(A) or len(A()) refs,
translating those to A.__len__() or A().__len__() and using 
those just as for C and f, respectively.


--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-16 14:43

Message:
Logged In: YES 
user_id=1188172

You want to use a metaclass:

class meta(type):
def __len__(cls):
return 12

class B:
__metaclass__ = B

print len(B)

--

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



[ python-Bugs-1382740 ] len() on class broken

2005-12-16 Thread SourceForge.net
Bugs item #1382740, was opened at 2005-12-16 15:18
Message generated for change (Comment added) made by rhettinger
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1382740&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: Open
>Resolution: None
Priority: 5
Submitted By: Kevin Quick (kquick)
>Assigned to: Guido van Rossum (gvanrossum)
Summary: len() on class broken

Initial Comment:
With the following python input:

class A:
@classmethod
def __len__(cls):
return 12

print '1',A.__len__()
print '2',A().__len__()
print '3',len(A())
print '4',len(A)

The output always breaks for '4' with 'TypeError: len 
of unsized object'

Same result for @staticmethod or normal instance method 
declaration.


--

>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-12-16 23:40

Message:
Logged In: YES 
user_id=80475

Guido, this issue arises throughout the language in various
guises (for instance, it applies to __neg__ as well as
__len__).  It comes-up whenever built-in functions or
operators bypass attribute lookup in favor of direct slot
access.  

Much of the code in abstract.c is in the form:

   def PyObject_SomeFunc(o):
if slots.somefunc is not None:
return slots.somefunc(o)
raise TypeError

If we cared about this (and I'm not sure we do), the
solution is to make the abstract.c functions smarter:

   def PyObject_SomeFunc(o):
if slots.somefunc is not None:
return slots.somefunc(o)
try:
f = gettattr(o, 'somefunc')
except AttributeError:
raise TypeError
else:
return f()

The advantage of the change is restoring the symmetry
between len(o) and o.__len__() where the method definition
is available via attribute lookup but not via a slot.  The
thought is to keep the speedy access as default, but if that
fails, then do a normal attribute lookup before barfing back
an error message.  This is precedent for this solution
elsewhere in the codebase (though I don't remember where at
the moment).  OTOH, I'm not sure we care.





 pervades the code in abstract.c which is in the form:

   def PyObject_Size

--

Comment By: Kevin Quick (kquick)
Date: 2005-12-16 17:52

Message:
Logged In: YES 
user_id=6133

That would indeed solve '4', but has a non-orthogonality of 
attribute propagation that I don't understand and which 
seems inconsistent.

In my original:
  '1' demonstrates that __len__ is indeed in the dictionary
  for the class.
  '2' shows the expected attribute propagation effects: if
  at attribute is not found in the instance dictionary,
  the class dictionary is checked.
  '3' shows that len is implemented (generally) by looking
  for a __len__ method on the object in question.
  '4' confuses me, because it means that '3' isn't quite
  correct...

With your metaclass solution (using "__metaclass__ = meta" 
:) it does indeed make '4' work, and '1', but '2' and '3' 
now do not work, showing that instance-->class propagation
does not follow instance-->class-->metaclass.  Or something
...

Approaching this a different way:

My understanding of @classmethod (or perhaps more properly
@staticmethod) is that it allows "constant" methods that are
independent of the particular object instance.  So if I had:

class C:
  @staticmethod
  def f(): return 1

then both C.f() and C().f() are valid and return 1.

Why the len() translation to __len__ works *differently*
is strange.  I'm still defining a method, just one that
I want Python to use for any len(A) or len(A()) refs,
translating those to A.__len__() or A().__len__() and using 
those just as for C and f, respectively.


--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-16 16:43

Message:
Logged In: YES 
user_id=1188172

You want to use a metaclass:

class meta(type):
def __len__(cls):
return 12

class B:
__metaclass__ = B

print len(B)

--

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



[ python-Bugs-1379994 ] "unicode_escape" and "raw_unicode_escape" encoding is broken

2005-12-16 Thread SourceForge.net
Bugs item #1379994, was opened at 2005-12-14 09:47
Message generated for change (Settings changed) made by perky
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379994&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: Mark Mc Mahon (markmcmahon)
Assigned to: Hye-Shik Chang (perky)
Summary: "unicode_escape" and "raw_unicode_escape" encoding is broken

Initial Comment:
In Python 2.4.2 and Python 2.4.1 (Windows XP)

>>> "\t\\t".encode("string_escape")
'\\tt'

>>> "\t\\t".encode("unicode_escape")
'\\t\\t'
>>> "\t\\t".encode("raw_unicode_escape")
'\t\\t'
>>> u"\t\\t".encode("unicode_escape")
'\\t\\t'
>>> u"\t\\t".encode("raw_unicode_escape")
'\t\\t'

I would have expected all to produce the same result.

Also round-tripping with the encoding doesn't seem to work:
>>> "\t\\t".encode('string_escape').decode('string_escape')
'\t\\t'
>>>
u"\t\\t".encode('unicode_escape').decode('unicode_escape')
u'\t\t'

Thanks
   Mark

--

>Comment By: Hye-Shik Chang (perky)
Date: 2005-12-17 13:39

Message:
Logged In: YES 
user_id=55188

Committed as r41728. Thank you!

--

Comment By: M.-A. Lemburg (lemburg)
Date: 2005-12-17 00:01

Message:
Logged In: YES 
user_id=38388

Please add a test case and check in the patch.
Thanks.

--

Comment By: Reinhold Birkenfeld (birkenfeld)
Date: 2005-12-16 06:39

Message:
Logged In: YES 
user_id=1188172

Patch looks good.

--

Comment By: Hye-Shik Chang (perky)
Date: 2005-12-14 10:41

Message:
Logged In: YES 
user_id=55188

Attached a patch. It looks like a simple typo. :)

--

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