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
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!
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
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
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
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
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
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
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
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
-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:
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
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
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
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 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:
16 matches
Mail list logo