Mailman 3 May 2003 - Python-Dev

Re: __slots__ and default values
by Michael Chermside May 14, 2003

May 14, 2003

Raymond Hettinger wrote: > class Pane(object): > __slots__ = ('background', 'foreground', 'size', 'content') > background = 'black' > foreground = 'white' > size = (80, 25) ...which doesn't work since the class variable overwrites the __slots__ descriptor. Aahz replies: > Why not do the initializing in __init__? I presume that Raymond's concern was not that there wouldn't be a way to do initialization, but that this would become a new c.l.p FAQ and point of confusion for newbies. Unfortunately, I fear that it will. Already I am seeing that people are "discovering" class variables as a sort of "initialized instance variable" instead of using __init__ as they "ought" to. Of course, it's NOT an initialized instance variable, but newbies stumble across it and seem to prefer it to using __init__. Combine this with the fact that newbies from staticly typed languages tend to think of __slots__ as "practically mandatory" (because it prevents the use of instance variables not pre-declared, which they erroniously think is a good thing) rather than the special purpose performance hack that it REALLY is, and you have a recipe for trouble. I'm not quite sure how to present things so as to steer them right, but there's definitely a potential pitfall here. -- Michael Chermside

4 5

Inplace multiply
by Paul Dubois May 14, 2003

May 14, 2003

My "masked array" class MA has a problem that I don't know how to solve. The inplace multiply function def __imul__ (self, other) is not getting called while my other input operations do work. The scenario is x = MA.array(...) x *= c If c is an int, this works correctly, calling MA.__imul__. Otherwise, I get a message from the Python runtime saying it can't multiply a sequence by a non-int. But change MA to Numeric, it works. Numeric is an extension type and MA is a (new style) class. MA defines __len__ as well as all the math operators.

5 5

RE: [Python-Dev] __slots__ and default values
by Delaney, Timothy C (Timothy) May 13, 2003

May 13, 2003

> From: Guido van Rossum [mailto:guido@python.org] > > > I would prefer to think of this is a useful feature rather than a > > wart. Finally we can have true constants! > > Yuck. If you want that, define a property-like class that doesn't > allow setting. > > These "constants" of yours are easily subverted by defining a subclass > which adds an instance __dict__ (any subclass that doesn't define > __slots__ of its own does this). Sorry - missing smiley there ;) But see my other post for a potentially useful side-effect of this. Not something I think should be done, but fun to think about. The idea is that you shouldn't be able to create a subclass without some really nasty work, as the only way to get it is to determine what module the module subclass is defined in, then grab the class out of that. But it's a horrible hack and I should never have suggested it ;) Tim Delaney

1 0

RE: [Python-Dev] __slots__ and default values
by Delaney, Timothy C (Timothy) May 13, 2003

May 13, 2003

> From: Delaney, Timothy C (Timothy) > > class Pane (module): # Or whatever - you get the idea ;) > > __slots__ = ('background', 'foreground', 'size', > 'content', '__name__', '__file__') > __name__ = globals()['__name__'] > __file__ = globals()['__file__'] > > background = 'black' > foreground = 'white' > size = (80, 25) > > import sys > sys.modules[__name__] = Pane() Hmm ... I was just wondering if we could use this technique to gain the advantages of fast lookup in other modules automatically (but optionally). The idea is, the last line of your module includes a call which transforms your module into a module subclass instance with slots. The functions in the module become methods which access the *class* instance variables (so they can modify them) but other modules can't. A fair bit of work, and probably not worthwhile, but it's interesting to think about ;) Tim Delaney

1 0

RE: [Python-Dev] __slots__ and default values
by Delaney, Timothy C (Timothy) May 13, 2003

May 13, 2003

> From: Raymond Hettinger [mailto:raymond.hettinger@verizon.net] > > class Pane(object): > __slots__ = ('background', 'foreground', 'size', 'content') > background = 'black' > foreground = 'white' > size = (80, 25) > > p = Pane() > p.background = 'light blue' # override the default > assert p.foreground == 'white' # other defaults still in-place Wow - I hadn't realised that. I would prefer to think of this is a useful feature rather than a wart. Finally we can have true constants! class Pane (module): # Or whatever - you get the idea ;) __slots__ = ('background', 'foreground', 'size', 'content', '__name__', '__file__') __name__ = globals()['__name__'] __file__ = globals()['__file__'] background = 'black' foreground = 'white' size = (80, 25) import sys sys.modules[__name__] = Pane() OK - so you could get around it by getting the class of the "module" and then modifying that ... but it's the best yet. It even tells you that the attribute is read-only! Tim Delaney

2 1

Python 2.3b1 _XOPEN_SOURCE value from configure.in
by Harri Pasanen May 13, 2003

May 13, 2003

Seems that Python 2.3b1 hardcodes the value of XOPEN_SOURCE to 600 on Solaris. In configure in: if test $define_xopen_source = yes then AC_DEFINE(_XOPEN_SOURCE, 600, Define to the level of X/Open that your system supports) Now the correct value for Solaris 2.7 in our case is 500, which is defined in the system headers, and boost config picks up the correct value. So when compiling boost-python, there are zillion warning messages about redefinition of _XOPEN_SOURCE. Is this a problem people are aware of, and is someone fixing it as I write, or is a volunteer needed? -Harri

3 3

Re: [Python-Dev] os.path.walk() lacks 'depth first' option
by Mark Russell May 13, 2003

May 13, 2003

>How about this patch? Thanks - I tried that with my script and it worked nicely. Hopefully this is as complex as os.walk() needs to get. Mark

1 0

Need some patches checked
by Brett C. May 13, 2003

May 13, 2003

Since I am trying to tackle patches that were not written by me for the first time I need someone to check that I am doing the right thing. http://www.python.org/sf/649742 is a patch to make adding headers to urllib2's Request object have consistent case. I cleaned up the patch and everything seems reasonable and I don't see how doing this will hurt backwards-compatibilty short of code that tried to add multiple headers of the same name with different case which is not legal anyway for HTTP. http://www.python.org/sf/639139 is a patch wanting to remove an isinstance assertion. Raymond initially suggested weakening the assertion to doing attribute checks. I personally see no reason we can't just take the check out entirely since the code does not appear to have any place where it will mask an AttributeError exception and the comment for the assert says it is just for checking the interface. But since Raymond initially wanted to go another direction I need someone to step in and give me some advice (or Raymond can look at it again; patch is old). -Brett

3 3

RE: [Python-Dev] os.path.walk() lacks 'depth first' option
by Delaney, Timothy C (Timothy) May 13, 2003

May 13, 2003

> From: Guido van Rossum [mailto:guido@python.org] > > OTOH there's something to say for fewer errors, not more; > e.g. sometimes I wish AttributeError and TypeError were unified, > because AttributeError usually means that an object isn't of the > expected type. Hmm ... I was going to ask if there was any reason not to make AttributeError a subclass of TypeError, but that would mean that code like: try: ... except TypeError: ... would also catch all AttributeErrors. Maybe we should have a __future__ directive and phase it in starting in 2.4? I wouldn't suggest making AttributeError and TypeError be synonyms though ... I think it is useful to distinguish the situations. I can't think of any case in *my* code where I would want to distinguish between a TypeError and an AttributeError - usually I end up having: try: ... except (TypeError, AttributeError): ... Tim Delaney

3 2

Re: [Python-Dev] os.path.walk() lacks 'depth first' option
by Walter Dörwald May 13, 2003

May 13, 2003

Guido van Rossum wrote: >> I like the increased flexibility. But how about the following >> version? > > > I don't think there's any need for such increased flexibility. Let's > stop while we're ahead. Fixing the silent errors case is important > (see various posts here). Your generalization is a YAGNI though. True, getting a list of files in the current directory even works with the current os.walk: sum([[os.path.join(x[0], f) for f in x[2]] for x in os.walk(".")], []) Bye, Walter Dörwald

2 1