«

Martin v. Löwis schrieb:
> I'm happy to announce partial 1.0; a module to implement
> partial classes in Python. It is available from
>
> http://cheeseshop.python.org/pypi/partial/1.0
>
> A partial class is a fragment of a class definition;
> partial classes allow to spread the definition of
> a class over several modules. One location serves
> as the original definition of the class.
>
> To extend a class original_module.FullClass with
> an additional function, one writes
>
> from partial import *
> import original_module
>
> class ExtendedClass(partial, original_module.FullClass):
> def additional_method(self, args):
> body
> more_methods
>
> This module is licensed under the Academic Free License v3.0.
>
> Please send comments and feedback to

Nice idea. I had to apply this change to make it work, though:

diff -u c:\python25\lib\site-packages\partial-1.0-py2.5.egg\partial.py.orig c:\python25\lib\site-packages\partial-1.0-py2.5.egg\partial.py
--- c:\python25\lib\site-packages\partial-1.0-py2.5.egg\partial.py.orig Wed Feb 07 13:47:55 2007
+++ c:\python25\lib\site-packages\partial-1.0-py2.5.egg\partial.py Wed Feb 07 13:47:55 2007
@@ -36,7 +36,7 @@
continue
if k in base.__dict__ and not hasattr(v, '__replace'):
raise TypeError, "%s already has %s" % (repr(base), k)
- base.__dict__[k] = v
+ setattr(base, k, v)
# Return the original class
return base

otherwise I get this:

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "c:\python25\lib\site-packages\partial-1.0-py2.5.egg\partial.py", line 39, in __new__
base.__dict__[k] = v
TypeError: Error when calling the metaclass bases
'dictproxy' object does not support item assignment


IIUC, wouldn't be 'partial.extend' or something like that be a better name
for the base class?

Thanks,
Thomas

On Feb 7, 8:51 am, Thomas Heller <thel...@ctypes.org> wrote:
> Martin v. Löwis schrieb:
>
> > I'm happy to announce partial 1.0; a module to implement
> > partial classes in Python. It is available from
>
> >http://cheeseshop.python.org/pypi/partial/1.0
>
> > A partial class is a fragment of a class definition;
> > partial classes allow to spread the definition of
> > a class over several modules. One location serves
> > as the original definition of the class.
>
> > To extend a class original_module.FullClass with
> > an additional function, one writes
>
> > from partial import *
> > import original_module
>
> > class ExtendedClass(partial, original_module.FullClass):
> > def additional_method(self, args):
> > body
> > more_methods
>
> > This module is licensed under the Academic Free License v3.0.
>
> > Please send comments and feedback to mar...@v.loewis.de
>
> Nice idea.

Indeed. I was going to make a post asking for advice on high-level
delegation (basically you have a generic mostly-OO framework, which
the user extends mostly by subclassing, but how do the generic classes
know about the user-extened classes?). I knew of many solutions, but
all had significant drawbacks. But this seems like it'd work great,
maybe with a few minor inconveniences but nothing like the icky hacks
I've been using.

Ironic, since I myself posted a very simple example of how to do this
with a class hook here on c.l.python a while back.

But I'll have to review the license and see how it works with what I
have.


Carl Banks

On Feb 7, 10:17 am, "Carl Banks" <pavlovevide...@gmail.com> wrote:
> On Feb 7, 8:51 am, Thomas Heller <thel...@ctypes.org> wrote:
>
>
>
> > Martin v. Löwis schrieb:
>
> > > I'm happy to announce partial 1.0; a module to implement
> > > partial classes in Python. It is available from
>
> > >http://cheeseshop.python.org/pypi/partial/1.0
>
> > > A partial class is a fragment of a class definition;
> > > partial classes allow to spread the definition of
> > > a class over several modules. One location serves
> > > as the original definition of the class.
>
> > > To extend a class original_module.FullClass with
> > > an additional function, one writes
>
> > > from partial import *
> > > import original_module
>
> > > class ExtendedClass(partial, original_module.FullClass):
> > > def additional_method(self, args):
> > > body
> > > more_methods
>
> > > This module is licensed under the Academic Free License v3.0.
>
> > > Please send comments and feedback to mar...@v.loewis.de
>
> > Nice idea.
>
> Indeed. I was going to make a post asking for advice on high-level
> delegation (basically you have a generic mostly-OO framework, which
> the user extends mostly by subclassing, but how do the generic classes
> know about the user-extened classes?). I knew of many solutions, but
> all had significant drawbacks. But this seems like it'd work great,
> maybe with a few minor inconveniences but nothing like the icky hacks
> I've been using.
>
> Ironic, since I myself posted a very simple example of how to do this
> with a class hook here on c.l.python a while back.

And looking back at that post, I said that using such a hack would be
"truly evil". To every thing there is a season....


Carl Banks

> Martin v. Löwis schrieb:
>
>
>
> > I'm happy to announce partial 1.0; a module to implement
> > partial classes in Python. It is available from
>
> >http://cheeseshop.python.org/pypi/partial/1.0
>
> > A partial class is a fragment of a class definition;
> > partial classes allow to spread the definition of
> > a class over several modules. One location serves
> > as the original definition of the class.

This looks the same as Ruby classes, right?
I don't like class definitions to be scattered in different files, for
the same reason
I don't like excessive inheritance, it is too easy to get lost when
debugging
code written by somebody else. But probably I am just overreacting due
to my
exposure to Zope ...

Michele Simionato

On Feb 7, 10:48 am, "Michele Simionato" <michele.simion...@gmail.com>
wrote:
> > Martin v. Löwis schrieb:
>
> > > I'm happy to announce partial 1.0; a module to implement
> > > partial classes in Python. It is available from
>
> > >http://cheeseshop.python.org/pypi/partial/1.0
>
> > > A partial class is a fragment of a class definition;
> > > partial classes allow to spread the definition of
> > > a class over several modules. One location serves
> > > as the original definition of the class.
>
> This looks the same as Ruby classes, right?
> I don't like class definitions to be scattered in different files, for
> the same reason
> I don't like excessive inheritance, it is too easy to get lost when
> debugging
> code written by somebody else. But probably I am just overreacting due
> to my
> exposure to Zope ...

The big difference from Ruby is that this can't extend most built-
ins. Which means that a lot of Ruby horror stories wouldn't apply.


Carl Banks

Carl Banks schrieb:
> On Feb 7, 10:17 am, "Carl Banks" <pavlovevide...@gmail.com> wrote:
>> On Feb 7, 8:51 am, Thomas Heller <thel...@ctypes.org> wrote:
>>
>>
>>
>> > Martin v. Löwis schrieb:
>>
>> > > I'm happy to announce partial 1.0; a module to implement
>> > > partial classes in Python. It is available from
>>
>> > >http://cheeseshop.python.org/pypi/partial/1.0
>>
>> > > A partial class is a fragment of a class definition;
>> > > partial classes allow to spread the definition of
>> > > a class over several modules. One location serves
>> > > as the original definition of the class.
>>
>> > > To extend a class original_module.FullClass with
>> > > an additional function, one writes
>>
>> > > from partial import *
>> > > import original_module
>>
>> > > class ExtendedClass(partial, original_module.FullClass):
>> > > def additional_method(self, args):
>> > > body
>> > > more_methods
>>
>> > > This module is licensed under the Academic Free License v3.0.
>>
>> > > Please send comments and feedback to mar...@v.loewis.de
>>
>> > Nice idea.
>>
>> Indeed. I was going to make a post asking for advice on high-level
>> delegation (basically you have a generic mostly-OO framework, which
>> the user extends mostly by subclassing, but how do the generic classes
>> know about the user-extened classes?). I knew of many solutions, but
>> all had significant drawbacks. But this seems like it'd work great,
>> maybe with a few minor inconveniences but nothing like the icky hacks
>> I've been using.
>>
>> Ironic, since I myself posted a very simple example of how to do this
>> with a class hook here on c.l.python a while back.
>
> And looking back at that post, I said that using such a hack would be
> "truly evil". To every thing there is a season....

Do you have a pointer to that post?

Thomas

Thomas Heller wrote:
>
> Do you have a pointer to that post?
>

I think that he was refering to this post:
http://mail.python.org/pipermail/pyt...er/416241.html

If you are interested in various implementations there is also this:
http://mail.python.org/pipermail/pyt...st/396835.html

and a module from PyPy:
http://mail.python.org/pipermail/pyt...ly/067501.html

which was moved to a new location:
https://codespeak.net/viewvc/pypy/di...py?view=markup

Ziga

> Martin v. Löwis schrieb:
>
>>A partial class is a fragment of a class definition;
>>partial classes allow to spread the definition of
>>a class over several modules.

When I want to do this, usually I define the parts
as ordinary, separate classes, and then define the
main class as inheriting from all of them. That
avoids the monkeypatching-like behaviour of what
you're doing -- the main class definition makes it
clear what parts it's made up of -- and it uses
only standard Python techniques, so it doesn't
harbour any surprises.

--
Greg

greg> When I want to do this, usually I define the parts as ordinary,
greg> separate classes, and then define the main class as inheriting
greg> from all of them.

Agreed. Maybe it's just my feeble brain, but I find this the most
compelling (and easy to understand) use for multiple inheritance by far.

Skip

On Feb 8, 1:04 pm, s...@pobox.com wrote:
> greg> When I want to do this, usually I define the parts as ordinary,
> greg> separate classes, and then define the main class as inheriting
> greg> from all of them.
>
> Agreed. Maybe it's just my feeble brain, but I find this the most
> compelling (and easy to understand) use for multiple inheritance by far.
>
> Skip

That is a common design, but I don't like it, since it becomes very
easy to get
classes with dozens of methods inherited from everywhere, a modern
incarnation
of the spaghetti-code concept. I find it much better to use
composition, i.e. to
encapsulate the various behaviors in different objects and to add them
as
attributes. In other words, instead of a flat class namespace with
hundreds
of methods, I prefer a hierarchical namespace, a class with few
attributes, which
in turns have their own attributes, and so on. In other words, nested
is better
than flatten


Michele Simionato

P.S. Of course I mean situations where the methods can be meaningfully
grouped
together, which I find is the most common case.