Re: [Python-Dev] PEP 383 update: utf8b is now the error handler

[Walter Dörwald]

Stephen J. Turnbull wrote:
> Walter Dörwald writes:
> 
>  > "surrogatepass" (for the "don't complain about lone half surrogates"
>  > handler) and "surrogatereplace" sound OK to me. However the other
>  > "...replace" handlers are destructive (i.e. when such a "...replace"
>  > handler is used for encoding, decoding will not produce the original
>  > unicode string).
> 
> That doesn't bother me in the slightest.  "Replace" does not connote
> "destructive" or "non-destructive" to me; it connotes "substitution".
> The fact that other error handlers happen to be destructive doesn't
> affect that at all for me.  YMMV.
> 
>  > The purpose of the PEP 383 error handler however is to be roundtrip
>  > safe, so maybe we should choose a slightly different name?  How
>  > about "surrogateescape"?
> 
> To me, "escape" has a strong connotation of a multicharacter
> representation of a single character, and that's not true here.
> 
> How about "surrogatetranslate"?  I still prefer "surrogatereplace", as
> it's slightly easier for me to type.

I like "surrogatetranslate" better than "surrogateescape" better than
"surrogatereplace".

But I'll stop bikesheding now and let Martin decide.

Servus,
   alter


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] py3k build broken

[David Cournapeau]

On Fri, May 8, 2009 at 7:23 AM, Tarek Ziadé  wrote:

> I have fixed configure by runing autoconf, everything should be fine now
>
> Sorry for the inconvenience.

I am the one responsible for this - I did not realize that the
generated configure/Makefile were also in the trunk, and my patch did
not include the generated files. My apologies,

cheers,

David
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] feature request 5804

[Kristján Valur Jónsson]

Hello there.  I have sumitted the following patch:
Add an 'offset' argument to zlib.decompress
http://bugs.python.org/issue5804

I'd be interested on getting some more feedback on it.

Kristján
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (05/01/09 - 05/08/09)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue 
number.  Do NOT respond to this message.


 2188 open (+45) / 15604 closed (+30) / 17792 total (+75)

Open issues with patches:   848

Average duration of open issues: 646 days.
Median duration of open issues: 396 days.

Open Issues Breakdown
   open  2153 (+45)
pending34 ( +0)

Issues Created Or Reopened (75)
___

socketmodule.c  on HPUX ia64 without _XOPEN_SOURCE_EXTENDED comp 05/01/09
   http://bugs.python.org/issue5895created  ntai
  
   

timeit documentation 05/01/09
   http://bugs.python.org/issue5896created  hrfeels 
  
   

No library reference tree in chm help file   05/01/09
CLOSED http://bugs.python.org/issue5897created  suraj   
  
   

Hang in Popen.wait() when another process has been created   05/01/09
   http://bugs.python.org/issue5898created  farialima   
  
   

test_capi crashes when called more than once 05/01/09
CLOSED http://bugs.python.org/issue5899created  pitrou  
  
   

Ensure RUNPATH is added to extension modules with RPATH if GNU l 05/01/09
   http://bugs.python.org/issue5900created  flub
  
   patch   

missing meta-info in documentation pdf   05/02/09
   http://bugs.python.org/issue5901created  ZeD 
  
   

Stricter codec names 05/02/09
   http://bugs.python.org/issue5902created  ezio.melotti
  
   

strftime fails in non UTF-8 locale   05/02/09
   http://bugs.python.org/issue5903created  barry-scott 
  
   

strftime docs do not explain locale affect on result string  05/02/09
   http://bugs.python.org/issue5904created  barry-scott 
  
   

strptime fails in non-UTF locale 05/02/09
   http://bugs.python.org/issue5905created  pitrou  
  
   

Risk of confusion in multiprocessing module - daemonic processes 05/02/09
   http://bugs.python.org/issue5906created  pakal   
  
   

repr of time.struct_time type does not eval  05/02/09
   http://bugs.python.org/issue5907created  jwm 
  
   

I need to import the module in the same thread   05/02/09
   http://bugs.python.org/issue5908created  tyoc
  
   

Segfault in typeobject.c 05/02/09
CLOSED http://bugs.python.org/issue5909created  gbritton
  
   

kqueue for more than one event is broken.05/02/09
   http://bugs.python.org/issue5910created  Erik Gorset 
  
   patch   

built-in compile() should take encoding option.  05/03/09
   http://bugs.python.org/issue5911created  naoki   
  
   

import deadlocks when using fork 05/03/09
   http://bugs.python.org/issue5912created  abaron  
  
   

On Windows os.listdir('') -> cwd and os.listdir(u'') -> C:\  05/03/09
CLOSED http://bugs.python.org/issue5913created  ezio.melotti
  
   patch 

Re: [Python-Dev] Easy way to detect filesystem case-sensitivity?

[Brett Cannon]

On Thu, May 7, 2009 at 18:56, John Arbash Meinel <
john.arbash.mei...@gmail.com> wrote:

> Andrew Bennetts wrote:
> > Antoine Pitrou wrote:
> >> Robert Kern  gmail.com> writes:
> >>> Since one may have more than one filesystem side-by-side, this can't be
> just
> >> be
> >>> a system-wide boolean somewhere. One would have to query the target
> directory
> >>> for this information. I am not aware of the existence of code that does
> such
> >> a
> >>> query, though.
> >> Or you can just be practical and test for it. Create a file "foobar" and
> see if
> >> you can open "FOOBAR" in read mode...
> >
> > Agreed.  That is how Bazaar's test suite detects this, and it works well.
> >
> > -Andrew.
>
>
> Actually, I believe we do:
>
> open('format', 'wb').close()
> try:
>  os.lstat('FoRmAt')
> except IOError, e:
>  if e.errno == errno.ENOENT:
>   ...
>
> I don't know that it really matters, just wanted to indicate we use
> 'lstat' rather than 'open()' to check. I could be wrong about the test
> suite, but I know that is what we do for 'live' files. (We always create
> a format file, so we know it is there to 'stat' it via a different name.)


Thanks for the help to everyone. I ended up simply taking __file__, making
it all uppercase (or lowercase if it is already uppercase) and then doing
os.path.exists() on the modified name. Seems to work.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Easy way to detect filesystem case-sensitivity?

[MRAB]

Brett Cannon wrote:



On Thu, May 7, 2009 at 18:56, John Arbash Meinel 
mailto:john.arbash.mei...@gmail.com>> wrote:


Andrew Bennetts wrote:
 > Antoine Pitrou wrote:
 >> Robert Kern  gmail.com > writes:
 >>> Since one may have more than one filesystem side-by-side, this
can't be just
 >> be
 >>> a system-wide boolean somewhere. One would have to query the
target directory
 >>> for this information. I am not aware of the existence of code
that does such
 >> a
 >>> query, though.
 >> Or you can just be practical and test for it. Create a file
"foobar" and see if
 >> you can open "FOOBAR" in read mode...
 >
 > Agreed.  That is how Bazaar's test suite detects this, and it
works well.
 >
 > -Andrew.


Actually, I believe we do:

open('format', 'wb').close()
try:
 os.lstat('FoRmAt')
except IOError, e:
 if e.errno == errno.ENOENT:
  ...

I don't know that it really matters, just wanted to indicate we use
'lstat' rather than 'open()' to check. I could be wrong about the test
suite, but I know that is what we do for 'live' files. (We always create
a format file, so we know it is there to 'stat' it via a different
name.)


Thanks for the help to everyone. I ended up simply taking __file__, 
making it all uppercase (or lowercase if it is already uppercase) and 
then doing os.path.exists() on the modified name. Seems to work.



Alternatively, use swapcase() and then os.path.exists().
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Easy way to detect filesystem case-sensitivity?

[Oleg Broytmann]

On Fri, May 08, 2009 at 09:52:40AM -0700, Brett Cannon wrote:
> Thanks for the help to everyone. I ended up simply taking __file__, making
> it all uppercase (or lowercase if it is already uppercase) and then doing
> os.path.exists() on the modified name. Seems to work.

   What if __file__ is on a different filesystem with different rules
(consider NFS, SMB/CIFS, etc.)?

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/p...@phd.pp.ru
   Programmers don't die, they just GOSUB without RETURN.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

[Casey Duncan]

On May 4, 2009, at 3:10 AM, Larry Hastings wrote:



I should have brought this up to python-dev before--sorry for being  
so slow.  It's already in the tracker for a couple of days:


  http://bugs.python.org/issue5880

The idea: PyGetSetDef has this "void *closure" field that acts like  
a context pointer.  You stick it in the PyGetSetDef, and it gets  
passed back to you when your getter or setter is called.  It's a  
reasonable API design, but in practice you almost never need it.   
Meanwhile, it clutters up CPython, particularly typeobject.c; there  
are all these function calls that end with ", NULL);", just to  
satisfy the getter/setter prototype internally.


I think this is an important feature, which allows you to define  
generic, reusable getter and setter functions and pass static metadata  
to them at runtime. Admittedly I have never needed the full pointer,  
my typical usage is to pass in an offset.


I think this should only be removed if a suitable mechanism replaces  
it, if not it will require some needless duplication of code in  
extensions that use it (in particular my own) 8^)


-Casey
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] special method lookup: how much do we care?

[Benjamin Peterson]

A while ago, Guido declared that all special method lookups on
new-style classes bypass __getattr__ and __getattribute__. This almost
completely consistent now, and I've been working on patching up a few
incorrect cases. I've know hit __enter__ and __exit__. The compiler
generates LOAD_ATTR instructions for these, so it uses the normal
lookup. The only way I can see to fix this is add a new opcode which
uses _PyObject_LookupSpecial, but I don't think we really care this
much. Opinions?

-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Proposed: drop unnecessary "context" pointer from PyGetSetDef

[Larry Hastings]

Casey Duncan wrote:
I think this is an important feature, which allows you to define 
generic, reusable getter and setter functions and pass static metadata 
to them at runtime. Admittedly I have never needed the full pointer, 
my typical usage is to pass in an offset.


I think this should only be removed if a suitable mechanism replaces 
it, if not it will require some needless duplication of code in 
extensions that use it (in particular my own) 8^)


I disagree; I think it is a minor convenience feature, and one which 
encourages a lack of type safety.


A suitable replacement mechanism already exists in C:

   static PyObject *generic_getter(PyObject *o, int context) {
   /* your generic code goes here */
   }

   static PyObject *getter_with_context_1(o) { return generic_getter(o,
   1); }
   static PyObject *getter_with_context_2(o) { return generic_getter(o,
   2); }
   static PyObject *getter_with_context_3(o) { return generic_getter(o,
   3); }

You would then use "getter_with_context_1" &c in your PyGetSetDef.  With 
a clever optimizing compiler this should result in no detectable 
slowdown or code bloat.


However, you will be happy to learn there wasn't much support for this 
change, so it didn't make it into Python 3.1.



/larry/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] special method lookup: how much do we care?

[Terry Reedy]

Benjamin Peterson wrote:

A while ago, Guido declared that all special method lookups on
new-style classes bypass __getattr__ and __getattribute__. This almost
completely consistent now, and I've been working on patching up a few
incorrect cases. I've know hit __enter__ and __exit__. The compiler
generates LOAD_ATTR instructions for these, so it uses the normal
lookup. The only way I can see to fix this is add a new opcode which
uses _PyObject_LookupSpecial, but I don't think we really care this
much. Opinions?


1.More consistent attribute lookup is, to me, a feature of 3.x and I 
appreciate you working on this.
2. I am puzzled why those two methods should be extra special, but don't 
know enough to say more.
3. If there are only those two or a couple of other exceptions, I'd like 
them listed in the 'Special method lookup' ref doc section.


tjr


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] special method lookup: how much do we care?

[Benjamin Peterson]

2009/5/8 Terry Reedy :
> 2. I am puzzled why those two methods should be extra special, but don't
> know enough to say more.

They're not supposed to be special, which is the reason for this
message. :) Currently the interpreter will call __getattr__ when
looking them up. This is not the way it should be.




-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] special method lookup: how much do we care?

[Daniel Stutzbach]

On Fri, May 8, 2009 at 1:09 PM, Benjamin Peterson wrote:

> I've know hit __enter__ and __exit__. The compiler
> generates LOAD_ATTR instructions for these, so it uses the normal
> lookup. The only way I can see to fix this is add a new opcode which
> uses _PyObject_LookupSpecial, but I don't think we really care this
> much. Opinions?
>

Why does this problem arise only with __enter__ and __exit__?

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] special method lookup: how much do we care?

[Benjamin Peterson]

2009/5/8 Daniel Stutzbach :
> On Fri, May 8, 2009 at 1:09 PM, Benjamin Peterson 
> wrote:
>>
>> I've know hit __enter__ and __exit__. The compiler
>> generates LOAD_ATTR instructions for these, so it uses the normal
>> lookup. The only way I can see to fix this is add a new opcode which
>> uses _PyObject_LookupSpecial, but I don't think we really care this
>> much. Opinions?
>
> Why does this problem arise only with __enter__ and __exit__?

Normally special methods use slots of the PyTypeObject struct.
typeobject.c looks up all those methods on Python classes correctly.
In the case of __enter__ and __exit__, the compiler generates bytecode
to look them up, and that bytecode use PyObject_Getattr.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] special method lookup: how much do we care?

[Daniel Stutzbach]

On Fri, May 8, 2009 at 6:14 PM, Benjamin Peterson wrote:

> Normally special methods use slots of the PyTypeObject struct.
> typeobject.c looks up all those methods on Python classes correctly.
> In the case of __enter__ and __exit__, the compiler generates bytecode
> to look them up, and that bytecode use PyObject_Getattr.


Would this problem apply to all special methods that don't use a slot in
PyTypeObject, then?  I know of several other examples:

__reduce__
__setstate__
__reversed__
__length_hint__
__sizeof__

(unless I misunderstand the definition of "special methods", which is
possible)

--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] special method lookup: how much do we care?

[Benjamin Peterson]

2009/5/8 Daniel Stutzbach :
> On Fri, May 8, 2009 at 6:14 PM, Benjamin Peterson 
> wrote:
>>
>> Normally special methods use slots of the PyTypeObject struct.
>> typeobject.c looks up all those methods on Python classes correctly.
>> In the case of __enter__ and __exit__, the compiler generates bytecode
>> to look them up, and that bytecode use PyObject_Getattr.
>
> Would this problem apply to all special methods that don't use a slot in
> PyTypeObject, then?  I know of several other examples:

Yes. I didn't think of those.

>
> __reduce__
> __setstate__
> __reversed__
> __length_hint__
> __sizeof__
>
> (unless I misunderstand the definition of "special methods", which is
> possible)



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] special method lookup: how much do we care?

[Terry Reedy]

Benjamin Peterson wrote:

2009/5/8 Terry Reedy :

2. I am puzzled why those two methods should be extra special, but don't
know enough to say more.


They're not supposed to be special, which is the reason for this
message. :) Currently the interpreter will call __getattr__ when
looking them up. This is not the way it should be.


I was trying to ask the same question as Daniel did more clearly, and 
which you answered: they are special special methods because they are 
not in the PyTypeObject struct like the other special (name) methods. 
And that, I presume, is because they are specific to context manager 
objects, while all other 'special' methods (that I notice in 'Special 
method names') are more general in being applicable to multiple types.


Since built-in functions are compiled to load_global, call_function and 
operations to various special op codes, I could imagine that .__enter__ 
and .__exit__ are currently the only implicitly invoked special names 
that explicitly appear in code objects. I can see why you ask before 
burning an opcode (with parameter) to avoid that.


There are two issues: 1) bypass instance lookup; 2) bypass 
.__getattribute__() calling.  I presume you have or can do at least the 
first with a custom .__getattribute__ method.


Terry Jan Reedy





___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] special method lookup: how much do we care?

[Terry Reedy]

Benjamin Peterson wrote:

2009/5/8 Daniel Stutzbach :

On Fri, May 8, 2009 at 6:14 PM, Benjamin Peterson 
wrote:

Normally special methods use slots of the PyTypeObject struct.
typeobject.c looks up all those methods on Python classes correctly.
In the case of __enter__ and __exit__, the compiler generates bytecode
to look them up, and that bytecode use PyObject_Getattr.

Would this problem apply to all special methods that don't use a slot in
PyTypeObject, then?  I know of several other examples:


Yes. I didn't think of those.


__reduce__
__setstate__
__reversed__
__length_hint__
__sizeof__

(unless I misunderstand the definition of "special methods", which is
possible)


__reversed__, at least, is called by the reversed() builtin, so there is 
no LOAD_ATTR k (__reversed__) byte code.  So for that, the problem is 
reduced to accessing type(it).__reversed__ without going thru 
type(it).__getattribute__.  I would think that a function that did that 
would work for the others on the list (all 4?) that also have no 
LOAD_ATTR bytecode.  Would a modified version of object.__getattribute__ 
work?


tjr

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] special method lookup: how much do we care?

[Benjamin Peterson]

2009/5/8 Terry Reedy :
> Benjamin Peterson wrote:
>>
>> 2009/5/8 Daniel Stutzbach :
>>>
>>> On Fri, May 8, 2009 at 6:14 PM, Benjamin Peterson 
>>> wrote:

 Normally special methods use slots of the PyTypeObject struct.
 typeobject.c looks up all those methods on Python classes correctly.
 In the case of __enter__ and __exit__, the compiler generates bytecode
 to look them up, and that bytecode use PyObject_Getattr.
>>>
>>> Would this problem apply to all special methods that don't use a slot in
>>> PyTypeObject, then?  I know of several other examples:
>>
>> Yes. I didn't think of those.
>>
>>> __reduce__
>>> __setstate__
>>> __reversed__
>>> __length_hint__
>>> __sizeof__
>>>
>>> (unless I misunderstand the definition of "special methods", which is
>>> possible)
>
> __reversed__, at least, is called by the reversed() builtin, so there is no
> LOAD_ATTR k (__reversed__) byte code.  So for that, the problem is reduced
> to accessing type(it).__reversed__ without going thru
> type(it).__getattribute__.  I would think that a function that did that
> would work for the others on the list (all 4?) that also have no LOAD_ATTR
> bytecode.  Would a modified version of object.__getattribute__ work?

No, it's easier to just use _PyObject_LookupSpecial there.



-- 
Regards,
Benjamin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] special method lookup: how much do we care?

[Terry Reedy]

Benjamin Peterson wrote:


__reduce__
__setstate__
__reversed__
__length_hint__
__sizeof__



No, it's easier to just use _PyObject_LookupSpecial there.


Does that mean that the above 5 'work correctly' (or can easily be made 
to do so)?  Leaving just __entry__ and __exit__ as problems?


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com