Mailman 3 May 2001 - Python-Dev

[noreply@sourceforge.net: [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn]
by Luke Kenneth Casson Leighton 04 May '01

04 May '01

hi there, i thought it best to bring this to someone's attention. the forkingmixin code keeps track of its children, plus because it forks, there's no close_requests() to interfere with the operation of the child etc. etc. now, for some marginally bizarre reason, adding an extra base class - BaseServer - has, i believe (without proof, just a hunch), caused a bug in ThreadingMixIn to be more likely to occur. now, i wrote BaseServer in order to be able to overload this for a server that reads from a SQL server table and performs actions based on what it reads from there (the name of a host and the name of a python script to action on the host, from the database :) :) ... but i don't do threading. python is my first actual exposure to thread programming. does anyone have enough experience with threads to write something in less lines and less time than this message? all best, luke ----- Forwarded message from noreply(a)sourceforge.net ----- Delivered-To: lkcl(a)angua.rince.de Delivered-To: lkcl(a)samba.org To: noreply(a)sourceforge.net From: noreply(a)sourceforge.net Subject: [ python-Bugs-417845 ] Python 2.1: SocketServer.ThreadingMixIn Date: Thu, 03 May 2001 16:26:12 -0700 Bugs item #417845, was updated on 2001-04-21 08:28 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=105470&aid=417845&group_id… Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Guido van Rossum (gvanrossum) Summary: Python 2.1: SocketServer.ThreadingMixIn Initial Comment: SocketServer.ThreadingMixIn does not work properly since it tries to close the socket of a request two times.

1 0

Classes and Metaclasses in Smalltalk
by Guido van Rossum 04 May '01

04 May '01

Jim Althoff (a big commercial user of J[P]ython) sent me a summary of how metaclasses work in Smalltalk. He should know, since he invented them! :-) I include it below, with his permission. While implementing more class-like behavior for built-in types in the experimental descr-branch in the 2.2 CVS tree, I've noticed problems caused by Python's collapsing of class attributes and instance attributes. For example, suppose d is a dictionary. My experimental changes make d.__class__ return DictType (from the types module). (DictType.__class__ is TypeType, by the way.) I also added special methods. For example, d.__repr__() now returns repr(d). I am preparing for subclassing of built-in types, so I will eventually be able to derive a class MyDictType from DictType, as follows: class MyDictType(DictType): ... Now comes the fun part. Suppose MyDictType wants to define its own repr(): class MyDictType(DictType): def __repr__(self): return "MyDictType(%s)" % DictType.__repr__(self) But, (surprise, surprise!), DictType itself also has a __repr__() method: it returns the string "<type 'dictionary'>". So the above code would fail: DictType.__repr__() returns repr(DictType), and DictType.__repr__(self) raises an argument count error. The correct __repr__ method for dictionary objects can be found as DictType.__dict__['__repr__'], but that looks hideous! What to do? Pragmatically, I can make DictType.__repr__ return DictType.__dict__['__repr__'], and all will be well in this example. But we have to tread carefully here: DictType.__class__ is TypeType, but DictType.__dict__['__class__'] is a descriptor for the __class__ attribute on dictionary objects. The best rule I can think of so far is that DictType.__dict__ gives the *true* set of attribute descriptors for dictionary objects, and is thus similar to Smalltalks's class.methodDict that Jim describes below. DictType.foo is a shortcut that can resolve to either DictType.__dict__['foo'] or to an attribute (maybe a method) of DictType described in TypeType.__dict__['foo'], whichever is defined. If both are defined, I propose the following, clumsy but backwards compatible rule: if DictType.__dict__['foo'] describes a method, it wins. Otherwise, TypeType.__dict__['foo'] wins. Sigh. --Guido van Rossum (home page: http://www.python.org/~guido/) ------------------------- Jim Althoff's message --------------------------- Hi Guido, I was reading the discussion on class methods in the python-dev archive and noticed your question about how Smalltalk determines the difference between instance methods and class methods. I have some info on this which I can't post to python-dev, not being a member; but I thought you might be interested in it anyway. It turns out that I am the one that devised metaclasses in Smalltalk-80. (On the other hand, I haven't looked at any Smalltalk implementation code in a long time so this is merely a description of how it all started.) Basically (I think) Smalltalk doesn't have the ambiguity you mention for instance methods versus class methods (as Python would) because Smalltalk doesn't do method lookup the same as Python does. To illustrate, suppose you have object.method() (using Python-style syntax) The Smalltalk method lookup is as follows: o find the class that object is an instance of -- this resulting thing is a "class object" (a first-class object, same as in Python) o since class is a "class object" one of its fields will be a dict of methods -- let's call it class.methodDict o find method in class.methodDict o if found, execute method on object o if not, do the same thing traversing the (single inheritance) superclass chain (follow class.superClass) I believe Python works roughly as follows (Just testing my own understanding here -- correct me if I don't get it right): o convert (conceptually at least) object.method() into object. __class__.method(object) o find a _function_ corresponding to method in object.__class__.__dict__ o if found, execute the found function (with object bound as the first arg to function) o if not, traverse the (multiple inheritance) superclass chain (depth first) I think the key difference is that Python treats object.method() the same as it treats object.__class__.method(object). Smalltalk doesn't do this. In Smalltalk, object.__class__.method(object) would mean: o consider object.__class__ to be an "object" like any other "object" in Smalltalk (which it is) o get the "class object" of object.__class__ , namely object. __class__.class__ o find method in object.__class__.__class__.methodDict o if found, execute the method on object.__class__ o if not, do the same thing traversing the (single inheritance) superclass chain (follow object.__class__.__class__.superClass) In other words, it exactly the same lookup mechanism. So there is no ambiguity. To summarize, in Smalltalk: o instance methods (for instances that are not "class objects") are specified by: instance.instanceMethod() o class methods are specified by: class.classMethod() o both of these are just object.objectMethod() since classes are objects and the method lookup mechanism is no different from that of any other kind of object. A concrete example: If I have a class Date in Smalltalk and an instance of it referenced by variable, d. I would do: o d.followingDate() for an instance method, and o Date.currentDate() for a class method I think this is a nice, conceptually simple model. Things get interesting, though, when you start to consider how the mechanism of class. __class__ -- which is the thing that makes class methods no different than instance methods -- actually works. And this leads to metaclasses in Smalltalk. Here's a rough sketch of how metaclasses work: Standard principles of Smalltalk: o everything is an object (first-class) o every object is an instance of a class o a class inherits (single-inheritance) from its superclass (except the root class Object, which has no superclass) o methods can be invoked on a object. All such methods are defined as part of the object's class definition (or a class going up the superclass chain) Because of the first 2 principles above: o every class is an object (because everything is an object) o every class is, itself, an instance of some class (because every object is an instance of a class) Originally in Smalltalk-76, there was one metaclass, Class. All classes (class objects) were instances of Class. Class was an instance of itself. Class had methods defined for it just like all classes did. In particular, it had a method "new" -- this being the method that creates instances of classes. So suppose you had class Rectangle. Rectangle is an instance of Class (hence it is a class object). If you wanted to create an instance of Rectangle, you would do: myRect = Rectangle.new(). This would mean: "find the 'new' method in the definition of Rectangle's class (Class) and invoke it on Rectangle (which is a class object). The result is a Rectangle instance which is assigned to the variable myRect. The Rectangle class object held data (state -- same rules as any other kind of object) -- such as number and name of fields its instances would have, a dictionary of methods for its instances, etc. So the "new" method in Class would have access to all the info it needed to create a Rectangle instance (as opposed to a Point instance, for example). The limitation with this scheme was that all classes had to share exactly the same methods, namely all the methods defined in Class. The method "new" was one of these methods along with lots of "reflection-type" methods for class creation, modification, and inspection. But if you wanted an "application-oriented" class method -- like Date.currentDate() -- you couldn't do that because then the method "currentDate" would be shared amongst all class objects (instances of Class) and wouldn't make any sense (e.g., Rectangle.currentDate()). In Smalltalk-80 I added a more flexible mechanism which we called metaclasses (we hadn't used that terminology previously for the single Class although it was a "metaclass"). The thing that everyone in the Smalltalk development team liked about the new metaclass mechanism at the time was that it didn't require any new basic principles for Smalltalk. It was all done using the same basic principles of Smalltalk listed above. The idea was to use subclassing to allow for different methods for different instances of Class. A "metaclass" simply became a subclass of Class. Each class object then ended up being a singleton instance (although the "singleton-ness" was not mandatory) of a metaclass (i.e., a subclass of Class). So class objects were no longer _all_ instances of the _same_ class (Class). Each was an instance of a corresponding subclass of Class -- that is to say, an instance of a metaclass. The Smalltalk-80 class hierarchy looked like the following: (This is actually a simplification. The actually hierarchy has a little more factoring and I changed the names for more clarity). First a digression on some terminology: o a class is an object that can be instantiated o a metaclass is a class and one such that when it is instantiated, the instanced is itself a class o a plain-object is one that cannot be instantiated (I'm just making this term up). o a plain-class is one that is a class but is not a metaclass (making this up, too). In the list below, indentation indicates class hieararchy (superclass -- subclass) plain-class ---------------- <none> o Class o Object isInstanceOf o ObjectMetaClass isInstanceOf MetaClass o Class isInstanceOf o ClassMetaClass isInstanceOf MetaClass o MetaClass isInstanceOf o MetaClassMetaClass isInstanceOf MetaClass . . . o Rectangle isInstanceOf o RectangleMetaClass isInstanceOf MetaClass o SpecializedRectangle isInstanceOf o SpecializedRectangleMetaClass isInstanceOf MetaClass All "metaclasses" are instances of MetaClass. All "plain-classes" (those that are not "metaclasses") are instances of a "metaclass". Because of this there are parallel class hierarchies between "plain-classes" and their corresponding "metaclasses". Note that MetaClass is a "plain-class" and not a "metaclass". Also note that MetaClass (being a "plain-class") is an instance of its corresponding "metaclass" MetaClassMetaClass. And MetaClassMetaClass is an instance of MetaClass (because MetaClassMetaClass _is_ a "metaclass"). The MetaClass / MetaClassMetaClass class/instance relationship is circular. An example. If you want a Rectangle class you first make a metaclass for it, RectangleMetaClass -- actually, the system does this for you automatically as part of the class creation method implementation (when you define the class Rectangle, for example). RectangleMetaClass is an instance of MetaClass so all the methods defined in MetaClass are available to it. RectangleMetaClass can also define its own methods now (because it is a class) which would be invoked on any (typically one) instance of RectangleMetaClass, which in this case is going to be class Rectangle. You then make your Rectangle class by making an instance of RectangleMetaClass (conceptually doing: Rectangle = RectangleMetaClass.new() ). Now you can make instances of Rectangle, doing: myRect = Rectangle.new() as before. This is not so different from the Smalltalk-76 mechanism. The main advantage is that you now have a specific class, RectangleMetaClass, that can have methods specific to the class Rectangle (the instance of RectangleMetaClass). So you could define a method like "newFromPointToPoint" for example and then do: myRect = Rectangle.newFromPointToPoint(point1,point2). The meaning is the same as always: take the variable "Rectangle", find out what it is pointing to. It is pointing to an instance of the RectangleMetaClass. Find the method "newFromPointToPoint" as part of the definition of RectangleMetaClass (it being a class object). Invoke this method on the Rectangle class object -- which then creates a Rectangle instance. The same would go for the other example: Date.currentDate(). So the bottom line is (I think) that the Smalltalk method lookup mechanism doesn't have to resolve an ambiguity because all methods that get invoked on an object always come from the object's definition class (or superclass) and from no other place. Hope this helps, Jim

13 50

OT: CVS access through firewall via SSH
by skip＠pobox.com 03 May '01

03 May '01

Python-dev folks, Sorry for the off-topic post, but I'm striking out on the various other sources I've located so far. Since this group seemed to have a love-hate relationship with CVS for awhile I thought maybe someone here would be able to steer me in the right direction. I have to access a CVS repository through a firewall via SSH. That is, to get to "server" I have to tunnel through "firewall" using SSH to port "nnn". Using SSH to establish an interactive session to server is no problem: ssh -p nnn firewall When I'm inside the firewall, I use a CVSROOT that looks like :pserver:montanaro@server:/cvs/projects I need to merge the two bits somehow to come up with a CVSROOT that will do the tunnel automagically. I've tried this: :pserver:montanaro@firewall:nnn/cvs/projects but CVS complains cvs [update aborted]: connect to firewall:2401 failed: Connection refused (port 2401 is the normal CVS port). Any suggestions or pointers? Thanks, Skip

1 0

RE: [Python-checkins] CVS: python/dist/src/Doc/lib libfuncs.tex,1.76,1.77
by Tim Peters 02 May '01

02 May '01

[Fred L. Drake] > Update the filter() and list() descriptions to include information > about the support for containers and iteration. > ... > \begin{funcdesc}{list}{sequence} > ! Return a list whose items are the same and in the same order as > ! \var{sequence}'s items. \var{sequence} may be either a sequence, > ! a container that supports iteration, or an iterator object. > ... [and similarly for filter()] Before we repeat this last incantation umpteen more times in the docs, is this how we want it to read in the end? The truth of the implementation and of the design is that "sequence" is any object that supports iteration, period (if PyObject_GetIter(op) succeeds, list(op) etc are happy, else they raise TypeError). "A sequence" and "an iterator object" *always* support iteration, so naming them too appears to draw a distinction that doesn't exist. Suggested alternative: \var{sequence} must support iteration (see XXX). where XXX is common boilerplate explaining what "support iteration" means, and that sequences and iterator objects are just particular cases of that. Note that this boilerplate may expand to include generators too before 2.2 is real, and a generator isn't really "a container that supports iteration" (the word "container" is a strain in the generator context). That is, a long-winded incantation is just going to get longer over time, and if it's repeated umpteen places in the docs I doubt they'll all get updated when needed.

1 0

PEP 250 buglet
by Fredrik Lundh 02 May '01

02 May '01

PEP 250 suggests changing the sitedirs setup in site.py from sitedirs = [prefix] to sitedirs == [makepath(prefix, "lib", "site-packages")] on windows. it then goes on to say that This change does not preclude packages using the current location -- the change only adds a directory to sys.path, it does not remove anything. this isn't true (even after correcting the typo), since the sitedirs list isn't only added to the path; it's also used to look for PTH files. after this change, PTH files located under prefix will no longer be found. the following change works a bit better: sitedirs = [prefix, makepath(prefix, "lib", "site-packages")] Cheers /F

1 0

Unicode and the Windows file system.
by Mark Hammond 02 May '01

02 May '01

I understand the issue of "default Unicode encoding" is a loaded one, however I believe with the Windows' file system we may be able to use a default. Windows provides 2 versions of many functions that accept "strings" - one that uses "char *" arguments, and another using "wchar *" for Unicode. Interestingly, the "char *" versions of function almost always support "mbcs" encoded strings. To make Python work nicely with the file system, we really should handle Unicode characters somehow. It is not too uncommon to find the "program files" or the "user" directory have Unicode characters in non-english version of Win2k. The way I see it, to fix this we have 2 basic choices when a Unicode object is passed as a filename: * we call the Unicode versions of the CRTL. * we auto-encode using the "mbcs" encoding, and still call the non-Unicode versions of the CRTL. The first option has a problem in that determining what Unicode support Windows 95/98 have may be more trouble than it is worth. Sticking to purely ascii versions of the functions means that the worst thing that can happen is we get a regular file-system error if an mbcs encoded string is passed on a non-Unicode platform. Does anyone have any objections to this scheme or see any drawbacks in it? If not, I'll knock up a patch... Mark.

5 13

Coercion and comparison of numbers
by M.-A. Lemburg 02 May '01

02 May '01

I just received a bug report for mx.Number which revealed a probelm with the comparison code in Python 2.1. Looking at the code it seems that one of my original coercion patches did not make it into the core. I added a new API PyNumber_Compare() knows about the new coercion mechanism and should be called for numbers instead of trying coercion in PyObject_Compare(). Was this part of the coercion patch left out on purpose or a simple oversight ? I hope the latter... -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

3 3

Slight wart in __all__
by Mark Hammond 01 May '01

01 May '01

I just got caught out by this: """ def foo(): pass __all__ = [foo] """ Then at the interactive prompt: >>> from foo import * Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: attribute name must be string The problem is that __all__ contains a function object rather than a string object. I had to use the debugger to determine why I was getting the failure :( All you 2.1 veterans will immediately pick that it should read '__all__ = ["foo"]' Looking at the __all__ code: if (skip_leading_underscores && PyString_Check(name) && PyString_AS_STRING(name)[0] == '_') { Py_DECREF(name); continue; } value = PyObject_GetAttr(v, name); PyObject_GetAttr explicitly handles string and unicode objects. However, code here won't like Unicode that much :) Would it make sense to a explicitly raise a more meaningful exception here if __all__ doesnt contain strings?

2 1

MacPython 2.1 released
by jack＠oratrix.nl 01 May '01

01 May '01

MacPython 2.1 is available for download. Get it via http://www.cwi.nl/~jack/macpython.html . Python is a high-level programming language that is suitable for simple scripting tasks as well as writing large applications. MacPython offers alot of Mac-specific extensions, including access to all major MacOS Toolbox modules (QuickDraw, QuickTime, AppleScript and many more), an Integrated Development Environment (in Python!), frameworks for windowing applications, unix-compatible cgi-scripting, image-manipulation libraries, numerical libraries, tk-based machine independent windowing and lots more. It also uniquely among Pythons allows you to create fully selfcontained (and, hence, distributable) applications without needing a C compiler or anything. New in this version: - A choice of Carbon or Classic runtime, so runs on anything between MacOS 8.1 and MacOS X - Distutils support for easy installation of extension packages - BBedit language plugin - All the platform-independent Python 2.1 mods - New version of Numeric - Lots of bug fixes - Choice of normal and active installer Please send feedback on this release to pythonmac-sig(a)python.org, where all the MacPythoneers hang out. Enjoy, -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | ++++ see http://www.xs4all.nl/~tank/ ++++

1 0

Importing extensions on Windows 95
by M.-A. Lemburg 01 May '01

01 May '01

Rebooting the thread... While testing mxNumber, I discovered what looks like a bug in Win95: both Thomas Heller and I are seeing a problem with Python 2.1 when importing extension modules which rely on other DLLs as library. Interestingly, the problem only shows up when starting Python from the installation directory. Looking at the imports using python -vv shows that in this situation, Python tries to import modules, packages, extensions etc. using *relative* paths. Now, under Win98 there is no problem, but Win95 doesn't seem to like these relative imports when it comes to .pyd files which reference DLLs in the same directory. It doesn't have any problems when Python is started outside the installation dir, since in that case Python uses absolute paths for importing modules and extensions. Would it be hard to tweak Python into always using absolute search paths during module import ? -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.lemburg.com/python/

3 9