Mailman 3 February 2002 - Python-Dev

Version updates etc.
by Guido van Rossum Feb. 28, 2002

Feb. 28, 2002

Maybe it's time for a quick informative PEP explaining where, when and how version numbers, copyright dates and the like should be updated? This info is currently spread all over the place (PEP 101 and 102 have some, the rest in in the minds of various PythonLabs folks). --Guido van Rossum (home page: http://www.python.org/~guido/)

2 1

PEP 0275 -- Switching on Multiple Values
by M.-A. Lemburg Feb. 28, 2002

Feb. 28, 2002

I consider the PEP 0275 ready for review by the developers. Comments please. http://python.sourceforge.net/peps/pep-0275.html Thanks, -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/

2 3

Manning Seeking Python book authors
by Guido van Rossum Feb. 28, 2002

Feb. 28, 2002

Is anybody interested in writing any of the titles below, or can you recommend someone? --Guido van Rossum (home page: http://www.python.org/~guido/) ------- Forwarded Message Date: Wed, 27 Feb 2002 15:02:17 -0500 From: Susan Capparelle <suca(a)manning.com> To: Guido van Rossum <guido(a)CNRI.Reston.VA.US> Subject: Seeking Python book authors Hi Guido, I hope all is well? As someone who has done valuable reviewing for us before in the Python arena, I thought you might be one of the right people to contact. We're currently seeking authors for a number of Python related books. A couple of titles or topics would be; 'Enterprise system development with Python,' 'Practical Python' and 'Effective Python.' Can you recommend anyone with the necessary experience and skills to undertake any of these books? Looking forward to your response and thanks in advance for your help. Sincerely, ======================================= Susan W. Capparelle Assistant Publisher Manning Publications Co. 209 Bruce Park Avenue, Greenwich, CT 06830 suca(a)manning.com tel. 203.629.2211 www.manning.com fax. 203.629.2084 ======================================= ------- End of Forwarded Message

2 1

Supporting precision in a DateTime type
by Steve Alexander Feb. 27, 2002

Feb. 27, 2002

Hi folks, On #zope3-dev, we were discussing how best to implement a DateTime type in Python. Leaving aside arguments of whether to store it as a packed C tuple, or as ms since an epoch, I'd like to think about the concept of precision as it relates to dates and times. As a writer of software applications that people use in people settings, I like to use types that reflect the elements of reality that people find important. One aspect of time that is important is its precision. Here's an example How long is it between 1992 and March 15, 1993 ? There isn't a sensible answer. Or, rather, there are many answers, some more sensible than others. The correct answer might be "1 year", a date range, or an error (perhaps a ValueError). In any case, the correct answer depends on the nature of the application. Thus, if I'm only interested in using dates, such as in an application where I'm interested in birthdays, I want to be able to describe a date without reference to a particular time. It isn't just a default time, it is a "no time specified". So, I won't get caught later on if I compare that datetime instance with another that has a different precision. It is often possible to resolve differing precisions in an application-specific way. Another way of thinking about precision is as a constraint on possible more precise values. So, I can play an April fool prank any time in the morning of April 1, in my local time-zone. The actual exact time of my pranks will fall within the less precise constraint. This makes dates with precision similar to durations. Common precisions in applications include years, months, iso weeks of a year, days. Any finer precision doesn't really matter; the max precision of time in C is ok for most human purposes. Although you could catch some cases by having distinct types for dates and times, this only captures the precision of days. It doesn't help for other precisions. Here's a paper I found via google, that discusses these issues: http://www.martinfowler.com/ap2/timePoint.html ps. I'm not a regular reader of python-dev. Guido suggested I post this here for further discussion. I'll catch up via the web eventually, but please cc me into any relevant replies. -- Steve Alexander

3 2

PEP 215 redux: toward a simplified consensus?
by barry＠zope.com Feb. 27, 2002

Feb. 27, 2002

I'm still woefully behind on my email since returning from vacation, but I thought I'd rehash a bit on PEP 215, string interpolation, given some recent hacking and thinking about stuff we talked about at IPC10. Background: PEP 215 has some interesting ideas, but IMHO is more than I'm comfortable with. At IPC10, Guido described his rules for string interpolation as they would be if his time machine were more powerful. These follow some discussions we've had during various Zope sprints about making the rules simpler for non-programmers to understand. I've also been struggling with how error prone %(var)s substitutions can be in the thru-the-web Mailman strings where this is supported. Here's what I've come up with. Guido's rules for $-substitutions are really simple: 1. $$ substitutes to just a single $ 2. $identifier followed by non-identifier characters gets interpolated with the value of the 'identifier' key in the substitution dictionary. 3. For handling cases where the identifier is followed by identifier characters that aren't part of the key, ${identfier} is equivalent to $identifier. And that's it. For the sake of discussion, forget about where the dictionary for string interpolation comes from. I've hacked together 4 functions which I'm experimentally using to provide these rules in thru-the-web string editing, and also for sanity checking the strings as they're submitted. I think there's a fairly straightforward conversion between traditional %-strings and these newfangled $-strings, and so two of the functions do the conversions back and forth. The second two functions attempt to return a list of all the substitution variables found in either a %-string or a $-string. I match this against the list of known legal substitution variables, and bark loudly if there's some mismatch. The one interesting thing about %-to-$ conversion is that the regexp I use leaves the trailing `s' in %(var)s as optional, so I can auto-correct for those that are missing. I think this was an idea that Paul Dubois came up with during the lunch discussion. Seems to work well, and I can do a %-to-$-to-% roundtrip; if the strings at the ends are the same then there wasn't any missing `s's, otherwise the conversion auto-corrected and I can issue a warning. This is all really proto-stuff, but I've done some limited testing and it seems to work pretty well. So without changing the language we can play with $-strings using Guido's rules to see if we like them or not, by simply converting them to traditional %-strings manually, and then doing the mod-operator substitutions. Hopefully I've extracted the right bits of code from my modules for you to get the idea. There may be bugs <wink>. -Barry -------------------- snip snip -------------------- import re from string import digits try: # Python 2.2 from string import ascii_letters except ImportError: # Older Pythons _lower = 'abcdefghijklmnopqrstuvwxyz' ascii_letters = _lower + _lower.upper() # Search for $(identifier)s strings, except that the trailing s is optional, # since that's a common mistake cre = re.compile(r'%$([_a-z]\w*?)$s?', re.IGNORECASE) # Search for $$, $identifier, or ${identifier} dre = re.compile(r'(\${2})|\$([_a-z]\w*)|\${([_a-z]\w*)}', re.IGNORECASE) IDENTCHARS = ascii_letters + digits + '_' EMPTYSTRING = '' # Utilities to convert from simplified $identifier substitutions to/from # standard Python $(identifier)s substititions. The "Guido rules" for the # former are: # $$ -> $ # $identifier -> $(identifier)s # ${identifier} -> $(identifier)s def to_dollar(s): """Convert from %-strings to $-strings.""" s = s.replace('$', '$$') parts = cre.split(s) for i in range(1, len(parts), 2): if parts[i+1] and parts[i+1][0] in IDENTCHARS: parts[i] = '${' + parts[i] + '}' else: parts[i] = '$' + parts[i] return EMPTYSTRING.join(parts) def to_percent(s): """Convert from $-strings to %-strings.""" s = s.replace('%', '%%') parts = dre.split(s) for i in range(1, len(parts), 4): if parts[i] is not None: parts[i] = '$' elif parts[i+1] is not None: parts[i+1] = '%(' + parts[i+1] + ')s' else: parts[i+2] = '%(' + parts[i+2] + ')s' return EMPTYSTRING.join(filter(None, parts)) def dollar_identifiers(s): """Return the set (dictionary) of identifiers found in a $-string.""" d = {} for name in filter(None, [b or c or None for a, b, c in dre.findall(s)]): d[name] = 1 return d def percent_identifiers(s): """Return the set (dictionary) of identifiers found in a %-string.""" d = {} for name in cre.findall(s): d[name] = 1 return d -------------------- snip snip -------------------- Python 2.2 (#1, Dec 24 2001, 15:39:01) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import dollar >>> dollar.to_dollar('%(one)s %(two)three %(four)seven') '$one ${two}three ${four}even' >>> dollar.to_percent(dollar.to_dollar('%(one)s %(two)three %(four)seven')) '%(one)s %(two)sthree %(four)seven' >>> dollar.percent_identifiers('%(one)s %(two)three %(four)seven') {'four': 1, 'two': 1, 'one': 1} >>> dollar.dollar_identifiers(dollar.to_dollar('%(one)s %(two)three %(four)seven')) {'four': 1, 'two': 1, 'one': 1}

15 71

Re: [Python-checkins] CVS: python/dist/src/Include patchlevel.h,2.60.2.1,2.60.2.1.2.1
by Michael Hudson Feb. 27, 2002

Feb. 27, 2002

Guido van Rossum <guido(a)python.org> writes: > > I *think* this is the only place I need to do this. > > I think so too. Good. > > There are also some "(c) 2001"s that should probably be turned into > > "(c) 2001, 2002"s -- should this be done on the trunk too? > > Yes -- can you take care of it? I'm such a sucker. -- > so python will fork if activestate starts polluting it? I find it more relevant to speculate on whether Python would fork if the merpeople start invading our cities riding on the backs of giant king crabs. -- Brian Quinlan, comp.lang.python

1 0

Re: OS/2 EMX changes to dynload_shlib.c
by Andrew MacIntyre Feb. 27, 2002

Feb. 27, 2002

On Tue, 26 Feb 2002, Guido Van Rossum wrote: > Given the number of OS/2 EMX specific changes to > dynload_shlib.c, wouldn't it be better to create a > separate dynload_os2.c? Its just occurred to me that you might in fact be referring to the changes to import.c, which were in the same commit (& thus the same checkin message) and were extensive. I did try to make it clear in the checkin message that changes to multiple files were committed. It seems to be de rigeur to commit a single file at a time; something I hadn't appreciated and don't remember being advised about. I will follow this practive from now on. -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac(a)bullseye.apana.org.au | Snail: PO Box 370 andymac(a)pcug.org.au | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia

2 1

RE: Python-Dev digest, Vol 1 #1917 - 14 msgs
by Andy Robinson Feb. 27, 2002

Feb. 27, 2002

> > I propose adding an "abstract" money base type to the standard > > library, to be subclassed by real money/decimal implementations. > > Why do we need this? I guess that would be Question #1... > > --Guido van Rossum (home page: http://www.python.org/~guido/) I can think of 3 reasons; I've seen all these occur in real life. Reason 1: Currency safety. Having a special type can rule out subtle programming errors. Imagine this: >> x = Money(3, "USD") >> y = Money(4.5, "NLG") >> z = x + y TypeError: can't add different currencies Likewise, if you add or subtract money you get money; if you divide money in the same currency you get a float; and just about any other operation might be an error. IMHO a basic type should just rule out operations; subclasses could do clever conversions etc. (Does anyone need Euro triagulation rules in the Python standard library?) Reason 2: fixed decimals SQL databases and AS400s have fixed decimal data types and can do math on thousands or millions of numeric fields at C-like speeds. There would be a (very small) market for a type that could do this. Reason (3): speed If I went for a Python "money class" with smart behaviour, I'd get a sizable speed hit compared to floats. Let's say I want to average a time series of 1000 bond prices; it will be faster on floats than on Python classes. IMHO all these are best served by an extension package not in the core language - but having a common base for them to inherit from would get a thumbs-up from me. Best Regards, Andy Robinson

1 0

Re: [Python-Dev] proposal: add basic time type to the standard library
by Anthony Baxter Feb. 27, 2002

Feb. 27, 2002

>>> "M.-A. Lemburg" wrote > I tried that in early version of mxDateTime -- it fails > badly. I switched to the local time assumption very > early in the development. If you must store stuff without timezones, _please_ don't use localtime. localtime is a variable thing (think what happens when daylight savings goes on and off). Storing UTC, or else the local time and enough timezone data to get to UTC reliably, is the only thing that will lead to hugs and puppies. Anthony, who deals with stupid date/times all the time, in billing systems, and in different time zones. -- Anthony Baxter <anthony(a)interlink.com.au> It's never to late to have a happy childhood.

2 1

Re: proposal: add basic time type to the standard library
by Tim Peters Feb. 27, 2002

Feb. 27, 2002

[Guido] > ... > Another thing to consider is that for most apps, the choice of the > date/time format should be taken out of the hands of the programmer > and placed into the hands of the user, through some kind of preference > setting. I18n and L10n also strongly suggests to take this route. I'm sure nobody wants to admit this <wink>, but in sheer numbers, nobody has more experience with this stuff than Microsoft. If you sit at your Windows box and go to Start -> Settings -> Control Panel -> Regional Settings, you'll get a tabbed dialog for specifying the format of number, currency, time, and date displays. A Windows app that ignores the settings here is considered to be broken (and rightly so). Idiosyncratic formats for user-visible number/currency/date/time info is going to become an increasingly Bad Idea on other OSes too.

9 17