Mailman 3 January 2003 - Python-Dev

Hello world.
by Jive Dadson 05 Jan '03

05 Jan '03

I would like to introduce myself to the group. I am a new-comer to Python. My first programming job was in 1971. Since 1979 I have worked fulltime in the computer field, mostly in research and developement. For three years in the early 80;'s I was visiting associate professor of computer science at a well-known university in the midwest. On the internet, I have posted under the nom du net of Jive Dadson for about 8 years or so. I am most at home programming in C++. I have used the language since its earliest days. My current work involves multi-threaded applications. Principle among them is an embedded robot control system. Best regards, Jive

1 0

Re: [Python-Dev] Holes in time
by Guido van Rossum 04 Jan '03

04 Jan '03

Let me present the issue differently. On Sunday, Oct 27, 2002, both 5:30 UTC and 6:30 UTC map to 1:30 am US Eastern time: 5:30 UTC maps to 1:30 am EDT, and 6:30 UTC maps to 1:30 am EST. (UTC uses a 24 hour clock.) We have a tzinfo subclass representing the US Eastern (hybrid) timezone whose primary responsibility is to translate from local time in that timezone to UTC: Eastern.utcoffset(dt). It can also tell us how much of that offset is due to DST: Eastern.dst(dt). It is crucial to understand that with "Eastern" as tzinfo, there is only *one* value for 1:30 am on Oct 27, 2002. The Eastern tzinfo object arbitrarily decides this is EDT, so it maps to 5:30 UTC. (But the problem would still exist if it arbitrarily decided that it was EST.) It is also crucial to understand that we have no direct way to translate UTC to Eastern. We only have a direct way to translate Eastern to UTC (by subtracting Eastern.utcoffset(dt)). Usually, the utcoffset() for times that differ only a few hours is the same, so we can approximate the reverse mapping (i.e. from UTC to Eastern) by using the utcoffset() for the input time and assuming that it is the same as that for the output time. Code for this is: # Initially dt is a datetimetz expressed in UTC whose tzinfo is None dt = dt.replace(tzinfo=Eastern) dt = dt + Eastern.utcoffset(dt) This is not sufficient, however, close to the DST switch. For example, let's try this with an initial dt value of 4:30 am UTC on Oct 27, 2002. The code applies the UTC offset corresponding to 4:30 am Eastern, which is -5 hours (EST), so the result is 11:30 pm the previous day. But this is wrong! 11:30 pm Eastern that day is in DST, so the UTC offset should be -4 hours. We can know we must make a correction, because we can compare the UTC offset of the result to the UTC offset of the input, and see that they differ. But what correction to make? The problem is that when the input is 6:30 UTC, the result is 1:30 am Eastern, which is still taken to be EDT. If we apply the same correction as we did for 4:30 UTC, we get 2:30 am Eastern, but that's wrong, because that's in EST, corresponding to 7:30 UTC. But if we don't apply a correction, and stick with 1:30 am Eastern, we've got a time that corresponds to to 5:30 UTC. So what time corresponds to 6:30 UTC? The problem for astimezone() is to come up with the correct result whenever it can, and yet somehow to fudge things so that 6:30 UTC gets translated to 1:30 Eastern. And astimezone() must not make many assumptions about the nature of DST. It can assume that the DST correction is >= 0 and probably less than 10 hours or so, and that DST changes don't occur more frequently than twice a year (once on and once off), and that the DST correction is constant during the DST period, and that the only variation in UTC offset is due to DST. But Tim has already taken all of that into account -- read his proof at the end of datetime.py: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/python/python/nondist/sandbo… Can you do better? --Guido van Rossum (home page: http://www.python.org/~guido/)

8 19

PEP 301 implementation checked in
by Andrew Kuchling 03 Jan '03

03 Jan '03

I've checked in Richard Jones's patches, so those of you who follow the Python CVS trunk can now play with the PEP 301 implementation. Changes: * The DistributionMetadata object and the setup() function now support 'classifiers' as a keyword. * The 'register' distutil command has been added to upload a package's metadata to the PyPI server. The registry is still running on my web server at amk.ca, a bandwidth-limited DSL line, but it'll be moved to something at python.org before too long. (Certainly before 2.3final ships!) Please bang on the distutils code in any way you can think of, filing bug reports and offering comments, so we can be sure that it's solid. You can comment on the web site, too, but the site can be updated independently of the Python code so there's less pressure to get it finished before 2.3final. Here's an example of how the new code works. A setup.py file can now contain a 'classifiers' argument listing Trove-style classifiers: setup (name = "Quixote", version = "0.5.1", description = "A highly Pythonic Web application framework", ... classifiers= ['Topic :: Internet :: WWW/HTTP :: Dynamic Content', 'Environment :: No Input/Output (Daemon)', 'Intended Audience :: Developers'], ... ) I can then run 'python setup.py register' to upload an entry to the package index, which is browseable at http://www.amk.ca/cgi-bin/pypi.cgi . ('register --list-classifiers' will output a list of legal classifiers.) See PEP 301 for more details. --amk (www.amk.ca) OLIVIA: Why, this is very midsummer madness. -- _Twelfth Night_, III, iv

2 1

Re: [Python-Dev] map, filter, reduce, lambda
by Bill Bumgarner 03 Jan '03

03 Jan '03

On Thursday, Jan 2, 2003, at 22:09 US/Eastern, python-dev-request(a)python.org wrote: > For Py3K, I might suggest "anon" instead of lambda, especially if the > construct were expanded to allow statements. If I weren't reading this list via digests on a 9,600 bps link that is only up three times a day, I would have beat Barry to that suggestion about 10 messages ago... ;-) +1 When I originally had lambda calculus thoroughly pounded into my head w/the anonymous clue-by-four, it didn't really click until someone said 'lambda functions are just anonymous functions'. Right. So why the heck are they called 'lambda'? Merely to make the less clueful CS students feel even more lost than they otherwise might? 'anon' sounds like a great name -- unlikely to be used, shorter than 'lambda', and a heck of lot more indicative as to what is going on. I'd just as soon live without the parens and *I* came from a Lisp/Scheme environment when I learned All About the Wonderful World of Lambda. b.bum

3 4

GC at exit?
by Aahz 03 Jan '03

03 Jan '03

[Originally posted to comp.lang.python with no response; asking here before filing a bug report] Is garbage collection supposed to run when Python exits? The following program does not print any output, unless I uncomment the gc.collect() (or add a for loop that forces GC after creating the cycle): import gc class A: pass class B: def __del__(self): print "Bye-bye!" a = A() b = A() a.b = b b.a = a a.x = B() del a del b #gc.collect() -- Aahz (aahz(a)pythoncraft.com) <*> http://www.pythoncraft.com/ "I disrespectfully agree." --SJM

8 11

Re: [Python-Dev] map, filter, reduce, lambda
by Michael Hudson 03 Jan '03

03 Jan '03

Skip Montanaro <skip(a)pobox.com> writes: > >> Is there a reason def couldn't have been reused in this context? > > Guido> You couldn't reuse def, because lambda can start an expression > Guido> which can occur at the start of a line, so a line starting with > Guido> def would be ambiguous (Python's parser is intentionally > Guido> simple-minded and doesn't like having to look ahead more than one > Guido> token). > > I'll leave that gauntlet thrown, since I have no interest in rewriting > Python's parser. Maybe it will spark John Aycock's interest though. ;-) Did you miss the "intentionally"? Cheers, M. -- at any rate, I'm satisfied that not only do they know which end of the pointy thing to hold, but where to poke it for maximum effect. -- Eric The Read, asr, on google.com

6 6

Re: [Python-Dev] map, filter, reduce, lambda
by Bill Bumgarner 03 Jan '03

03 Jan '03

On Thursday, Jan 2, 2003, at 21:13 US/Eastern, python-dev-request(a)python.org wrote: > map, reduce, filter, apply: They are just abstractions > which take a function and let them work on arguments > in certain ways. They are almost obsolete now > since they can be replaced by powerful constructs > like comprehensions and the very cute asterisk calls. Short answer: -1 for removing map/reduce/filter/apply unless doing so will vastly improve the Python core (i.e. less size, greater speed, smaller footprint -- some combination in a usefully large fashion). Personally, I find comprehensions and very cute asterisk calls to be incredibly unreadable. map(), reduce(), filter() and apply() are all easy to read and provide a keyword via which determining their meaning in the documentation is a trivial task. Comprehensions were incomprehensible the first 10 times I ran into them. A few years ago and spanning a number of years before that, I did a huge amount of Python programming. I ended up taking about a 2.5 year break from serious Python programming-- not for any particularly good reason, in hindsight-- and returned to Python in the last year. Somewhere in that break, list comprehensions were added. This is comprehensible, but looks alien in light of everything Python I had learned in the past (substitute a simple, but real world, comprehension into here): [x for x in range(0,3)] This hurt when I had to figure it out and the essence of perl seemed rife within: [(x,y) for x in range(0,3) for y in range(0,3)] And this just seemed to be a positively perlescent way of doing things: [(x,y) for x in range(0,4) if x is not 2 for y in range(0,4) if y is not 2] Yuck, yuck, yuck! And it isn't just me! I have a number of peers who have deep roots in CS, QA, and/or Project Management with whom we tend to discuss random computing issues.... every single one agreed that list comprehensions are mighty powerful, but have gnarly syntax that is not in line with the general "zen" of Python. The asterisk stuff seems to be a similar bit of syntactic magic that is equally as baffling to both the novice and to experienced Python programmers that have missed a year or two of the language's evolution. As a friend would say-- and not in a good way-- "That's positively Perlescent!". I know there isn't a snowballs chance in hell of these things changing anytime in the future... but before other similar features/extensions are added [dictionary comprehensions, for example], I beg of the community to step back and ask how much power is really gained in balance against the total confusion that may be caused? Python is a brilliant teaching tool-- I have taught OO programming to a number of people through the use of Python without them feeling overtly challenged by mechanics and esoterica that was outside of the focus of learning. Comprehensions and the asterisk notation have definitely taken away from the elegant simplicity of the language. Both very powerful constructs that I have grown relatively comfortable with. With power, comes a price... the result of using such constructs is that my code has become significantly less approachable by relative newcomers to Python-- including my co-workers. It also means that /usr/lib/python*/*.py has become less of a source of learning for folks new to python. There is a lot of power in the core set of functional API found in the builtins. Probably the most powerful feature of things like map/filter/apply/reduce are that they are easily approached and consumed by the Python newcomer, thereby making the language more attractive by making it easier to do powerful things without learning esoteric/alien syntax. (The other construct that bent my brain for a bit were generators-- only because of what they did, not because of the pythonic implementation. Very cool. I like generators.) b.bum

8 13

Re: [Python-Dev] Holes in time
by Guido van Rossum 03 Jan '03

03 Jan '03

> Tim & I spent some more time in front of a whiteboard today. We've > found a solution that takes the ValueError away. It needs to make > assumptions about what the tzinfo implementation does with the > impossible and ambiguous times at the DST switch points. Tim thinks > that this is the same solution that Aahz arrived at with han dwaving. ^^^^^^^^^^^ That's not Aahz's imaginary friend, it's a typo for hand waving. :-) --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

The meaning of __all__
by Jack Jansen 03 Jan '03

03 Jan '03

There's a discussion over on the pyobjc developers mailing list at the moment about the use of __all__. Some people suggested that for a certain module we only put "often used" items in __all__, so that "from module import *" will import only these commonly used items into your namespace. The module would contain other items which *are* useful and which should be callable from the outside, but these would have to be explicitly imported into your namespace (or used via "import objc; objc.SetVerbose()". This doesn't feel right to me, as I've always used __all__ to mean "the whole externally visible API", and I've considered anything else that the module exports basically an artefact of the implementation. But when I looked this up in the reference manual it is rather vague about this. Any opinions on the matter? -- Jack Jansen, <Jack.Jansen(a)cwi.nl>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman

4 3

RE: [Python-checkins] python/dist/src/Modules _randommodule.c,1.1,1.2
by Tim Peters 03 Jan '03

03 Jan '03

[nnorwitz(a)users.sourceforge.net] > Modified Files: > _randommodule.c > Log Message: > Try to get compilation working for cygwin > > Index: _randommodule.c And then, for example, before: > ! PyObject_GenericGetAttr, /*tp_getattro*/ and after: > ! 0, /*tp_getattro*/ followed by: > + Random_Type.tp_getattro = PyObject_GenericGetAttr; > + Random_Type.tp_alloc = PyType_GenericAlloc; > + Random_Type.tp_free = _PyObject_Del; in the module init function. Please don't make this kind of change -- it makes the code so much harder to follow. If this is needed for Cygwin, then, e.g., do #define DEFERRED(x) 0 /* some boxes can't resolve addresses at compile-time */ and make the "after" line DEFERRED(PyObject_GenericGetAttr), /*tp_getattro*/ IOW, the type slots should be readable on their own, as a static unit.

6 9