Re: How to comment code?
I think that doc strings are the most important way in which you should be commenting on your code. Once the code works, you can elimainate most inline comments, leaving only doc string for everything and a few comments on some particularly confusing parts. Other than that, comments usually only clutter Python code. But remember that you are the person who understands your code best, so don't be too fanatical about deleting inline comments. -- http://mail.python.org/mailman/listinfo/python-list
Overriding methods per-object
I've got an object which has a method, __nonzero__ The problem is, that method is attached to that object not that class > a = GeneralTypeOfObject() > a.__nonzero__ = lambda: False > a.__nonzero__() False But: > bool(a) True What to do? -- http://mail.python.org/mailman/listinfo/python-list
Re: Overriding methods per-object
> The docs don't say you can do that: Thanks, hadn't noticed that. > Should you be able to? I'd say so. In my case, I need a class that can encapsulate any object, add a few methods to it, and spit something back that works just like the object, but also has those extra methods. I can't just add the methods, because it has to work on e.g. lists. So I'll have to end up defining all the possible methods on that class (and that's still not best because I can't use hasattr to test if, for example, addition is allowed on that object). On the other hand, I see how this severely restricts the possibly optimizations that can be made in the interpreter. -- http://mail.python.org/mailman/listinfo/python-list
Re: Overriding methods per-object
On Apr 18, 4:01 pm, Piet van Oostrum wrote:
> But you can give each object its own class and then put the special
> methods in that class:
>
> >>> def create_special_object(bases, *args):
>
> ... if not isinstance(bases, tuple):
> ... bases = bases,
> ... cls = type("SpecialClass", bases, {})
> ... return cls(*args)
> ...>>> a = create_special_object(list, [1,2,3])
> >>> a
> [1, 2, 3]
> >>> a.__class__
>
>
>
> >>> a.__class__.__nonzero__ = lambda self: False
> >>> bool(a)
> False
> >>> a.__nonzero__()
> False
> >>> a.append(4)
> >>> a
> [1, 2, 3, 4]
>
> --
> Piet van Oostrum
> URL:http://pietvanoostrum.com[PGP 8DAE142BE17999C4]
> Private email: p...@vanoostrum.org
I think this is the solution I like best.
> FYI this works as you expect if GeneralTypeOfObject is an old-style
> class (i.e. does not inherit from object). If this feature is so more
> important than all those that come with new-style classes, you have
> control over the involved classes and don't care about Python 3.x
> (where old-style classes are gone), you may choose to downgrade
> GeneralTypeOfObject to old-style.
It is important, but new-style classes are important too. And I care
quite a bit about Python 3.x, thus the fact that I prefer the above
solution.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Overriding methods per-object
On Apr 18, 9:43 pm, Aaron Brady wrote: > On Apr 17, 9:41 pm, Steven D'Aprano > cybersource.com.au> wrote: > > On Fri, 17 Apr 2009 18:22:49 -0700, Pavel Panchekha wrote: > > > I've got an object which has a method, __nonzero__ The problem is, that > > > method is attached to that object not that class > > > >> a = GeneralTypeOfObject() > > >> a.__nonzero__ = lambda: False > > >> a.__nonzero__() > > > False > > > > But: > > > >> bool(a) > > > True > > > > What to do? > > > (1) Don't do that. > > > (2) If you *really* have to do that, you can tell the class to look at > > the instance: > > > class GeneralTypeOfObject(object): > > def __nonzero__(self): > > try: > > return self.__dict__['__nonzero__'] > > except KeyError: > > return something > > snip > > I think you need to call the return, unlike you would in > '__getattr__'. > return self.__dict__['__nonzero__']( ) > > You're free to use a different name for the method too. > return self.custom_bool( ) > > And you don't even have to implement an ABC. Er... /have/ to, that > is. I got it working. Thanks! -- http://mail.python.org/mailman/listinfo/python-list
Inheriting dictionary
I want a dictionary that will transparently "inherit" from a parent
dictionary. So, for example:
"""
a = InheritDict({1: "one", 2: "two", 4: "four"})
b = InheritDict({3: "three", 4: "foobar"}, inherit_from=a)
a[1] # "one"
a[4] # "four"
b[1] # "one"
b[3] # "three"
b[4] # "foobar"
"""
I've written something like this in Python already, but I'm wondering
if something like this already exists, preferably written in C, for
speed.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Inheriting dictionary
On Aug 18, 4:23 pm, "Jan Kaliszewski" wrote:
> 18-08-2009 o 21:44:55 Pavel Panchekha wrote:
>
>
>
> > I want a dictionary that will transparently "inherit" from a parent
> > dictionary. So, for example:
>
> > """
> > a = InheritDict({1: "one", 2: "two", 4: "four"})
> > b = InheritDict({3: "three", 4: "foobar"}, inherit_from=a)
>
> > a[1] # "one"
> > a[4] # "four"
> > b[1] # "one"
> > b[3] # "three"
> > b[4] # "foobar"
> > """
>
> > I've written something like this in Python already, but I'm wondering
> > if something like this already exists, preferably written in C, for
> > speed.
>
> AFAIN -- no. But you can easily implement it in Python with rather
> small loss of speed...
>
> class InheritDict(dict):
>
> class NoParent(object):
> def __getitem__(self, key):
> raise KeyError('There is no %r key in the hierarchy' % key)
> def __nonzero__(self):
> return False
>
> noparent = NoParent()
>
> def __init__(self, *args, **kwargs):
> parent = kwargs.pop('inherit_from', self.noparent)
> dict.__init__(self, *args, **kwargs)
> self.parent = parent
>
> def __getitem__(self, key):
> try:
> return dict.__getitem__(self, key)
> except KeyError:
> return self.parent[key]
>
> Did you do it in similar way? (just curiosity) :-)
>
> Regards,
> *j
>
> --
> Jan Kaliszewski (zuo)
I implemented it in a similar way (instead of a try block, an if
block, which works a tiny bit faster; also have a multiple-parents
case, but its rare, and I could do that in Python without much loss of
speed). Pity that there's no C version; this InheritDict is kind of
the core of my application (in a very basic test, I have 329901 calls
to __getitem__).
Oh well; I'll see if I can optimize the __getattr__ function with
minor tweaking. Thanks for your help.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Inheriting dictionary
On Aug 18, 5:11 pm, "Jan Kaliszewski" wrote:
> 18-08-2009 o 22:27:41 Nat Williams wrote:
>
>
>
> > On Tue, Aug 18, 2009 at 2:44 PM, Pavel Panchekha
> > wrote:
>
> >> I want a dictionary that will transparently "inherit" from a parent
> >> dictionary. So, for example:
>
> >> """
> >> a = InheritDict({1: "one", 2: "two", 4: "four"})
> >> b = InheritDict({3: "three", 4: "foobar"}, inherit_from=a)
>
> >> a[1] # "one"
> >> a[4] # "four"
> >> b[1] # "one"
> >> b[3] # "three"
> >> b[4] # "foobar"
> >> """
>
> >> I've written something like this in Python already, but I'm wondering
> >> if something like this already exists, preferably written in C, for
> >> speed.
>
> > Why complicate this with a custom object? Just use regular dicts and
> > make b a copy of a.
>
> > a = {1: 'one', 2: 'two', 4: 'four'}
> > b = dict(a)
> > b[3] = 'three'
> > b[4] = 'foobar'
>
> Because, as I understand Pavel's intent, it has to work dynamically
> (e.g. changes in 'a' reflect in behaviour of 'b'), and obviously not
> only for such trivial examples like above.
>
> *j
>
> --
> Jan Kaliszewski (zuo)
That is indeed the point.
--
http://mail.python.org/mailman/listinfo/python-list
Distutils evil voodoo: install into a package
Before you flame me, I know that what I'm trying to do is beyond evil. But I nonetheless want to do it. Feel free to rant if you must. :) I have a package that I want to install into another package. For example, I have the packages pya and pyb. pya is guaranteed to be installed before pyb is, so that's not an issue. pya is installed as the module `pya`. I want to install pyb into the module `pya.pyb`. Is there any way to do this beyond figuring out what the path is and installing the entire pyb directory as data_files? -- http://mail.python.org/mailman/listinfo/python-list
Re: Distutils evil voodoo: install into a package
> This is what whe world has created namespace-packages for. At least if > you can live with the namespace "pya" being otherwise empty. That seems like a good solution. Thanks! -- http://mail.python.org/mailman/listinfo/python-list
