Armin Ronacher <[EMAIL PROTECTED]> wrote:
> I like the python import system but it's limited at some point. Imagine you
> have
> a large application with a plugin system and you want plugins to appear below
> `applicationname.plugins` (Me and the pocoo team encountered that issue some
> time ago
[redirecting to the py3k list where this belongs]
On 1/16/07, Tim Delaney <[EMAIL PROTECTED]> wrote:
> Phillip J. Eby wrote:
>
> > To be honest, the items() and keys() thing personally baffles me. If
> > they're supposed to be *views* on the underlying dictionary, wouldn't
> > it
> > make more se
Guido van Rossum wrote:
> I find it hard to explain, but my gut feeling is that using an
> attribute instead of a method would be a mistake here. In the past
> I've paid deerly for ignoring my gut feelings (about language design
> as well as about other things) so I'd rather wait until a rational
Of course, the purpose of using ABCs is to allow easy inspection of
the capabilities of an object, and for some objects, the state can be
an important part. But don't be misled to confuse ABCs with simply
type-based function dispatch. They're useful for other things as
well.
I think that statefu
Other than dict.items (and .keys and .values) returning a non-list,
are there any other cases where the Py3K idiom can't already be used
in (or at least backported to) Py 2.x?
Is there a chance that this special case could be handled by an import
hook in py 2.6?
For example 2.6 could have an addi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 16, 2007, at 5:04 PM, Jim Jewett wrote:
> Other than dict.items (and .keys and .values) returning a non-list,
> are there any other cases where the Py3K idiom can't already be used
> in (or at least backported to) Py 2.x?
I know Guido is again
