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 wrote:
It's just a little more overhead, but I think it reads quite a bit better.
>>>
>>> Or we could use pseudo-namespacing: get_phone_
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.
On Sat, 4 Sep 2010 09:21:25 -0500
Daniel Stutzbach 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 larger query, plus there
> are
On Sat, Sep 4, 2010 at 3:28 AM, Stefan Behnel 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 explicitly and not j
On Sat, 04 Sep 2010 15:13:55 +0200
"Martin v. Löwis" 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 dangerous *if*
> -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: E
> 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 precau
> 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).
> 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
> 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 i
Am 04.09.2010 12:06, schrieb Antoine Pitrou:
> On Sat, 04 Sep 2010 11:42:08 +0200
> Éric Araujo 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_ph
On Sat, 04 Sep 2010 11:42:08 +0200
Éric Araujo 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 lit
> 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
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 kn
14 matches
Mail list logo
