On Sun, Oct 11, 2015 at 4:53 PM, dieter wrote:
> Otherwise, you can likely use a technique called "monkey patching".
> This is dynamically changing code at startup time.
> In your case, it could look like:
>
>from ... import Node
>
>def new_method(self, ...):
>
On Saturday, October 10, 2015 at 10:40:15 AM UTC-7, Ian wrote:
> name mangling
Awesome! I didn't know this was a feature.
> There's nothing wrong with [functional programming] IMO. In fact, Python
> does this in the standard library, e.g. len(objects) rather than
> objects.len().
...good point.
On Saturday, October 10, 2015 at 3:55:17 PM UTC-7, Steven D'Aprano wrote:
> # Solution 1: inject a new method into each and every instance in the tree.
>
> node.foo = MethodType(foo, node)
Ooh, interesting. I'll meditate on that for a while.
> # Solution 2: hack the node type of each
On Saturday, October 10, 2015 at 11:32:24 PM UTC-7, Chris Angelico wrote:
> If you REALLY want to look like Ruby,
Ha! This thread has provided so many interesting monkey-patching techniques,
but this might be the most perverse. Very cute.
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, Oct 12, 2015 at 10:09 AM, wrote:
> On Saturday, October 10, 2015 at 11:32:24 PM UTC-7, Chris Angelico wrote:
>> If you REALLY want to look like Ruby,
>
> Ha! This thread has provided so many interesting monkey-patching techniques,
> but this might be the most
On Sat, Oct 10, 2015 at 11:02 AM, wrote:
> (This is a long post, but the question is simple. Most of this is
> just me enumerating what I've already tried.)
>
> Someone wrote a library that creates and manipulates `Node`s.
> I would like to write another layer on top of
(This is a long post, but the question is simple. Most of this is
just me enumerating what I've already tried.)
Someone wrote a library that creates and manipulates `Node`s.
I would like to write another layer on top of this, to make
trees that behave just like the library's trees, but whose
In a message of Sat, 10 Oct 2015 10:02:24 -0700, speeze.pear...@gmail.com write
s:
>I should just use the existing library's `Node` class, and write
>my library in a functional style. Don't define `MyNode.foo()`,
>instead define `mylibrary.foo(my_node)`.
>I've got nothing against functional
speeze.pear...@gmail.com writes:
> ...
> Someone wrote a library that creates and manipulates `Node`s.
> I would like to write another layer on top of this, to make
> trees that behave just like the library's trees, but whose nodes
> have some extra methods.
If you are happy, the library supports
On Sun, 11 Oct 2015 04:02 am, speeze.pear...@gmail.com wrote:
> (This is a long post, but the question is simple. Most of this is
> just me enumerating what I've already tried.)
>
> Someone wrote a library that creates and manipulates `Node`s.
> I would like to write another layer on top of
Laura Creighton wrote:
don't fear mixins and multiple
inheritance unduly. They are a practical solution for a lot of
problems. You might have one of them.
I don't think mixins are a solution here, because they
still require controlling the instantiation of the classes
so that you can
11 matches
Mail list logo