Mailman 3 March 2002 - Python-Dev

RE: Python-Dev digest, Vol 1 #1944 - 12 msgs
by Gerald S. Williams 07 Mar '02

07 Mar '02

Guido van Rossum <guido(a)python.org> wrote: > I would certainly like to see more applications from people interested > in getting developer status, even if it means I'll have to do > semi-formal "interviews" or reference checks myself. How can we > encourage the good developers that exist to help? Be careful what you ask for. Perhaps the developers you really want are going to seek you out anyway. As a new member, let me take a bit of time to introduce myself: I'm with a Lucent spinoff that makes communications ICs, and write drivers and other software to support them (not as simple as it sounds--these are BIG chips). But I started off in Bell Labs. I decided that was what I wanted to be when I got to meet the original group that wrote Unix (I was 11 at the time). Times have changed at AT&T (and now Lucent), though. But I digress... My previous assignment involved writing development tools for our DSPs. I was peripherally involved with a GCC port for our DSP (a contract was in place when I joined the group), and I ported the BSD libraries (we wanted to avoid licensing issues with Gnu libs) and wrote the rest of the development tools (assembler, linker, archiver, and the like). I also got several software patents for my work (boo, hiss!). We were very involved with Tcl there, and used it extensively with our integrated debugger/simulator/ICE tool. After I joined my current group, I discovered Python. I've been working with Python for a few years now, and I believe projects like Python are really becoming the technology leaders now. It's an exciting place to be. I've made many Python converts (once they get past the idea of using indents). [BTW, I had previous experience with a research language called FIT that used indents similarly. But again I digress...] I joined this list after posting a few patches to the Python threading modules. This all started after I got my group to finally abandon Microsoft Developer Studio for in-house work and switch to Cygwin (one step closer to Linux!), only to discover that Cygwin Python didn't support threads. :-( I'm still in lurker mode on this list, but expect to hear more from me in the future... -Jerry -O Gerald S. Williams, 22Y-103GA : mailto:gsw@agere.com O- -O AGERE SYSTEMS, 555 UNION BLVD : office:610-712-8661 O- -O ALLENTOWN, PA, USA 18109-3286 : mobile:908-672-7592 O-

2 1

Incorporating some of the HOWTOs
by Andrew Kuchling 06 Mar '02

06 Mar '02

I'm becoming more and more convinced that at least some of the HOWTOs should become part of the Python documentation. Motivation: * A sizable number of the documents are about Python as a whole, and therefore would be more naturally part of Python's tree than a separate one. * If the documents were in the Python CVS tree, changes would be glanced at by the 30-odd people on the python-checkins list as opposed to the 8 people on the pyhowto-checkins list * They would get increased visibility from being on www.python.org/doc/ . My candidates for addition would be (in decreasing order of suitability): * The "What's New" documents, which are like really verbose release notes. * python-dev, which discusses how Python is developed, where to report bugs, and that sort of thing. * "Editor Configuration", which discusses how to configure various editors (vi, Emacs, Alpha, CodeWright, jed, ....) for editing Python code. * The Python Advocacy HOWTO, which should be dusted off and updated to serve as a sort of advocacy/marketing FAQ. The rest of the HOWTOs are smaller and more task-specific (rexec, curses); a case could be made for creating Doc/howto/, but I won't argue that case right now. Reactions (particularly from Fred)? --amk (www.amk.ca) "The future" has arrived but they forgot to update the docs. -- R. David Murray, 9 May 2000 (The random number generator strikes again!)

3 3

Re: [Python-checkins] CVS: python/dist/src/Lib os.py,1.51,1.52
by Michael Hudson 06 Mar '02

06 Mar '02

Neal Norwitz <neal(a)metaslash.com> writes: > Michael: > > I'm curious why you did import copy_reg as _copy_reg. > Is it because you don't want clutter when doing 'from os import *'? Well, just to empasize the "this is here for obscure internal purposes only" effect. > Would it be better to do: > > import copy_reg > # use copy_reg > del copy_reg > ? Maybe. Don't care much either way. Cheers, M. -- : Giant screaming pieces of excrement, they are. I have a feeling that some of the people in here have a MUCH more exciting time relieving themselves than I do. -- Mike Sphar & Dave Brown, asr

1 0

Re: [Python-Dev] Explorations on new-style classes
by Michael Hudson 06 Mar '02

06 Mar '02

Kevin Jacobs <jacobs(a)penguin.theopalgroup.com> writes: [snip] > I'm very much interested in what people think about these ideas about using > (or mis-using) slots, metaclasses, new-style classes, and other cutting-edge > Python features. I think it's hard to have an opinion until I come across some problem where using these new features helps. This hasn't happened to me yet. [...] > I am also aware that a sizeable fraction of python-dev may not care much > about this topic, so I would not be offended if the consensus was that this > discussion is not topical enough for the list. Hey, I ignore most of python-dev, most days. I think this stuff is interesting, but can't spare the brain cells to think hard about it :( > It would also be nice if some of the examples I'm working on could > eventually become part of the official Python test suite. If for no other > reason, because the current set of tests is somewhat sparse. Submitting patches will make this vastly more likely... Cheers, M. -- All parts should go together without forcing. You must remember that the parts you are reassembling were disassembled by you. Therefore, if you can't get them together again, there must be a reason. By all means, do not use a hammer. -- IBM maintenance manual, 1925

1 0

Explorations on new-style classes
by Kevin Jacobs 06 Mar '02

06 Mar '02

Hi all, I've been sick, and have not had the strength to continue last week's thread on slots. I'll get back to it, but in the mean time I thought I'd share a little of what my feverish brain has come up with: First, should we add the type of a slot descriptor to 'types'? i.e.: # Get the type of a member descriptor (its not currently in types) class _Foo(object): __slots__ = 'a' member_descriptor = type(_Foo.a) del _Foo If so, I'll submit a patch related the the above. Second, I've been twisting metaclasses to do my evil bidding. In this case, I have implemented pseudo-typed attributes and slots in Python. e.g.: class A(object): __metaclass__ = ConstrainedObject __slots__ = {'a':int,'b':float} class B(A): __attrs__ = {'c':str} # My own invention foo=B() foo.a = 1 foo.b = 1 foo.c = 1 print foo.a,foo.b,foo.c > 1 1.0 1 print type(foo.a),type(foo.b),type(foo.c) > <type 'int'> <type 'float'> <type 'str'> foo.a = '5' foo.b = '0x5A' foo.c = 5.4 print foo.a,foo.b,foo.c > 5 1.40625 5.4 foo.a = 'Spam!' > ValueError: invalid literal for int(): Spam! The first thing to notice is that float('0x5A') == 1.40625?! I can see what it is doing, though it doesn't seem to be the most intuitive behavior. However, this is tangential to what I really care about -- I just thought I'd share my initial confusion. Thirdly, properties doesn't seem to be subclassable. Or at least they fail to be properties once subclassed. This isn't a big deal, but it should be documented if it is an intentional behavior. See the attached file for more why... Third, metaclasses are _fun_. The above example uses silly constraint objects, since they do all kinds of possibly smart and annoying things. e.g., Instead of using str, int and float, we can easily define functions like: def str_constraint(s): if type(s) is not types.StringType: raise TypeError, "I'm sorry Dave, but I expected a string." return s Anyhow, the implementation of my constraint meta-class is attached. Give it a read-over if you feel masochistic and let me know what you think. Still running a fever, -Kevin -- -- Kevin Jacobs The OPAL Group - Enterprise Systems Architect Voice: (216) 986-0710 x 19 E-mail: jacobs(a)theopalgroup.com Fax: (216) 986-0714 WWW: http://www.theopalgroup.com

3 4

RE: [Python-checkins] CVS: python/nondist/sandbox/datetime datetime.py,1.50,1.51
by Tim Peters 05 Mar '02

05 Mar '02

[MAL, on DST for out-of-platform-mktime()-range years] > My point was to not fiddle with the date at all: raise an > exception and that's it. If someone wants to print some datetime object from the year 1537 as if a local time, raising an exception just because the local DST rules in effect at that time are unknown seems extremely unfriendly. For goodness sake, we're already "lying" to them about the calendar system in effect at that time, and an hour more or less due to DST uncertainty is trivial. It's an idealized calendar, and an idealized time. We should supply a way for the user to find out whether or not a DST correction was applied, though. ECMAScript does that via a DaylightSavingTA(t) function mapping UTC time to the number of milliseconds (all their times are in milliseconds) to be added to t to adjust for local DST. A distinct LocalTZA constant gives the number of msecs to add to UTC to adjust for local timezone. Conversion from UTC to local time is defined by LocalTime(t) = t + LocalTZA + DaylightSavingTA(t) Conversion from local time to UTC is defined by UTC(t) = t – LocalTZA – DaylightSavingTA(t – LocalTZA) Note that UTC(LocalTime(t)) is not necessarily always equal to t. That last line gives me an especially warm feeling <wink>. there's-idealized-and-then-there's-idealized-ly y'rs - tim

1 0

PEP 263 -- Python Source Code Encoding
by M.-A. Lemburg 05 Mar '02

05 Mar '02

I consider the above PEP ready for review by the developers. Please comment. http://python.sourceforge.net/peps/pep-0263.html After approval, the next step would be to implement phase 1 for 2.3. Step two would then be on the plate for 2.4. -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

16 75

Re: [Python-checkins] CVS: python/dist/src/Lib robotparser.py,1.10,1.11
by Michael Hudson 05 Mar '02

05 Mar '02

"Martin v. L?wis" <loewis(a)users.sourceforge.net> writes: > Update of /cvsroot/python/python/dist/src/Lib > In directory usw-pr-cvs1:/tmp/cvs-serv31559/Lib > > Modified Files: > robotparser.py > Log Message: > Correct various errors: > - Use substring search, not re search for user-agent and paths. > - Consider * entry last. Unquote, then requote URLs. > - Treat empty Disallow as "allow everything". > Add test cases. Fixes #523041 I can't tell and Martin's not sure whether this is appropriate for the 2.2.1 branch. What do others think? Cheers, M. -- Some people say that a monkey would bang out the complete works of Shakespeare on a typewriter give an unlimited amount of time. In the meantime, what they would probably produce is a valid sendmail configuration file. -- Nicholas Petreley

2 1

setting class attributes from C?
by Fred L. Drake, Jr. 05 Mar '02

05 Mar '02

Has anyone tried setting class attributes on a new-style class in C? The file sandbox/datetime/datetime.py has code that does this: class datetime(basetime): ... datetime.min = datetime(...) datetime.max = datetime(...) I can easily add descriptors in the C version so that min and max are defined on instances, but using PyObject_SetAttrString() using the new class: tmp = create_datetime(...); if (datetime_min == NULL) return; if (PyObject_SetAttrString((PyObject *) &PyDateTime_Type, "min", datetime_min) < 0) return; produces this exception: Traceback (most recent call last): File "test_cdatetime.py", line 9, in ? from _datetime import datetime, MINYEAR, MAXYEAR TypeError: can't set attributes of built-in/extension type 'datetime.datetime' (where _datetime is the C extension that implements the C version of the type). Any ideas? -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

4 3

inet_addr usage in Modules/socketmodule.c?
by Skip Montanaro 05 Mar '02

05 Mar '02

According to the checkin comment for Modules/socketmodule.c v. 1.91: Port inet_ntoa and inet_aton to Windows: - fix unescaped newline in string literal - removed unused err variable - Windows doesn't have inet_aton; use inet_addr instead However, in the man page for inet_addr it states: This is an obsolete interface to inet_aton, described immediately above; it is obsolete because -1 is a valid address (255.255.255.255), and inet_aton provides a cleaner way to indicate error return. The reason I bring it up is that a request came in today to python-help about python-2.2 on an SX supercomputer, which suggests that the code for handling INADDR_NONE (and thus inet_addr()) is broken: I have compiled python-2.2 on an SX supercomputer which does not have inet_pton(). The emulated one in Modules/socketmodule.c is being used instead. The test for packed_addr against INADDR_NONE fails because: 1) INADDR_NONE is 0xffffffff in SX #include file, 2) long on SX is 8-bytes, 3) inet_addr() returns -1 (0xffffffffffffffff) which is -1, but _not_ INADDR_NONE. Has this problem come up anywhere else with sizeof(long) == 8 and inet_addr() schizophrenia? I realize that this may be an OS implementation issue (should inet_addr() return -1 or INADDR_NONE) but what should/can be done (if anything) to the Python package in order to address this? It seems to me the simplest thing to do is to force a "proper" definition of INADDR_NONE with something like #ifdef INADDR_NONE #undef INADDR_NONE #endif #define INADDR_NONE ((in_addr_t)-1) if it's not defined and in_addr_t is available. The more correct thing would seem to be to dump inet_addr in favor of inet_aton unless the latter is unavailable. On the other hand, perhaps just the SX include files are busted and all that has to happen is to override INADDR_NONE for that platform: #if defined(INADDR_NONE) && INADDR_NONE != ((in_addr_t)-1) #undef INADDR_NONE #define INADDR_NONE ((in_addr_t)-1) #endif Unfortunately, my mastery of the C preprocessor, casts, and configure is insufficient to determine without some experimentation on a platform I have no acces to if either of these is a workable approach or if there is a better approach that will work on the SX. Your thoughts? Skip

2 1

Python-Dev March 2002