Re: [Python-Dev] 3.2 What's New

2010-09-04 Thread Georg Brandl
Am 04.09.2010 01:40, schrieb Victor Stinner: Le samedi 04 septembre 2010 00:52:38, Georg Brandl a écrit : For this weekend's 3.2a2, it would be rather nice to have some more coverage of changes in the document, since it is the main thing people will look at when determining whether to download

Re: [Python-Dev] 3.2 What's New

2010-09-04 Thread Georg Brandl
Am 04.09.2010 01:26, schrieb Raymond Hettinger: On Sep 3, 2010, at 3:52 PM, Georg Brandl wrote: Hi, I'm not sure what the arrangement for the What's New in Python 3.2 document is; especially if either Andrew or Raymond still feel in charge for it. I'm already working on it. Thanks!

[Python-Dev] new LRU cache API in Py3.2

2010-09-04 Thread Stefan Behnel
Hi, reading the description of the new LRU cache in the What's new in 3.2 document now, I got the impression that the hits/misses attributes and the .clear() method aren't really well namespaced. When I read get_phone_number.clear() it's not very obvious to me what happens, unless I

Re: [Python-Dev] new LRU cache API in Py3.2

2010-09-04 Thread Éric Araujo
What about adding an intermediate namespace called cache, so that the new operations are available like this: print get_phone_number.cache.hits get_phone_number.cache.clear() ? It's just a little more overhead, but I think it reads quite a bit better. Or we could use

Re: [Python-Dev] new LRU cache API in Py3.2

2010-09-04 Thread Antoine Pitrou
On Sat, 04 Sep 2010 11:42:08 +0200 Éric Araujo mer...@netwok.org wrote: What about adding an intermediate namespace called cache, so that the new operations are available like this: print get_phone_number.cache.hits get_phone_number.cache.clear() ? It's just a

Re: [Python-Dev] new LRU cache API in Py3.2

2010-09-04 Thread Georg Brandl
Am 04.09.2010 12:06, schrieb Antoine Pitrou: On Sat, 04 Sep 2010 11:42:08 +0200 Éric Araujo mer...@netwok.org wrote: What about adding an intermediate namespace called cache, so that the new operations are available like this: print get_phone_number.cache.hits

Re: [Python-Dev] PEP 384 status

2010-09-04 Thread Martin v. Löwis
It would be interesting to know how, in practice, these FILE pointers come to life. In my experience they are generally obtained via fopen. I think that experience can't be generalized. I personally guess that in most cases, the FILE* being passed across CRT boundaries is stdout. If that is

Re: [Python-Dev] PEP 384 status

2010-09-04 Thread Martin v. Löwis
This sounds like the issues such a mix can cause are mostly theoretical and don't really bother much in practice, so PEP 384 on Windows does have a chance :-) Actually, the CRT issues (FILE* in particular) have been causing real crashes for many years, for many people. Regards, Martin

Re: [Python-Dev] PEP 384 status

2010-09-04 Thread Martin v. Löwis
What I think would be a mistake would be to define the API in terms of Windows-specific quirks. All this discussion seems bent on satisfying the needs of Windows developers at the expense of non-Windows developers. FILE* is a perfectly standard C feature (and a widely-used one at that). If

Re: [Python-Dev] PEP 384 status

2010-09-04 Thread Martin v. Löwis
Please consider this: even without relying on PEP 384, using FILE* is /already/ dangerous; because you might compile an extension with a different compiler version than Python was compiled with. It's only dangerous *if* you compile with a different compiler. That's why we take serious

Re: [Python-Dev] versioned .so files for Python 3.2

2010-09-04 Thread Martin v. Löwis
-1 on always using wchar_t as well. Python's default is UCS2 and the stable ABI should not change that. It's not really Python's default. It is what configure.in does by default. Python's default, on Linux, is UCS-4. I also think that this information is not relevant for the stable ABI:

Re: [Python-Dev] PEP 384 status

2010-09-04 Thread Antoine Pitrou
On Sat, 04 Sep 2010 15:13:55 +0200 Martin v. Löwis mar...@v.loewis.de wrote: Please consider this: even without relying on PEP 384, using FILE* is /already/ dangerous; because you might compile an extension with a different compiler version than Python was compiled with. It's only

Re: [Python-Dev] new LRU cache API in Py3.2

2010-09-04 Thread Daniel Stutzbach
On Sat, Sep 4, 2010 at 3:28 AM, Stefan Behnel stefan...@behnel.de wrote: What about adding an intermediate namespace called cache, so that the new operations are available like this: I had been thinking that the lru_cache should be a class (with a dict-like interface), so it can be used

Re: [Python-Dev] new LRU cache API in Py3.2

2010-09-04 Thread Antoine Pitrou
On Sat, 4 Sep 2010 09:21:25 -0500 Daniel Stutzbach dan...@stutzbachenterprises.com wrote: I have been using a similar LRU cache class to store items retrieved from a database. In my case, a decorator-paradigm wouldn't work well because I only want to cache a few of the columns from a much

Re: [Python-Dev] new LRU cache API in Py3.2

2010-09-04 Thread Raymond Hettinger
On Sep 4, 2010, at 11:20 AM, Antoine Pitrou wrote: Well, perhaps lru_cache() would have deserved a review before committing? Not everything needs to be designed by committee. This API is based on one that was published as a recipe several years ago and has been used in a number of companies.

Re: [Python-Dev] new LRU cache API in Py3.2

2010-09-04 Thread Raymond Hettinger
On Sep 4, 2010, at 3:15 AM, Georg Brandl wrote: Am 04.09.2010 12:06, schrieb Antoine Pitrou: On Sat, 04 Sep 2010 11:42:08 +0200 Éric Araujo mer...@netwok.org wrote: It's just a little more overhead, but I think it reads quite a bit better. Or we could use pseudo-namespacing: