[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 know that there actually 
*is* a cache involved, which simply has the same name as the function. So 
this will likely encourage users to add a half-way redundant comment like 
"clear the cache" to their code.


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.

Stefan


___
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 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 pseudo-namespacing: get_phone_number.cache_hits,
get_phone_number.clear_cache()

Regards

___
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 LRU cache API in Py3.2

2010-09-04 Thread 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_phone_number.cache.clear()
> > 
> > ?
> > 
> > It's just a little more overhead, but I think it reads quite a bit better.
> 
> Or we could use pseudo-namespacing: get_phone_number.cache_hits,
> get_phone_number.clear_cache()

It looks better indeed.

Regards

Antoine.


___
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 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  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 little more overhead, but I think it reads quite a bit better.
>> 
>> Or we could use pseudo-namespacing: get_phone_number.cache_hits,
>> get_phone_number.clear_cache()
> 
> It looks better indeed.

+1.

Georg

-- 
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of thy
indenting shall be four. Eight shalt thou not indent, nor either indent thou
two, excepting that thou then proceed to four. Tabs are right out.

___
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 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 broadly true, then a middle-ground may be for Python to
> expose something like Py_fopen, Py_fclose and a PyFILE opaque "handle".
>  API elements which currently take a FILE * could be exposed using a
> PyFILE * in the ABI.  People who didn't care about this level of
> portability could continue to use the non-ABI FILE * functions, but
> people who do could use Py_fopen/Py_fclose in place of fopen/fclose but
> otherwise work as now.

I don't think this would solve the problem; see above.

Regards,
Martin
___
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 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
___
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 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 Windows doesn't handle it correctly then
> it's a Windows issue and we shouldn't annoy other people by refusing
> access to that feature.

The point of the PEP is specifically to solve Python versioning
problems *ON WINDOWS*. It would be pointless if it didn't have that
effect.

If you think it doesn't affect you, then you can just ignore the stable
ABI.

> After all, we don't usually try to workaround platform-specific
> bugs (not as a low level such as the C API level); at worse, we mention
> their existence in the docs.

Yes, and that policy is an ongoing annoyance, one that PEP 384 tries
to remedy.

Only after I wrote the PEP, I learned that it can have uses for Linux
distributions, too.

Regards,
Martin
___
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 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 precautions that you never ever do.
For example, distutils will, by default, refuse to use a different
compiler.

Regards,
Martin
___
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] 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: Extensions that want to stick to the stable ABI should really
> not have to know whether Py_UNICODE maps to wchar_t or not. If they
> want to interface to a local whcar_t type they can use the conversion
> APIs we have for that in the Unicode API: PyUnicode_FromWideChar()
> and PyUnicode_AsWideChar().

Ok. I'm fine with excluding Py_UNICODE from the stable ABI. However,
I think in the long run, I guess more support for wchar_t will then
be needed in the API, e.g. more convenient argument parsing.

Regards,
Martin
___
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 384 status

2010-09-04 Thread Antoine Pitrou 
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* you compile with a different compiler.
> That's why we take serious precautions that you never ever do.
> For example, distutils will, by default, refuse to use a different
> compiler.

Thanks for the explanations.

Regards

Antoine.
___
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 LRU cache API in Py3.2

2010-09-04 Thread Daniel Stutzbach 
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 just as a decorator.  It
could provide a wrap() method to be used as a decorator (or implement
__call__ to keep the current semantics, but explicit is better than
implicit)

widget_cache = lru_cache()
widget_cache[name] = widget

@lru_cache().wrap
def get_thingy(name):
return something(name)

# get_thingy.cache is an lru_cache instance
print(get_thingy.cache.hits)

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 multiple functions that want to talk to the cache.
--
Daniel Stutzbach, Ph.D.
President, Stutzbach Enterprises, LLC 
___
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 LRU cache API in Py3.2

2010-09-04 Thread Antoine Pitrou 
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 multiple functions that want to talk to the cache.

Well, perhaps lru_cache() would have deserved a review before
committing?

Regards

Antoine.


___
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 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.  Its design reflects feedback from a variety
of advanced python users (the keyword argument support
from Miki Tebeka, the concurrency support from Jim Baker, 
the clearing option and introspectability from Nick Coghlan, etc).
Aside from the compact API, the actual implementation
is so dirt simple that it will be trivial for folks to roll their
own variants if they have more exotic needs.  After I'm 
done with other work for the alpha, I'll take a further 
look at the suggestions here.


Raymond


___
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 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  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_number.cache_hits,
>>> get_phone_number.clear_cache()
>> 
>> It looks better indeed.
> 
> +1.

Those seem like reasonable names.


Raymond
___
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