Re: [Python-Dev] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
I'm looking forward to an ordered dictionary in the standard library, especially for things like LRU caches. I was just reading the PEP, and caught this bit: "Does OrderedDict.popitem() return a particular key/value pair? Yes. It pops-off the most recently inserted new key and its corresponding value." Okay, but I'd also like a convenient and fast way to find the oldest entry in an OrderedDict, which I think I'd need for an LRU cache. Skimming the current patch (od7.diff), I didn't notice one. Perhaps I simply missed something. Shouldn't popitem() allow the caller to choose which end from which to pop? ___ Python-Dev mailing list [email protected] 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 372 -- Adding an ordered directory to collections ready for pronouncement
On Tue, March 3, 2009 11:54 am, Guido van Rossum wrote: > On Tue, Mar 3, 2009 at 11:20 AM, Forest wrote: >> Okay, but I'd also like a convenient and fast way to find the oldest >> entry >> in an OrderedDict, which I think I'd need for an LRU cache. Skimming >> the >> current patch (od7.diff), I didn't notice one. Perhaps I simply missed >> something. > > What's your use case? An LRU cache which occasionally needs to scan the oldest keys in the underlying odict to see if they should be purged. > If you really need this you can do it easily by taking the first key > returned by the iterator: Yep. I simply missed something. That's what I get for reading patches while hungry. :) ___ Python-Dev mailing list [email protected] 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 372 -- Adding an ordered directory to collections ready for pronouncement
On Tue, March 3, 2009 11:20 am, Forest wrote: > Okay, but I'd also like a convenient and fast way to find the oldest entry > in an OrderedDict, which I think I'd need for an LRU cache. Skimming the > current patch (od7.diff), I didn't notice one. Perhaps I simply missed > something. Shouldn't popitem() allow the caller to choose which end from > which to pop? Thinking it through a bit more, and LRU cache would actually need to access the oldest item before knowing whether to remove it. Besides, popitem() should probably retain the signature of dict.popitem(). I therefore retract my suggestion about popitem(). Still, I think an LRU cache would be a very common use case for an ordered dict. The current implementation already uses a list to keep track of order, which makes accessing the oldest key a simple matter of exposing it. Perhaps a new method like getfirst() would be worth while here? ___ Python-Dev mailing list [email protected] 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 372 -- Adding an ordered directory to collections ready for pronouncement
Raymond Hettinger wrote: > [Forest] >> Perhaps a new method like getfirst() would be worth while here? > > Guido already gave you a way to access the first item using the existing > API. > Using next(iter(d)) also works. Yep. I think messages are arriving out of order. -1 on my own suggestion. ___ Python-Dev mailing list [email protected] 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 372 -- Adding an ordered directory to collections ready for pronouncement
On Wed, Wed, 4 Mar 2009 13:52:59 -0800, Guido van Rossum wrote: > On Wed, Mar 4, 2009 at 1:44 PM, Greg Ewing > wrote: >> [email protected] wrote: >> >>> I actually like StableDict best. ?When I hear that I think, "ah, the >>> key order is stable in the face of insertions, unlike a regular dict". >> >> But it still doesn't convey what the ordering actually *is*. > > Please, stick with OrderedDict. That's the name used historically by > most people who independently reinvented this functionality. It's also what I typed into google and PYPI when I went looking for this functionality. +1 for odereddict or odict or OrderedDict. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Epoch and Platform
ISTR using a Microsoft C compiler in the early/mid 1990s whose runtime library used an unusual epoch. I don't recall any others straying from the Unix way, but then again, I haven't been looking for such quirks. Guido wrote: > > ISTR that we force the epoch to be 1970 on all major platforms -- or > perhaps it happens to be 1970 even on Windows when using MS's C > runtime. > > On Mon, Jun 16, 2008 at 4:08 PM, Curt Hagenlocher <[EMAIL PROTECTED]> > wrote: >> The documentation for the time module says that "the epoch is the point >> where the time starts. On January 1st of that year, at 0 hours, the >> ``time >> since the epoch'' is zero. For Unix, the epoch is 1970. To find out what >> the >> epoch is, look at gmtime(0)." This confirms that the epoch is >> platform-specific. As such, the only legal uses of the timestamp should >> be >> >> 1) comparing with another timestamp to determine elapsed time in seconds >> 2) passing to another standard Python library function which expects a >> timestamp >> 3) as a source of randomness. >> >> However, the following files in the standard library have hardcoded the >> assumption that the Python epoch will always be the same as the Unix >> epoch: >> In gzip.py, method GzipFile._write_gzip_header >> In tarfile.py, method _Stream._init_write_gz >> In uuid.py, function uuid1 >> >> Additionally, the following files in the standard library have hardcoded >> the >> assumption that the Python epoch will cause timestamps to fall within >> the >> range of a 32-bit unsigned integer value: >> In imputil.py, function _compile >> In py_compile.py, function compile >> >> So there's some kind of a potential discrepancy here, albeit a minor >> one. >> This discrepancy can be resolved in one of at least three ways: >> >> 1) The documentation for the time module is wrong, and the epoch for >> Python >> (at least versions 2.x) should be the Unix epoch. >> 2) These library functions are slightly wrong and should be modified by >> subtracing an "epoch offset" before doing other calculations. This >> offset >> can be calculated as "time.mktime((1970, 1, 1, 0, 0, 0, 3, 1, 0)) - >> time.timezone". >> 3) These library files should be considered part of the >> platform-specific >> implementation, and an alternate platform should provide its own version >> of >> these files if necessary. >> >> Any thoughts on this? >> >> From the perspective of implementing IronPython, I'd prefer that the >> answer >> is 1 or 2 -- but mainly I just want to be as compatible with "the spec" >> as >> possible, while respecting CLR-specific norms for functionality which is >> left up to individual implementations. >> >> -- >> Curt Hagenlocher >> [EMAIL PROTECTED] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] new ssl module is incompatible with servers that drop privileges
I've been trying out the new ssl module, and I love it so far, except for the way it accepts private keys and certificates. It accept them only as paths to their location on the file system, which I believe means that a server can only support SSL if it has read permission to its private key file when client connections arrive. This is a problem for servers that bind to their socket and drop privileges as soon as they start up, a practice that is both common and recommended in the unix world. IMHO, this severely limits the new ssl module's utility, and discourages good security practices. Wouldn't it be better if we could specify keys and certificates as bytes or file-like objects? This would solve the security issue, give applications more flexibility in key management, and might also improve performance slightly (by avoiding file system operations at accept() time). Perhaps there's a workaround that I haven't noticed yet? A quick look at the source code didn't reveal any obvious way to specify keys other than as paths in the file system. http://bugs.python.org/issue3823 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] new ssl module is incompatible with servers that drop privileges
On Tue, September 9, 2008 12:49 pm, Bill Janssen wrote: >> IMHO, this severely limits the new ssl module's utility, and discourages >> good security practices. > > Please file a bug report. A bug report with a patch and tests would > be even better :-). Assign it to me. I filed one, but the bug tracker doesn't seem to offer a way to assign it to you. I'll add you to the nosy list. http://bugs.python.org/issue3823 I'm pretty swamped right now, so I don't think I can learn the code well enough to make a patch in the few weeks before python 2.6 is released. (How nice it would be if the debut of this very useful module was free of this problem!) If I find some unexpected free time, I'll take a crack at it. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
