From lists at cheimes.de  Thu Jul 12 17:43:25 2007
From: lists at cheimes.de (Christian Heimes)
Date: Thu, 12 Jul 2007 17:43:25 +0200
Subject: [Python-ideas] C# style properties
Message-ID: <f75i6v$g1$1@sea.gmane.org>

Hello!

In the past few months I've been toying around with .NET, C# and
PythonNet. While I still think that C# is too wory (public static
explicit operator Egg(Spam spam) { ... }) C# has one syntax feature I
really like to see in Python.

private float _a
public float a
{
    get { return _a; }
    set { _a = value; }
}

I think it's a very nice way to define a variable that acts similar to
Python properties. get, set and value are part of the syntax.

Python has no nice way to define a property with set and get. You always
have to use lambda or some private methods.

class Now:
    _a = 0.0
    @property
    def a(self):
        """Read only property
        return self._a

    def _geta(self):
        return self._a
    def _seta(self, value):
        self._a = value
    a = property(_geta, _seta)

It puts a lot of methods into the body of the class that are only used
for properties. I find the C# syntax more intriguing. It puts the getter
and setter into a block of their own and makes reading and understand
the property more easy.

What do you think about this syntax?

class EasyExample:
    _a = 0.0
    property a:
        """doc string
        """
        def get(self) -> float:
            return self._a
        def set(self, value):
            self._a = float(value)
        def delete(self):
            del self._a

It may be possible to combine the feature with generic methods but I
guess that's not going to be easy.

class ComplexExample:
    _a = 0.0
    property a:
        """doc string
        """
        def get(self) -> float:
            return self._a

        @generic
        def set(self, value:float):
            self._a = value

        @generic
        def set(self, value:int):
            self._a = float(value)

        @generic
        def set(self, value:str):
            self._a = float(value)

        def delete(self):
            del self._a

An alternative syntax. It doesn't look as clean as the other syntax but
has the benefit that the variable is in front of the definition.

class AlternativeSyntax:
    _a = 0.0
    a = property:
        """doc string
        """

Comments?

Christian



From steven.bethard at gmail.com  Thu Jul 12 18:40:15 2007
From: steven.bethard at gmail.com (Steven Bethard)
Date: Thu, 12 Jul 2007 10:40:15 -0600
Subject: [Python-ideas] C# style properties
In-Reply-To: <f75i6v$g1$1@sea.gmane.org>
References: <f75i6v$g1$1@sea.gmane.org>
Message-ID: <d11dcfba0707120940l4e258724oa1afbe6580099957@mail.gmail.com>

On 7/12/07, Christian Heimes <lists at cheimes.de> wrote:
> What do you think about this syntax?
>
> class EasyExample:
>     _a = 0.0
>     property a:
>         """doc string
>         """
>         def get(self) -> float:
>             return self._a
>         def set(self, value):
>             self._a = float(value)
>         def delete(self):
>             del self._a

I'm pretty sure Guido's said before that he doesn't like the
get/set/del methods being indented more than other instance methods
would be. If you really like this style, you can get something like it
today using inner classes:

    http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/442418

Steve
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy


From jcarlson at uci.edu  Thu Jul 12 18:51:15 2007
From: jcarlson at uci.edu (Josiah Carlson)
Date: Thu, 12 Jul 2007 09:51:15 -0700
Subject: [Python-ideas] C# style properties
In-Reply-To: <f75i6v$g1$1@sea.gmane.org>
References: <f75i6v$g1$1@sea.gmane.org>
Message-ID: <20070712094423.8C73.JCARLSON@uci.edu>


Christian Heimes <lists at cheimes.de> wrote:
> 
> Hello!
> 
> In the past few months I've been toying around with .NET, C# and
> PythonNet. While I still think that C# is too wory (public static
> explicit operator Egg(Spam spam) { ... }) C# has one syntax feature I
> really like to see in Python.
> 
> private float _a
> public float a
> {
>     get { return _a; }
>     set { _a = value; }
> }
[snip]
> Comments?

Python has an exact equivalent to the C# method (which uses a new
block/scope for defining properties...)

    class foo:
        class a(Property):
            ''' documentation '''
            def get(self):
                return self._a
            def set(self, val):
                self._a = val
            def de1(self):
                del self._a


Now all you need is a Property base class with a proper metaclass that
handles all of the magic for you.  I'm curious as to why this still gets
brought up when the obvious syntax is more or less identical to
basically all reasonable alternate syntaxes.  Is it because people don't
understand that metaclasses can mangle your class any way they want?


 - Josiah



From george.sakkis at gmail.com  Thu Jul 12 19:20:09 2007
From: george.sakkis at gmail.com (George Sakkis)
Date: Thu, 12 Jul 2007 13:20:09 -0400
Subject: [Python-ideas] C# style properties
In-Reply-To: <d11dcfba0707120940l4e258724oa1afbe6580099957@mail.gmail.com>
References: <f75i6v$g1$1@sea.gmane.org>
	<d11dcfba0707120940l4e258724oa1afbe6580099957@mail.gmail.com>
Message-ID: <91ad5bf80707121020k3a4bea97jf8bbb3f58ec4304b@mail.gmail.com>

On 7/12/07, Steven Bethard <steven.bethard at gmail.com> wrote:

> On 7/12/07, Christian Heimes <lists at cheimes.de> wrote:
> > What do you think about this syntax?
> >
> > class EasyExample:
> >     _a = 0.0
> >     property a:
> >         """doc string
> >         """
> >         def get(self) -> float:
> >             return self._a
> >         def set(self, value):
> >             self._a = float(value)
> >         def delete(self):
> >             del self._a
>
> I'm pretty sure Guido's said before that he doesn't like the
> get/set/del methods being indented more than other instance methods
> would be. If you really like this style, you can get something like it
> today using inner classes:
>
>     http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/442418

Or decorators: http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/410698


George

-- 
"If I have been able to see further, it was only because I stood on
the shoulders of million monkeys."


From g.brandl at gmx.net  Thu Jul 12 23:10:26 2007
From: g.brandl at gmx.net (Georg Brandl)
Date: Thu, 12 Jul 2007 23:10:26 +0200
Subject: [Python-ideas] C# style properties
In-Reply-To: <20070712094423.8C73.JCARLSON@uci.edu>
References: <f75i6v$g1$1@sea.gmane.org> <20070712094423.8C73.JCARLSON@uci.edu>
Message-ID: <f765bn$alp$1@sea.gmane.org>

Josiah Carlson schrieb:
> Christian Heimes <lists at cheimes.de> wrote:
>> 
>> Hello!
>> 
>> In the past few months I've been toying around with .NET, C# and
>> PythonNet. While I still think that C# is too wory (public static
>> explicit operator Egg(Spam spam) { ... }) C# has one syntax feature I
>> really like to see in Python.
>> 
>> private float _a
>> public float a
>> {
>>     get { return _a; }
>>     set { _a = value; }
>> }
> [snip]
>> Comments?
> 
> Python has an exact equivalent to the C# method (which uses a new
> block/scope for defining properties...)
> 
>     class foo:
>         class a(Property):
>             ''' documentation '''
>             def get(self):
>                 return self._a
>             def set(self, val):
>                 self._a = val
>             def de1(self):
>                 del self._a
> 
> 
> Now all you need is a Property base class with a proper metaclass that
> handles all of the magic for you.  I'm curious as to why this still gets
> brought up when the obvious syntax is more or less identical to
> basically all reasonable alternate syntaxes.  Is it because people don't
> understand that metaclasses can mangle your class any way they want?

No, it's because they feel that the word "class" to introduce a property
is ugly, and I can't blame them for it.

Georg



From lists at cheimes.de  Fri Jul 13 01:58:12 2007
From: lists at cheimes.de (Christian Heimes)
Date: Fri, 13 Jul 2007 01:58:12 +0200
Subject: [Python-ideas] C# style properties
In-Reply-To: <f765bn$alp$1@sea.gmane.org>
References: <f75i6v$g1$1@sea.gmane.org> <20070712094423.8C73.JCARLSON@uci.edu>
	<f765bn$alp$1@sea.gmane.org>
Message-ID: <f76f6l$9vk$1@sea.gmane.org>

Georg Brandl wrote:
> No, it's because they feel that the word "class" to introduce a property
> is ugly, and I can't blame them for it.

Yeah, it looks ugly, it's hard to understand if you aren't familiar with
the technique and it doesn't integrate into documentation tools like
pydoc. The trick isn't part of Python's stdlib, too.

I like to see a clean solution that is easy to understand and not a
genius but tricky metaclass hack.

Christian



From greg.ewing at canterbury.ac.nz  Fri Jul 13 03:40:59 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Fri, 13 Jul 2007 13:40:59 +1200
Subject: [Python-ideas] C# style properties
In-Reply-To: <20070712094423.8C73.JCARLSON@uci.edu>
References: <f75i6v$g1$1@sea.gmane.org> <20070712094423.8C73.JCARLSON@uci.edu>
Message-ID: <4696D82B.8030708@canterbury.ac.nz>

Josiah Carlson wrote:
>     class foo:
>         class a(Property):
>             ''' documentation '''
>             def get(self):
>                 return self._a
>             ...
> 
> I'm curious as to why this still gets
> brought up when the obvious syntax is more or less identical to
> basically all reasonable alternate syntaxes.

I would dispute that anything involving a class statement
that creates something other than a class is "obvious".

--
Greg


From jcarlson at uci.edu  Fri Jul 13 09:16:25 2007
From: jcarlson at uci.edu (Josiah Carlson)
Date: Fri, 13 Jul 2007 00:16:25 -0700
Subject: [Python-ideas] C# style properties
In-Reply-To: <4696D82B.8030708@canterbury.ac.nz>
References: <20070712094423.8C73.JCARLSON@uci.edu>
	<4696D82B.8030708@canterbury.ac.nz>
Message-ID: <20070712235418.8C7D.JCARLSON@uci.edu>


Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Josiah Carlson wrote:
> >     class foo:
> >         class a(Property):
> >             ''' documentation '''
> >             def get(self):
> >                 return self._a
> >             ...
> > 
> > I'm curious as to why this still gets
> > brought up when the obvious syntax is more or less identical to
> > basically all reasonable alternate syntaxes.
> 
> I would dispute that anything involving a class statement
> that creates something other than a class is "obvious".

The "Property" statement that is longer, the existance of get/set/de1
methods, those didn't catch your eye?  What if the user plopped in a
nice big "__metaclass__ = Property" line?  Ugly or not, I find that it
has helped me organize (with indentation), not repeat myself, and not
have to clean up spare get/set/del methods.  I personally prefer it to
x = property(...), a property decorator, and a bazillion times more than
any property-specific syntax.

 - Josiah



From ntoronto at cs.byu.edu  Fri Jul 13 11:43:07 2007
From: ntoronto at cs.byu.edu (Neil Toronto)
Date: Fri, 13 Jul 2007 03:43:07 -0600
Subject: [Python-ideas] C# style properties
In-Reply-To: <20070712235418.8C7D.JCARLSON@uci.edu>
References: <20070712094423.8C73.JCARLSON@uci.edu>	<4696D82B.8030708@canterbury.ac.nz>
	<20070712235418.8C7D.JCARLSON@uci.edu>
Message-ID: <4697492B.8080308@cs.byu.edu>

Josiah Carlson wrote:
> Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
>   
>> Josiah Carlson wrote:
>>     
>>>     class foo:
>>>         class a(Property):
>>>             ''' documentation '''
>>>             def get(self):
>>>                 return self._a
>>>             ...
>>>
>>> I'm curious as to why this still gets
>>> brought up when the obvious syntax is more or less identical to
>>> basically all reasonable alternate syntaxes.
>>>       
>> I would dispute that anything involving a class statement
>> that creates something other than a class is "obvious".
>>     
>
> The "Property" statement that is longer, the existance of get/set/de1
> methods, those didn't catch your eye?  What if the user plopped in a
> nice big "__metaclass__ = Property" line?  Ugly or not, I find that it
> has helped me organize (with indentation), not repeat myself, and not
> have to clean up spare get/set/del methods.  I personally prefer it to
> x = property(...), a property decorator, and a bazillion times more than
> any property-specific syntax.
>   

Your original question was on how obvious this is to *invent*, but here 
you're defending how obvious it is to *read*. (FWIW, I think it reads 
just fine, and I've added a couple of new, nifty things to my personal 
library. Thanks for the pointer.) Inner-class-as-a-class-variable is the 
mental leap you have to make, plus you have to be comfortable with 
metaclasses. I expect most developers would get to "hey, let's add a new 
keyword" before they arrive at that. Some proportion of those would 
bring it up on a mailing list, and then some proportion of the mailing 
list recipients would have seen it before, and some proportion of those 
recipients might feel a little exasperated and wonder how the rest of us 
can be so blind as to miss such an obvious solution...

It's statistics, babay.

On a very related topic, I find it interesting how often classes get 
abused just to provide a convenient namespace to stick things in. 
Classes are heavy things, though, with a lot of semantics and 
behind-the-scenes witchery to deal with inheritance and metaclasses and 
such-like. Why bring that baggage into it? It might be nice to be able 
to declare a one-off namespace:

    class Foo:
        x:
            '''documentation'''
            def __get__(self, instance, owner):  # self = x, instance = 
a Foo(), owner = Foo()
                return instance._x


    logger:
        '''Singleton logger object blah blah...'''
        db = make_db_connection(...)
       
        def log(self, message):
            ...


Be gentle, because I haven't thought this through very well. :)

Neil



From steven.bethard at gmail.com  Fri Jul 13 18:01:47 2007
From: steven.bethard at gmail.com (Steven Bethard)
Date: Fri, 13 Jul 2007 10:01:47 -0600
Subject: [Python-ideas] C# style properties
In-Reply-To: <4697492B.8080308@cs.byu.edu>
References: <20070712094423.8C73.JCARLSON@uci.edu>
	<4696D82B.8030708@canterbury.ac.nz>
	<20070712235418.8C7D.JCARLSON@uci.edu> <4697492B.8080308@cs.byu.edu>
Message-ID: <d11dcfba0707130901r9792ebara0f17aa5f65b7764@mail.gmail.com>

On 7/13/07, Neil Toronto <ntoronto at cs.byu.edu> wrote:
> On a very related topic, I find it interesting how often classes get
> abused just to provide a convenient namespace to stick things in.
> Classes are heavy things, though, with a lot of semantics and
> behind-the-scenes witchery to deal with inheritance and metaclasses and
> such-like. Why bring that baggage into it? It might be nice to be able
> to declare a one-off namespace:
>
>     class Foo:
>         x:
>             '''documentation'''
>             def __get__(self, instance, owner):  # self = x, instance =
> a Foo(), owner = Foo()
>                 return instance._x
>
>
>     logger:
>         '''Singleton logger object blah blah...'''
>         db = make_db_connection(...)
>
>         def log(self, message):
>             ...

You should look at the "make" statement PEP, which offered you
something like this:

    http://www.python.org/dev/peps/pep-0359/

It was withdrawn at Guido's request - partly because he didn't like
how it allowed you to indent the methods for properties.

STeVe
-- 
I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a
tiny blip on the distant coast of sanity.
        --- Bucky Katt, Get Fuzzy


From greg.ewing at canterbury.ac.nz  Sat Jul 14 04:58:46 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sat, 14 Jul 2007 14:58:46 +1200
Subject: [Python-ideas] C# style properties
In-Reply-To: <4697492B.8080308@cs.byu.edu>
References: <20070712094423.8C73.JCARLSON@uci.edu>
	<4696D82B.8030708@canterbury.ac.nz>
	<20070712235418.8C7D.JCARLSON@uci.edu>
	<4697492B.8080308@cs.byu.edu>
Message-ID: <46983BE6.7020509@canterbury.ac.nz>

Neil Toronto wrote:
> Inner-class-as-a-class-variable is the 
> mental leap you have to make, plus you have to be comfortable with 
> metaclasses.

Actually, I think there's a further mental leap you have
to make -- the notion that a 'class' statement can create
something that is *not* a class. Just knowing that there
is a metaclass involved is not enough to alert you to
this possibility.

IMO this is something that should definitely not be
encouraged, as it directly obfuscates the code --
you're saying 'class' when you don't really mean it.

 > It might be nice to be able
 > to declare a one-off namespace:

Yes, things like this have been suggested before.
There was a thread not long ago about a 'make'
statement, for example, and there have been numerous
suggestions for a 'namespace' statement.

My favourite version would be something like

   intance foo(property):

     def __get__(self):
       ...

     def __set__(self, x):
       ...

which would be roughly equivalent to

   class _foo(property):
     ...

   foo = _foo()

but without the intermediate class name.

--
Greg


From ntoronto at cs.byu.edu  Sat Jul 14 06:54:11 2007
From: ntoronto at cs.byu.edu (Neil Toronto)
Date: Fri, 13 Jul 2007 22:54:11 -0600
Subject: [Python-ideas] C# style properties
In-Reply-To: <46983BE6.7020509@canterbury.ac.nz>
References: <20070712094423.8C73.JCARLSON@uci.edu>	<4696D82B.8030708@canterbury.ac.nz>	<20070712235418.8C7D.JCARLSON@uci.edu>	<4697492B.8080308@cs.byu.edu>
	<46983BE6.7020509@canterbury.ac.nz>
Message-ID: <469856F3.7060404@cs.byu.edu>

Greg Ewing wrote:
> Neil Toronto wrote:
>
>  > It might be nice to be able
>  > to declare a one-off namespace:
>
> Yes, things like this have been suggested before.
> There was a thread not long ago about a 'make'
> statement, for example, and there have been numerous
> suggestions for a 'namespace' statement.
>
> My favourite version would be something like
>
>    intance foo(property):
>
>      def __get__(self):
>        ...
>
>      def __set__(self, x):
>        ...
>   

Surely you meant to write "instance". :) I like that spelling. The 
keyword has exactly the right meaning. I imagine having to create a new 
keyword just for a bit of syntactic sugar would be the main argument 
against it.

It's not just about saving keystrokes, though.

> which would be roughly equivalent to
>
>    class _foo(property):
>      ...
>
>    foo = _foo()
>
> but without the intermediate class name.
>   

Seems this sort of thing would be trivial with a class decorator, 
something like "@instance" or "@oneinstance". ("@singleton" would 
probably make people expect a call to the class to return a unique 
instance only the first time.) As part of my new delvination (that's a 
word) into metaclasses, I've been trying to make a metaclass that does 
the same thing. (No spoilers, please!)

Neil



From greg.ewing at canterbury.ac.nz  Sun Jul 15 02:57:17 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Sun, 15 Jul 2007 12:57:17 +1200
Subject: [Python-ideas] C# style properties
In-Reply-To: <469856F3.7060404@cs.byu.edu>
References: <20070712094423.8C73.JCARLSON@uci.edu>
	<4696D82B.8030708@canterbury.ac.nz>
	<20070712235418.8C7D.JCARLSON@uci.edu>
	<4697492B.8080308@cs.byu.edu> <46983BE6.7020509@canterbury.ac.nz>
	<469856F3.7060404@cs.byu.edu>
Message-ID: <469970ED.9050800@canterbury.ac.nz>

Neil Toronto wrote:
> Greg Ewing wrote:
 >
> >   intance foo(property):
>
> Surely you meant to write "instance". :)

Oops, yes.

> Seems this sort of thing would be trivial with a class decorator, 
> something like "@instance" or "@oneinstance".

I have much the same feeling about class decorators
that don't return a class. You're still writing
'class foo' yet not defining foo to be a class.

--
Greg


From tomerfiliba at gmail.com  Sun Jul 22 23:03:54 2007
From: tomerfiliba at gmail.com (tomer filiba)
Date: Sun, 22 Jul 2007 23:03:54 +0200
Subject: [Python-ideas] of properties and metaclasses
Message-ID: <1d85506f0707221403r465bafaqd792d9986cbd6c9c@mail.gmail.com>

first thing: properties. i prefer this approach to properties (example below).
true, it involves some magic, but the magic is very restricted and contained.

import inspect

def getter(func):
    namespace = inspect.stack()[1][0].f_locals
    p = namespace.get(func.func_name)
    if p is None:
        p = property(func)
    else:
        p = property(func, p.fset, p.fdel)
    return p

def setter(func):
    namespace = inspect.stack()[1][0].f_locals
    p = namespace.get(func.func_name)
    if p is None:
        p = property(None, func)
    else:
        p = property(p.fget, func, p.fdel)
    return p

class File(object):
    def __init__(self):
        self._pos = 8

    @getter
    def position(self):
        return self._pos

    @setter
    def position(self, value):
        self._pos = value


f = File()
print f.position
f.position = 11
print f.position
==============================================

btw, in py3k, with class decorators, you could instead use
class File:
     @propertyclass
     class position:
         def get(self):
             return self.tell()
          def set(self):
              return self.tell()
==============================================

second -- metaclasses. there's some notion (Josiah et al) that metaclasses
were introduced to make classes behave as generic attribute containers. this
is not true. using metaclasses like so was not the original intent.

metaclasses are the types of types. they also happened to be executed
before the class body is made into a class, which means they can be used
to tweak class creation, but that's a technicality. using this feature to turn
classes into anything you want is wrong: it's implicit, complex, and mostly
unreadable by the common programmer. i'd guess 80% of python
programmers have never used metaclasses. it's a difficult concept,
and should be used sparsely.

class decorators would cover ~70% of the use-cases for metaclasses,
but for some reason, people insist on complicating even more the
metaclass machinery in py3k. see my protest [1], which was silently ignored.

what you people are asking for is a new language construct which allows
the definition of syntactic namespaces. much like the deceased make pep.
(mis)using classes for this purpose is wrong. it's different -- it's
not a class
anymore. so why is it being defined by a class-clause?

@property
namespace foo:
    def get(self):
        ....
    def set(self):
        ....


-tomer

[1] http://mail.python.org/pipermail/python-3000/2007-June/008330.html


From tomerfiliba at gmail.com  Sun Jul 22 23:11:22 2007
From: tomerfiliba at gmail.com (tomer filiba)
Date: Sun, 22 Jul 2007 21:11:22 -0000
Subject: [Python-ideas] announcing: google group
Message-ID: <1185138682.715453.153390@k79g2000hse.googlegroups.com>

this is to inform the readers of this group: i created a mirror group
of this
mailing list on google-groups. unlike most mailing list mirrors out
there,
which only allow you to browse the archive, the google group also
allows
you to post to a specific message/thread (so you don't have to start
new topics when you only want to reply, but don't have the original
message).

http://groups.google.com/group/python-ideas


-tomer



From nad at acm.org  Mon Jul 23 00:07:13 2007
From: nad at acm.org (Ned Deily)
Date: Sun, 22 Jul 2007 15:07:13 -0700
Subject: [Python-ideas] announcing: google group
References: <1185138682.715453.153390@k79g2000hse.googlegroups.com>
Message-ID: <nad-B58849.15071322072007@sea.gmane.org>

In article <1185138682.715453.153390 at k79g2000hse.googlegroups.com>,
 tomer filiba <tomerfiliba at gmail.com> 
 wrote:

> this is to inform the readers of this group: i created a mirror group
> of this
> mailing list on google-groups. unlike most mailing list mirrors out
> there,
> which only allow you to browse the archive, the google group also
> allows
> you to post to a specific message/thread (so you don't have to start
> new topics when you only want to reply, but don't have the original
> message).
> 
> http://groups.google.com/group/python-ideas

FYI, such a two-way mirror already exists, gmane.comp.python.ideas, both 
through the web and as a usenet-style nntp news group.  See 
<http://dir.gmane.org/gmane.comp.python.ideas>.

Many other python-related mailing lists are also available through gmane 
<http://dir.gmane.org/index.php?prefix=gmane.comp.python>.

-- 
 Ned Deily,
 nad at acm.org



From rrr at ronadam.com  Mon Jul 23 02:51:13 2007
From: rrr at ronadam.com (Ron Adam)
Date: Sun, 22 Jul 2007 19:51:13 -0500
Subject: [Python-ideas] of properties and metaclasses
In-Reply-To: <1d85506f0707221403r465bafaqd792d9986cbd6c9c@mail.gmail.com>
References: <1d85506f0707221403r465bafaqd792d9986cbd6c9c@mail.gmail.com>
Message-ID: <46A3FB81.1060206@ronadam.com>



tomer filiba wrote:
> first thing: properties. i prefer this approach to properties (example below).
> true, it involves some magic, but the magic is very restricted and contained.

Looks good, it also looks optional in that the old way still works.



Here are my recent thoughts on properties, which I believe would create 
more problems than not, but maybe someone can think of a nicer way to do 
the same thing? (shrug)  (This isn't thought out fully.)


Properties are magic anyways.  Yes, they can be implemented in pythons 
existing machinery, but that doesn't make them any less magical in what 
they do.

For example, *what if* properties could be defined independently of 
class's?     (possible?)  They would act something like a true variable or 
a unique mutable container of length one.  This is unique in python because 
in all other cases the expression (x = y) would be a name binding 
operation.  With a property, it's a closer to (x[0] = y).

Because it's behavior is unique, it would probably need it's own 
constructor syntax, as well as support by the interpreter to recognize them 
and call the setter and getter functions instead of rebinding the name.  It 
would need to convert (x = y) statements where x is a property to 
(x.__set__(y)).

So a global property definition might look something like...

property foo():
     __value__ = value
     def __get__():
         return __value__
     def __set__(value)
         __value__ = value


Of course that would be magic since it isn't a class and it isn't a 
function.  It's a mutable variable with definable input and output functions.

And it has a problem in that there is no way to create a lot of them 
without resorting to meta programming techniques.  So we are back to first 
creating a function or a class, and then converting it to a property in 
some *magical* way.


The same object in a class might look like...

property foo(self):
    self.__value__ = None
    def __get__(self):
        return self.__value__
    def __set__(self, value):
        self.__value__ = value


This is sort of the direction some of the other suggestions have been going 
in I think.  But how useful would it be?  In other words, would something 
like property objects be useful and beneficial behavior to the language?

My personal thoughts at this time are it would probably be more trouble 
than it's worth even thought there are certain aspects to the general idea 
I like.  There is more things about how to make it work I don't like.


> second -- metaclasses. there's some notion (Josiah et al) that metaclasses
> were introduced to make classes behave as generic attribute containers. this
> is not true. using metaclasses like so was not the original intent.
> 
> metaclasses are the types of types. they also happened to be executed
> before the class body is made into a class, which means they can be used
> to tweak class creation, but that's a technicality. using this feature to turn
> classes into anything you want is wrong: it's implicit, complex, and mostly
> unreadable by the common programmer. i'd guess 80% of python
> programmers have never used metaclasses. it's a difficult concept,
> and should be used sparsely.

I haven't needed them yet, but I do wonder how I might use them to 
generalize certain types of behaviors across a wider range of objects and 
situations.  So far though I've found it easier to just stay away from them.

> class decorators would cover ~70% of the use-cases for metaclasses,
> but for some reason, people insist on complicating even more the
> metaclass machinery in py3k. see my protest [1], which was silently ignored.
> 
> what you people are asking for is a new language construct which allows
> the definition of syntactic namespaces. much like the deceased make pep.
> (mis)using classes for this purpose is wrong. it's different -- it's
> not a class
> anymore. so why is it being defined by a class-clause?

I think I agree that there seems to be a indirect need if not desire to 
have an explicit name space type of object.  It seems like it may have the 
potential to improve some types of name space operations where dictionaries 
are currently used.

> @property
> namespace foo:
>     def get(self):
>         ....
>     def set(self):
>         ....

I think that should be...

     def set(self, value):
        ...

Then it's not too different from what I described above. ;-)

There may also be no requirement for a property type to have a single 
value.  So a property with child values could also be a name space or the 
other way around.  A name space with only it's primary value could be a 
property.

Cheers,
    Ron




From jcarlson at uci.edu  Mon Jul 23 06:25:28 2007
From: jcarlson at uci.edu (Josiah Carlson)
Date: Sun, 22 Jul 2007 21:25:28 -0700
Subject: [Python-ideas] of properties and metaclasses
In-Reply-To: <1d85506f0707221403r465bafaqd792d9986cbd6c9c@mail.gmail.com>
References: <1d85506f0707221403r465bafaqd792d9986cbd6c9c@mail.gmail.com>
Message-ID: <20070722210123.7282.JCARLSON@uci.edu>


"tomer filiba" <tomerfiliba at gmail.com> wrote:
> 
> first thing: properties. i prefer this approach to properties (example below).
> true, it involves some magic, but the magic is very restricted and contained.
[snip]

I'm not a big fan of the style that you propose.  It doesn't fit my
aesthetics.  I'd rather introduce another level of indentation with a
class statement than to confuse myself with generic-like decoration that
aren't actually generics.


> second -- metaclasses. there's some notion (Josiah et al) that metaclasses
> were introduced to make classes behave as generic attribute containers. this
> is not true. using metaclasses like so was not the original intent.

I have never made any claim that they were introduced to offer that
functionality (incidentally, I don't believe anyone else has claimed as
much on this list either), I stated that they *could be used* to offer
that functionality, expressed that I had done so, and in my opinion,
using them as a generic container was obvious. If others disagree with
my opinions, that's fine, but please don't put words into my mouth.


> metaclasses are the types of types. they also happened to be executed
> before the class body is made into a class, which means they can be used
> to tweak class creation, but that's a technicality. using this feature to turn
> classes into anything you want is wrong: it's implicit, complex, and mostly
> unreadable by the common programmer. i'd guess 80% of python
> programmers have never used metaclasses. it's a difficult concept,
> and should be used sparsely.

If metaclasses are rarely used by users, then where is the problem of 
using (and abusing) them if a person desires?


> class decorators would cover ~70% of the use-cases for metaclasses,
> but for some reason, people insist on complicating even more the
> metaclass machinery in py3k. see my protest [1], which was silently ignored.

Don't get me wrong, I've been pushing for class decorators for a couple
years now (after 2.4 was released without them), and also generally
dislike the uglification of metaclass semantics, but every extra
argument to 'class foo(<arguments>):' necessarily makes it an uglier
mess than it already is.  Yes, overloading metaclasses to return a
dictionary-like object as a namespace is ugly, but getting the 'order'
list in '(name, bases, attrs, order)' to be correct when confronted with
'del' is tricky, and will necessarily require an extra line of
boilerplate.  Of course whether this is a bigger issue than everyone
writing their own ordered dict, is another dicussion (that I don't
particularly want to participate in).


> what you people are asking for is a new language construct which allows
> the definition of syntactic namespaces. much like the deceased make pep.
> (mis)using classes for this purpose is wrong. it's different -- it's
> not a class anymore. so why is it being defined by a class-clause?

Because it offers everything necessary for certain higher order
functionality without needing to change the base language.  I don't know
about others, but I am conservative about language change. I believe
that Python should be no simpler and no more complex than necessary.
Adding yet another way of defining a namespace (with a namespace
construct as you propose) won't offer us anything that we don't already
have with 'class namespace'.


 - Josiah



From greg.ewing at canterbury.ac.nz  Tue Jul 24 02:07:03 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Tue, 24 Jul 2007 12:07:03 +1200
Subject: [Python-ideas] of properties and metaclasses
In-Reply-To: <46A3FB81.1060206@ronadam.com>
References: <1d85506f0707221403r465bafaqd792d9986cbd6c9c@mail.gmail.com>
	<46A3FB81.1060206@ronadam.com>
Message-ID: <46A542A7.9080308@canterbury.ac.nz>

Ron Adam wrote:

> property foo():
>      __value__ = value
>      def __get__():
>          return __value__
>      def __set__(value)
>          __value__ = value
> 
> The same object in a class might look like...
> 
> property foo(self):
>     self.__value__ = None
>     def __get__(self):
>         return self.__value__
>     def __set__(self, value):
>         self.__value__ = value

In the first version, how is anything supposed to know that
the __value__ inside the function is an implicit attribute
of self rather than a local variable of the function

I can't see this flying, for all the reasons that suggestions
for implicit 'self' in methods get shot down in milliseconds.

--
Greg


From rrr at ronadam.com  Tue Jul 24 04:04:44 2007
From: rrr at ronadam.com (Ron Adam)
Date: Mon, 23 Jul 2007 21:04:44 -0500
Subject: [Python-ideas] of properties and metaclasses
In-Reply-To: <46A542A7.9080308@canterbury.ac.nz>
References: <1d85506f0707221403r465bafaqd792d9986cbd6c9c@mail.gmail.com>	<46A3FB81.1060206@ronadam.com>
	<46A542A7.9080308@canterbury.ac.nz>
Message-ID: <46A55E3C.9050106@ronadam.com>



Greg Ewing wrote:
> Ron Adam wrote:
> 
>> property foo():
>>      __value__ = value

This should have been __value__ = None.

>>      def __get__():
>>          return __value__
>>      def __set__(value)
>>          __value__ = value


>> The same object in a class might look like...
>>
>> property foo(self):
>>     self.__value__ = None
>>     def __get__(self):
>>         return self.__value__
>>     def __set__(self, value):
>>         self.__value__ = value
> 
> In the first version, how is anything supposed to know that
> the __value__ inside the function is an implicit attribute
> of self rather than a local variable of the function

In the first example self isn't implicit, it's non-existent.  It would work 
more like a generator that yields it value on gets, and receives its value 
on sets.

In the second version self is passed to the functions explicitly so it can 
work in an instance.  But other than that it's the same.  It could also 
keep state between calls, in which case all instances of that class would 
share those values.  (just like instances share class attributes)

   class bar(object):
      property foo(self):
          countgets = 0
          self.__value__ = None
          def __get__()
              countgets += 1
              return countgets, self.__value__
          def __set__(value)
              self.__value__ = value

In this case countgets will be the total gets of all subclasses of bar.

This could be done with a class attribute as well, but that breaks the idea 
of having a single self contained component.  Having self contained 
components is more conducive to a modular design where you can more easily 
reuse parts.

Cheers,
    Ron


> I can't see this flying, for all the reasons that suggestions
> for implicit 'self' in methods get shot down in milliseconds.

I can see that.  I actually like self.  :-)

The feature I recently wanted was a dynamic __contained_in__ attribute to 
go along with self.  But on a wider scale than class's self.  For example 
an object in a list could get a reference to the list object it's in.  (or 
dictionary, function, class, etc.)  And if you moved that object to another 
container, the __contained_in__, attribute would change to reflect that.

The reason I wanted that is it can get around the chicken and egg situation 
of  having to construct windows and frames in tkinter before creating the 
objects that go in them.  I wanted to create the buttons and lables and 
other interior items first and then add them to frames later by appending 
them to a list like frame object.  It could completely do away with the 
need to pass handles around.

But there are places were you really need to construct things in a certain 
order.

Cheers,
    Ron







From taleinat at gmail.com  Tue Jul 24 12:30:21 2007
From: taleinat at gmail.com (Tal Einat)
Date: Tue, 24 Jul 2007 13:30:21 +0300
Subject: [Python-ideas] of properties and metaclasses
In-Reply-To: <46A55E3C.9050106@ronadam.com>
References: <1d85506f0707221403r465bafaqd792d9986cbd6c9c@mail.gmail.com>
	<46A3FB81.1060206@ronadam.com> <46A542A7.9080308@canterbury.ac.nz>
	<46A55E3C.9050106@ronadam.com>
Message-ID: <7afdee2f0707240330m62704d24p254f61706bea707d@mail.gmail.com>

On 7/24/07, Ron Adam <rrr at ronadam.com> wrote:
>
>
> >> The same object in a class might look like...
> >>
> >> property foo(self):
> >>     self.__value__ = None
> >>     def __get__(self):
> >>         return self.__value__
> >>     def __set__(self, value):
> >>         self.__value__ = value
> >
> > In the first version, how is anything supposed to know that
> > the __value__ inside the function is an implicit attribute
> > of self rather than a local variable of the function
>
> In the first example self isn't implicit, it's non-existent.  It would
> work
> more like a generator that yields it value on gets, and receives its value
> on sets.
>
> In the second version self is passed to the functions explicitly so it can
> work in an instance.  But other than that it's the same.  It could also
> keep state between calls, in which case all instances of that class would
> share those values.  (just like instances share class attributes)
>
>    class bar(object):
>       property foo(self):
>           countgets = 0
>           self.__value__ = None
>           def __get__()
>               countgets += 1
>               return countgets, self.__value__
>           def __set__(value)
>               self.__value__ = value
>
> In this case countgets will be the total gets of all subclasses of bar.
>
> This could be done with a class attribute as well, but that breaks the
> idea
> of having a single self contained component.  Having self contained
> components is more conducive to a modular design where you can more easily
> reuse parts.


Pardon me for interrupting... Don't the existing descriptors do all of this,
with almost exactly the same syntax? You just have to set a class variable
to an instance of the descriptor class, which is one extra line of code.
Additionally, this allows reuse of a descriptor class for multiple
properties, which as-far-as-I-can-tell your models don't.

Perhaps I'm missing something, but I can't see the actual benefit of your
suggestions (besides inline-ing of properties' names).

- Tal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20070724/425ca8ce/attachment.html>

From rrr at ronadam.com  Tue Jul 24 18:25:44 2007
From: rrr at ronadam.com (Ron Adam)
Date: Tue, 24 Jul 2007 11:25:44 -0500
Subject: [Python-ideas] of properties and metaclasses
In-Reply-To: <7afdee2f0707240330m62704d24p254f61706bea707d@mail.gmail.com>
References: <1d85506f0707221403r465bafaqd792d9986cbd6c9c@mail.gmail.com>	
	<46A3FB81.1060206@ronadam.com> <46A542A7.9080308@canterbury.ac.nz>	
	<46A55E3C.9050106@ronadam.com>
	<7afdee2f0707240330m62704d24p254f61706bea707d@mail.gmail.com>
Message-ID: <46A62808.5020900@ronadam.com>



Tal Einat wrote:
> On 7/24/07, *Ron Adam* <rrr at ronadam.com <mailto:rrr at ronadam.com>> wrote:
> 
> 
>      >> The same object in a class might look like...
>      >>
>      >> property foo(self):
>      >>     self.__value__ = None
>      >>     def __get__(self):
>      >>         return self.__value__
>      >>     def __set__(self, value):
>      >>         self.__value__ = value
>      >
>      > In the first version, how is anything supposed to know that
>      > the __value__ inside the function is an implicit attribute
>      > of self rather than a local variable of the function
> 
>     In the first example self isn't implicit, it's non-existent.  It
>     would work
>     more like a generator that yields it value on gets, and receives its
>     value
>     on sets.
> 
>     In the second version self is passed to the functions explicitly so
>     it can
>     work in an instance.  But other than that it's the same.  It could also
>     keep state between calls, in which case all instances of that class
>     would
>     share those values.  (just like instances share class attributes)
> 
>        class bar(object):
>           property foo(self):
>               countgets = 0
>               self.__value__ = None
>               def __get__()
>                   countgets += 1
>                   return countgets, self.__value__
>               def __set__(value)
>                   self.__value__ = value
> 
>     In this case countgets will be the total gets of all subclasses of bar.
> 
>     This could be done with a class attribute as well, but that breaks
>     the idea
>     of having a single self contained component.  Having self contained
>     components is more conducive to a modular design where you can more
>     easily
>     reuse parts.
> 
> 
> Pardon me for interrupting... 

You aren't interrupting at all, but adding to it.  ;-)

> Don't the existing descriptors do all of 
> this, with almost exactly the same syntax? You just have to set a class 
> variable to an instance of the descriptor class, which is one extra line 
> of code. Additionally, this allows reuse of a descriptor class for 
> multiple properties, which as-far-as-I-can-tell your models don't.

Yes you are correct and it is why I said at the beginning one of the 
problems is you can't make a lot of these without resorting to meta 
programming techniques.

> Perhaps I'm missing something, but I can't see the actual benefit of 
> your suggestions (besides inline-ing of properties' names).

Inline-ing property names isn't really the point at all.  A much bigger 
change is having a way to use them outside of classes for indirect references.

     foo = ['a', 'b', 'c', 'd']

     property thirdfoo():
        def __get__():
            return foo[3]
        def __set__(value):
            foo[n] = value

     print thirdfoo     --->  'c'
     thirdfoo = 'z'     # Doesn't rebind thirdfoo to 'z'!
     print thirdfoo     --->  'z'
     print foo          --->  ['a', 'b', 'z', 'd']

Now as far as re-use goes, it could be more like a class with an __init__ 
method. Then it becomes almost exactly like the current descriptor objects 
too. (Maybe a good thing.)

The reason 'class' is replaced by 'property' is that it needs some way to 
tell the interpreter that this has different access characteristics than a 
normal name/object binding so it can be used outside of a class.

That change (potentially) makes descriptors/properties independent from the 
classes they are in.

Another way to do it might be to have a indirect name space.  Then it 
becomes a matter of moving a class (or suitable function) to "indirect" to 
activate it as a local descriptor.  Or "__indirect__" in the case of class 
descriptors.

And yes this is still a rather abstract idea.  The question is would it be 
beneficial to generalize and formalize descriptors and properties? (but not 
necessarily in the exact manner I'm describing.)

Cheers,
    Ron





From jcarlson at uci.edu  Wed Jul 25 05:57:39 2007
From: jcarlson at uci.edu (Josiah Carlson)
Date: Tue, 24 Jul 2007 20:57:39 -0700
Subject: [Python-ideas] of properties and metaclasses
In-Reply-To: <46A62808.5020900@ronadam.com>
References: <7afdee2f0707240330m62704d24p254f61706bea707d@mail.gmail.com>
	<46A62808.5020900@ronadam.com>
Message-ID: <20070724163636.729B.JCARLSON@uci.edu>


Ron Adam <rrr at ronadam.com> wrote:
> And yes this is still a rather abstract idea.  The question is would it be 
> beneficial to generalize and formalize descriptors and properties? (but not 
> necessarily in the exact manner I'm describing.)

I would argue no.  Non-dotted assignments resulting in arbitrary code
execution sounds to me like a metric ton of magic and a great way of
confusing the hell out of any and all future readers of your code.  I
know I'm a curmudgeon when it comes to syntax, but I would really like
to see a *sane* use-case for the potential feature (though I doubt one
exists).

 - Josiah



From greg.ewing at canterbury.ac.nz  Wed Jul 25 06:22:13 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Wed, 25 Jul 2007 16:22:13 +1200
Subject: [Python-ideas] of properties and metaclasses
In-Reply-To: <20070724163636.729B.JCARLSON@uci.edu>
References: <7afdee2f0707240330m62704d24p254f61706bea707d@mail.gmail.com>
	<46A62808.5020900@ronadam.com> <20070724163636.729B.JCARLSON@uci.edu>
Message-ID: <46A6CFF5.9040102@canterbury.ac.nz>

Josiah Carlson wrote:
> I would really like
> to see a *sane* use-case for the potential feature

I would like to have some reasonable way of achieving
the effect of a __getattr__ for a module, so that I
could implement auto-loaded classes.

You can do this now, but the convolutions required are
horrible to behold.

I don't think this particular proposal is the way
to go about it, though.

--
Greg


From jcarlson at uci.edu  Wed Jul 25 08:13:48 2007
From: jcarlson at uci.edu (Josiah Carlson)
Date: Tue, 24 Jul 2007 23:13:48 -0700
Subject: [Python-ideas] of properties and metaclasses
In-Reply-To: <46A6CFF5.9040102@canterbury.ac.nz>
References: <20070724163636.729B.JCARLSON@uci.edu>
	<46A6CFF5.9040102@canterbury.ac.nz>
Message-ID: <20070724231002.72A1.JCARLSON@uci.edu>


Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> 
> Josiah Carlson wrote:
> > I would really like
> > to see a *sane* use-case for the potential feature
> 
> I would like to have some reasonable way of achieving
> the effect of a __getattr__ for a module, so that I
> could implement auto-loaded classes.
> 
> You can do this now, but the convolutions required are
> horrible to behold.
> 
> I don't think this particular proposal is the way
> to go about it, though.

It's already possible.

    >>> import sys
    >>> class foo(object):
    ...     def __getattr__(self, clsname):
    ...         return type(clsname, (object,), {})
    ...
    >>> sys.modules['loader'] = foo()
    >>> from loader import bar
    >>> bar
    <class '__main__.bar'>
    >>> import loader
    >>> loader.boo
    <class '__main__.boo'>
    >>>


 - Josiah



From arno at marooned.org.uk  Wed Jul 25 10:29:39 2007
From: arno at marooned.org.uk (Arnaud Delobelle)
Date: Wed, 25 Jul 2007 09:29:39 +0100 (BST)
Subject: [Python-ideas] look ahead iterators
Message-ID: <59216.80.195.169.49.1185352179.squirrel@webmail.marooned.org.uk>

Hi,

Several people have felt the need to be able to 'peek ahead' for the next
value of an iterator without actually retrieving it.  I have, and I have a
'peekable' class that I use to wrap around iterators when I need this
feature:

>>> it = iter('python')
>>> it = peekable(it)
>>> it.peek(), it.peek(), it.next(), it.peek(), it.next(), it.next()
('p', 'p', 'p', 'y', 'y', 't')
>>>

There is an example of implementation at:

http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/304373

A wrapper works fine but a lot of built-in iterators such as
listiterators, tupleiterators, dictionary-***iterators could provide a
peek() method natively, which would be much more efficient and would not
necessitate any buffering. (e.g. in the case of a listiterator, peek()
would be the same as next() but without incrementing the it_index counter)

My idea is the following :

* iterators such as the ones listed above, where providing a peek() method
does not require any buffering or extra bookkeeping, implement this method
natively.

* for the other ones, no peek() method but a user can still wrap them as
in the example above.

* to provide a common interface, define a peekable class like this:

class peekable(object):
    def __new__(cls, iterator):
        # if the iterator is already 'peekable', return it
        # otherwise wrap it
        if hasattr(iterator, 'peek'):
            return iterator
        else:
            return object.__new__(cls)
    def __init__(self, iterator):
        ...
    def __iter__(self):
        return self
    def next(self):
	...
    def peek(self):
        ...

This means that an iterator would have the option of providing a peek()
method, but wouldn't have to.  However all iterators could be made
peekable by writing

   it = peekable(it)

-- 
Arnaud




From rrr at ronadam.com  Wed Jul 25 23:48:32 2007
From: rrr at ronadam.com (Ron Adam)
Date: Wed, 25 Jul 2007 16:48:32 -0500
Subject: [Python-ideas] look ahead iterators
In-Reply-To: <59216.80.195.169.49.1185352179.squirrel@webmail.marooned.org.uk>
References: <59216.80.195.169.49.1185352179.squirrel@webmail.marooned.org.uk>
Message-ID: <46A7C530.3040102@ronadam.com>



Arnaud Delobelle wrote:
> Hi,
> 
> Several people have felt the need to be able to 'peek ahead' for the next
> value of an iterator without actually retrieving it.  I have, and I have a
> 'peekable' class that I use to wrap around iterators when I need this
> feature:
> 
>>>> it = iter('python')
>>>> it = peekable(it)
>>>> it.peek(), it.peek(), it.next(), it.peek(), it.next(), it.next()
> ('p', 'p', 'p', 'y', 'y', 't')
> 
> There is an example of implementation at:
> 
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/304373

I thought maybe the new .send() method might be good for this, but it's 
wasn't at all obvious how to do it.  (I'm still not sure if this is correct 
and doesn't have weird behaviors.)

Note:  While writing this I came across the following error... is there a 
way we can get rid of this silly requirement?

      TypeError: can't send non-None value to a just-started generator



def insert_iter(it):
     """
         An insertable iterator.

         it.send(value) -> puts value in the iterator.
     """
     it = iter(it)
     buff = []
     while 1:
         if buff:
             nv = yield buff.pop(0)
         else:
             nv = yield it.next()
         while nv:
             buff.append(nv)
             nv = yield nv


it = insert_iter('python')
print (it.send(it.next()),    # send it back, so it is avialable again.
        it.send(it.next()),
        it.next(),
        it.send(it.next()),
        it.next(),
        it.next())

PRINTS:
('p', 'p', 'p', 'y', 'y', 't')



# Output of one iterator inserted into another
# with extra content added.

it2 = insert_iter([0])      # Needs at least one item
it2.next()                  # to avoid silly error.  :(
for c1 in 'Hello world.':
     it2.send(c1)
     if c1 == ' ':
         for c2 in 'python ':
             it2.send(c2)

print ''.join(it2)


PRINTS:
Hello python world.







From greg.ewing at canterbury.ac.nz  Thu Jul 26 03:31:35 2007
From: greg.ewing at canterbury.ac.nz (Greg Ewing)
Date: Thu, 26 Jul 2007 13:31:35 +1200
Subject: [Python-ideas] of properties and metaclasses
In-Reply-To: <20070724231002.72A1.JCARLSON@uci.edu>
References: <20070724163636.729B.JCARLSON@uci.edu>
	<46A6CFF5.9040102@canterbury.ac.nz>
	<20070724231002.72A1.JCARLSON@uci.edu>
Message-ID: <46A7F977.7080806@canterbury.ac.nz>

Josiah Carlson wrote:
> It's already possible.
> 
>     >>> import sys
>     >>> class foo(object):
>     ...     def __getattr__(self, clsname):
>     ...         return type(clsname, (object,), {})
>     ...
>     >>> sys.modules['loader'] = foo()

Yes, that's the sort of ugly hack I was talking about
(although mine was slightly worse, involving a module
replacing itself with a subclass of module and then
re-importing itself).

I keep thinking there ought to be a neater way, although
I haven't figured out exactly what it should look like.

--
Greg