Re: [Python-Dev] calendar.timegm
On Tue, 2006-02-21 at 22:47 -0600, [EMAIL PROTECTED] wrote: > Sergey> Historical question ;) > > Sergey> Anyone can explain why function timegm is placed into module > Sergey> calendar, not to module time, where it would be near with > Sergey> similar function mktime? > > Historical accident. ;-) It seems time contains a simple wrapper around the equivalent C functions. There is no C equivalent to timegm() (how do they do it?). The timegm() function is implemented in python using the datetime module. The name sux BTW. It would be nice if there was a time.mkgmtime(), but it would need to be implemented in C. -- Donovan Baarda <[EMAIL PROTECTED]> http://minkirri.apana.org.au/~abo/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defaultdict proposal round three
Greg Ewing wrote: Fredrik Lundh wrote: fwiw, the first google hit for "autodict" appears to be part of someone's link farm At this website we have assistance with autodict. In addition to information for autodict we also have the best web sites concerning dictionary, non profit and new york. Hmmm, looks like some sort of bot that takes the words in your search and stuffs them into its response. I wonder if they realise how silly the results end up sounding? I've seen these sorts of things before, but I haven't quite figured out yet how they manage to get into Google's database if they're auto-generated. Anyone have any clues what goes on? I guess the question is, how would google know *not* to index them ? As soon as they are linked to (or more likely they re-use an expired domain name that is already in the google database) they will be indexed. They may be obviously autogenerated to a human, but it's a lot harder for a computer to tell. It seems that google indexes sites of dubious value - but gives them a low pagerank. This means they do appear in results, but only if there is nothing more relevant available. All the best, Michael Foord ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buildbot, and test failures
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Anthony Baxter wrote: >> I >> have an Ubuntu x86 box here that can become one (I think the only >> linux, currently, is Gentoo...) > > How different are the Linuxes, though? How many of them do we need? Actually, we would need enough to cover the libc/gcc combinations that are most common. This isn't feasible, though, so in case we add more Linux machines, at least make sure that the libc/gcc combo is not one already used in the existing ones. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buildbot, and test failures
Christos> This isn't feasible, though, so in case we add more Linux Christos> machines, at least make sure that the libc/gcc combo is not Christos> one already used in the existing ones. Maybe include libc/gcc versions in the name or description? Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Pre-PEP: The "bytes" object
On 2/22/06, Neil Schemenauer <[EMAIL PROTECTED]> wrote: @classmethoddef fromhex(self, data):data = "" '', data)return bytes(binascii.unhexlify(data))If it's to be a classmethod, I guess that should be "return self( binascii.unhexlify(data))".-j ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using and binding relative names (was Re: PEP for Better Control of Nested Lexical Scopes)
Phillip J. Eby wrote: > At 03:49 PM 2/23/2006 +1300, Greg Ewing wrote: >>Steven Bethard wrote: >> > And, as you mention, it's consistent >> > with the relative import feature. >> >>Only rather vaguely -- it's really somewhat different. >> >>With imports, .foo is an abbreviation for myself.foo, >>where myself is the absolute name for the current module, >>and you could replace all instances of .foo with that. > > Actually, "import .foo" is an abbreviation for "import myparent.foo", not > "import myparent.myself.foo". Actually, "import .foo" won't work anyway. nitpicking-ly yours, Georg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Using and binding relative names (was Re: PEP for Better Control of Nested Lexical Scopes)
On 2/22/06, Almann T. Goo <[EMAIL PROTECTED]> wrote: > Since the current semantics allow *evaluation* to an enclosing scope's > name by an "un-punctuated" name, "var" is a synonym to ".var" (if > "var" is bound in the immediately enclosing scope). However for > *re-binding* to an enclosing scope's name, the "punctuated" name is > the only one we can use, so the semantic becomes more cluttered. > > This can make a problem that I would say is akin to the "dangling else > problem." > > def incrementer_getter(val): >def incrementer(): >val = 5 >def inc(): >..val += 1 >return val >return inc >return incrementer > > Building on an example that Steve wrote to demonstrate the syntax > proposed, you can see that if a user inadvertently uses the enclosing > scope for the return instead of what would presumably be the outer > most bound parameter. Now remove the binding in the incrementer > function and it works the way the user probably thought. Sorry, what way did the user think? I'm not sure what you think was supposed to happen. STeVe -- Grammar am for people who can't think for myself. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Path PEP: some comments (equality)
On 2/20/06, Mark Mc Mahon <[EMAIL PROTECTED]> wrote: > Hi, > > It seems that the Path module as currently defined leaves equality > testing up to the underlying string comparison. My guess is that this > is fine for Unix (maybe not even) but it is a bit lacking for Windows. > > Should the path class implement an __eq__ method that might do some of > the following things: > - Get the absolute path of both self and the other path > - normcase both > - now see if they are equal > > This would make working with paths much easier for keys of a > dictionary on windows. (I frequently use a case insensitive string > class for paths if I need them to be keys of a dict.) The PEP specifies path.samefile(), which is useful in the case of files that actually exist, but pretty much useless for comparing paths that don't exist on the local machine. I think leaving __eq__ as the default string comparison is best. But what about providing an alternate platform-specific equality test? def isequal(self, other, platform="native"): """Return True if self is equivalent to other using platform's path comparison rules. platform can be one of "native", "posix", "windows", "mac".""" This could do some combination of os.path.normpath() and os.path.normcase() depending on the platform. The docs for os.path.normpath() say that it may change the meaning of the path if it contains symlinks...it's not clear to me how though. Cheers, Chris ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defaultdict and on_missing()
On 2/22/06, Michael Chermside <[EMAIL PROTECTED]> wrote: > A minor related point about on_missing(): > > Haven't we learned from regrets over the .next() method of iterators > that all "magically" invoked methods should be named using the __xxx__ > pattern? Shouldn't it be named __on_missing__() instead? Good point. I'll call it __missing__. I've uploaded a new patch to python.org/sf/1433928. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for Better Control of Nested Lexical Scopes
On Thu, Feb 23, 2006 at 05:25:30PM +1300, Greg Ewing wrote: > Samuele Pedroni wrote: > > > If you are looking for rough edges about nested scopes in Python > > this is probably worse: > > > > >>> x = [] > > >>> for i in range(10): > > ... x.append(lambda : i) > > ... > > >>> [y() for y in x] > > [9, 9, 9, 9, 9, 9, 9, 9, 9, 9] > > As an aside, is there any chance that this could be > changed in 3.0? I.e. have the for-loop create a new > binding for the loop variable on each iteration. You can't do that without introducing a whole new scope for the body of the 'for' loop, and that means (in the current rules) you can't assign to any function-local names in the for loop. The nested scope in that 'lambda' refers to the 'slot' for the variable 'i' in the outer namespace (in this case, the global one.) You can't 'remove' the binding, either; 'del' will not allow you to. -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] getdefault(), the real replacement for setdefault()
On Wed, Feb 22, 2006 at 10:29:08PM -0500, Barry Warsaw wrote:
> d.getdefault('foo', list).append('bar')
> Anyway, I don't think it's an either/or choice with Guido's subclass.
> Instead I think they are different use cases. I would add getdefault()
> to the standard dict API, remove (eventually) setdefault(), and add
> Guido's subclass in a separate module. But I /wouldn't/ clutter the
> built-in dict's API with on_missing().
+1. This is a much closer match to my own use of setdefault than Guido's
dict subtype. I'm +0 on the subtype, but I prefer the call-time decision on
whether to fall back to a default or not.
--
Thomas Wouters <[EMAIL PROTECTED]>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defaultdict and on_missing()
On Wed, Feb 22, 2006 at 01:13:28PM -0800, Michael Chermside wrote: > Haven't we learned from regrets over the .next() method of iterators > that all "magically" invoked methods should be named using the __xxx__ > pattern? Shouldn't it be named __on_missing__() instead? I agree that on_missing should be __missing__ (or __missing_key__) but I don't agree on the claim that all 'magically' invoked methods should be two-way-double-underscored. __methods__ are methods that should only be called 'magically', or by the object itself. 'next' has quite a few usecases where it's desireable to call it directly (and I often do.) -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defaultdict and on_missing()
Guido van Rossum wrote: > On 2/22/06, Michael Chermside <[EMAIL PROTECTED]> wrote: >> A minor related point about on_missing(): >> >> Haven't we learned from regrets over the .next() method of iterators >> that all "magically" invoked methods should be named using the __xxx__ >> pattern? Shouldn't it be named __on_missing__() instead? > > Good point. I'll call it __missing__. I've uploaded a new patch to > python.org/sf/1433928. I always thought that __magic__ method calls are done by Python on objects it doesn't know about. The special method name ensures that it is indeed the protocol Python is talking about, not some random method (with next() being the exception). In the defaultdict case this isn't a problem, because defaultdict is calling its own method. Bye, Walter Dörwald ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] bytes.from_hex()
Stephen J. Turnbull wrote: > Please define "character," and explain how its semantics map to > Python's unicode objects. One of the 65 abstract entities referred to in the RFC and represented in that RFC by certain visual glyphs. There is a subset of the Unicode code points that are conventionally associated with very similar glyphs, so that there is an obvious one-to-one mapping between these entities and those Unicode code points. These entities therefore have a natural and obvious representation using Python unicode strings. > No, base64 isn't a wire protocol. Rather, it's a schema for a family > of wire protocols, whose alphabets are heuristically chosen on the > assumption that code units which happen to correspond to alpha-numeric > code points in a commonly-used coded character set are more likely to > pass through a communication channel without corruption. Yes, and it's up to the programmer to choose those code units (i.e. pick an encoding for the characters) that will, in fact, pass through the channel he is using without corruption. I don't see how any of this is inconsistent with what I've said. > Only if you do no transformations that will harm the base64-encoding. > ... It doesn't allow any of the > usual transformations on characters that might be applied globally to > a mail composition buffer, for example. I don't understand that. Obviously if you rot13 your mail message or turn it into pig latin or something, it's going to mess up any base64 it might contain. But that would be a silly thing to do to a message containing base64. Given any piece of text, there are things it makes sense to do with it and things it doesn't, depending entirely on the use to which the text will eventually be put. I don't see how base64 is any different in this regard. > So then you bring it right back in with base64. Now they need to know > about bytes<->unicode codecs. No, they need to know about the characteristics of the channel over which they're sending the data. Base64 is designed for situations in which you have a *text* channel that you know is capable of transmitting at least a certain subset of characters, where "character" means whatever is used as input to that channel. In Py3k, text will be represented by unicode strings. So a Py3k text channel should take unicode as its input, not bytes. I think we've got a bit sidetracked by talking about mime. I wasn't actually thinking about mime, but just a plain text message into which some base64 data was being inserted. That's the way we used to do things in the old days with uuencode etc, before mime was invented. Here, the "channel" is NOT the socket or whatever that the ultimate transmission takes place over -- it's the interface to your mail sending software that takes a piece of plain text and sends it off as a mail message somehow. In Py3k, if a channel doesn't take unicode as input, then it's not a text channel, and it's not appropriate to be using base64 with it directly. It might be appropriate to to use base64 followed by some encoding, but the programmer needs to be aware of that and choose the encoding wisely. It's not possible to shield him from having to know about encodings in that situation, even if the encoding is just ascii. Trying to do so will just lead to more confusion, in my opinion. Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] OT: T-Shirts
Python Argentina finally have T-Shirts (you can see a photo here: http://www.taniquetil.com.ar/plog/post/1/161). Why this mail to python-dev? Because the group decided to give some, as a present, to some outstanding members of Python: Guido van Rossum Alex Martelli Tim Peters Fredrik Lundh David Ascher Mark Lutz Mark Hammond Also, some of us want to give one as a personal present: Raymond Hettinger (from Facundo Batista) Bob Ippolito (from Alejandro David Weil) Glyph Lefkowitz (from Alejandro J. Cura) The point is that I don't know some of you, so please grab my shoulder here in PyCon. And if you're not coming to the conference but somebody can carry it to you, just let me know. And if you want to buy one, I brought some, only USD 12, ;). Thank you very much and sorry for the OT. Regards, .Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defaultdict and on_missing()
Walter Dörwald writes: > I always thought that __magic__ method calls are done by Python on > objects it doesn't know about. The special method name ensures that it > is indeed the protocol Python is talking about, not some random method > (with next() being the exception). In the defaultdict case this isn't a > problem, because defaultdict is calling its own method. I, instead, felt that the __xxx__ convention served a few purposes. First, it indicates that the method will be called in some means OTHER than by name (generally, the interpreter invokes it directly, although in this case it's a built-in method of dict that would invoke it). Secondly, it serves to flag the method as being special -- true newbies can safely ignore nearly all special methods aside from __init__(). And it serves to create a separate namespace... writers of Python code know that names beginning and ending with double-underscores are "reserved for the language". Of these, I always felt that special invocation was the most important feature. The next() method of iterators was an interesting object lesson. The original reasoning (I think) for using next() not __next__() was that *sometimes* the method was called directly by name (when stepping an iterator manually, which one frequently does for perfectly good reasons). Since it was sometimes invoked by name and sometimes by special mechanism, the choice was to use the unadorned name, but later experience showed that it would have been better the other way. -- Michael Chermside ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] OT: T-Shirts
On Feb 23, 2006, at 6:12 PM, Facundo Batista wrote: > Python Argentina finally have T-Shirts (you can see a photo here: > http://www.taniquetil.com.ar/plog/post/1/161). > > Why this mail to python-dev? Because the group decided to give some, > as a present, to some outstanding members of Python: > > Guido van Rossum > Alex Martelli T-shirts? I'm an absolute fan of T-shirts...!-) > The point is that I don't know some of you, so please grab my shoulder > here in PyCon. And if you're not coming to the conference but somebody > can carry it to you, just let me know. Anna can bring mine!!! > And if you want to buy one, I brought some, only USD 12, ;). Anna, please buy one for yourself before they run out -- they're cool, and this way we can go around as the AR (Anna Ravenscroft, of course!) Python Twins...!-) Alex ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defaultdict and on_missing()
Michael Chermside wrote: > The next() method of iterators was an interesting > object lesson. ... Since it was sometimes invoked by name > and sometimes by special mechanism, the choice was to use the > unadorned name, but later experience showed that it would have been > better the other way. Any thoughts about fixing this in 3.0? -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] defaultdict and on_missing()
Thomas Wouters wrote: > __methods__ are methods that should only be > called 'magically', or by the object itself. > 'next' has quite a few usecases where it's > desireable to call it directly That's why the proposal to replace .next() with .__next__() comes along with a function next(obj) which calls obj.__next__(). -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP for Better Control of Nested Lexical Scopes
Thomas Wouters wrote: > On Thu, Feb 23, 2006 at 05:25:30PM +1300, Greg Ewing wrote: > >>As an aside, is there any chance that this could be >>changed in 3.0? I.e. have the for-loop create a new >>binding for the loop variable on each iteration. > > You can't do that without introducing a whole new scope for the body of the > 'for' loop, There's no need for that. The new scope need only include the loop variable -- everything else could still refer to the function's main scope. There's even a rather elegant way of implementing this in the current CPython. If a nested scope references the loop variable, then it will be in a cell. So you just create a new cell each time round the loop, instead of changing the existing one. This would even still let you use the value after the loop finished, if that were considered a good idea. But it might be better not to allow that, since it could make alternative implementations difficult. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
