On May 6, 10:32 pm, Luis Alberto Zarrabeitia Gomez
wrote:
> A bit offtopic: a while ago I think I saw a recipe for a decorator that, via
> bytecode hacks, would bind otherwise global names to the local namespace of
> the
> function. Can anyone remember it/point me to it?
Maybe you saw http://co
On Thu, 07 May 2009 08:21:51 -0700, Francis Carr wrote:
> In the special case of a self-recursive function, you would like re-
> naming "to just work". Out of morbid curiosity, I am compelled to
> ask... why do you expect that re-naming anything --- a function, a
> class, a module, a variable, an
En Wed, 06 May 2009 23:32:23 -0300, Luis Alberto Zarrabeitia Gomez
escribió:
Quoting Steven D'Aprano :
But regardless, everyone is missing the most important point: why are
you
copying and pasting code in the first place? That is surely very close
to
the top of the list of Worst Ever An
Francis Carr:
I don't know who are you talking to, but I can give you few answers
anyway.
>collections of multiply-recursive functions (which get used very frequently --
>by no means is it an uncommon situation, as you suggest in your initial post),<
They may be frequent in Scheme (because it's
Luis Alberto Zarrabeitia Gomez writes:
> A bit offtopic: a while ago I think I saw a recipe for a decorator
> that, via bytecode hacks, would bind otherwise global names to the
> local namespace of the function. Can anyone remember it/point me to
> it? An @bind decorator that would 'localize' all
Scheme is arguably the programming language with the most support for
recursion, including the most complete support for tail-call
optimization, constructs like "letrec" to define collections of
multiply-recursive functions (which get used very frequently -- by no
means is it an uncommon situation,
Steven D'Aprano wrote:
I am writing a book (with Python package) on algorithms that has *lots*
of recursive functions. I have also discovered that changing names can
be a pain. So in the text, (but not code) I have tried the equivalent of
# real_name
def f(params):
... f(args)
(This also
Quoting Steven D'Aprano :
> But regardless, everyone is missing the most important point: why are you
> copying and pasting code in the first place? That is surely very close to
> the top of the list of Worst Ever Anti-Patterns, and it should be avoided
> whenever possible.
[btw, I took this
On Thu, 07 May 2009 01:59:02 +0100, Rhodri James wrote:
> On Wed, 06 May 2009 23:33:20 +0100, Luis Alberto Zarrabeitia Gomez
> wrote:
>
>> Quoting Rhodri James :
>>> So the answer to my question would be "nothing"?
>>
>> Indeed, there is nothing broken with the search and replace feature of
>> h
On Wed, 06 May 2009 23:33:20 +0100, Luis Alberto Zarrabeitia Gomez
wrote:
Quoting Rhodri James :
So the answer to my question would be "nothing"?
Indeed, there is nothing broken with the search and replace feature of
his editor. When he is copying a non-recursive function, it is
_useles
Quoting Rhodri James :
> >> I'm sorry, but while I'm mildly positive towards the proposal (and more
> >> so towards Aaron's decorator), I don't buy this argument at all. What
> >> is broken about your editor's global search-and-replace function that
> >> makes it "usually useless" for making the
On Wed, 06 May 2009 04:59:59 +0100, Gabriel Genellina
wrote:
En Tue, 05 May 2009 22:35:08 -0300, Rhodri James
escribió:
On Tue, 05 May 2009 21:43:16 +0100, wrote:
wolfram.hinde...:
It is easy to change all references of the function name, except for
those in the function body itself?
On May 6, 6:49 am, Lie Ryan wrote:
> Luis Zarrabeitia wrote:
> > Btw, is there any way to inject a name into a function's namespace?
> > Following
> > the python tradition, maybe we should try to create a more general solution!
>
> How about a mechanism to pass arguments that are optional to acce
On May 6, 2:23 am, Arnaud Delobelle wrote:
> On May 5, 10:20 pm, Aaron Brady wrote:
>
> > def auto( f ):
> > def _inner( *ar, **kw ):
> > return f( _inner, *ar, **kw )
> > return _inner
>
> Quoting myself near the start of this thread:
>
> Here's an idea:
>
> >>> def bindfunc(f):
Luis Zarrabeitia wrote:
Btw, is there any way to inject a name into a function's namespace? Following
the python tradition, maybe we should try to create a more general solution!
How about a mechanism to pass arguments that are optional to accept?
So (in the general case) the caller can call a
On May 5, 10:20 pm, Aaron Brady wrote:
> def auto( f ):
> def _inner( *ar, **kw ):
> return f( _inner, *ar, **kw )
> return _inner
Quoting myself near the start of this thread:
Here's an idea:
>>> def bindfunc(f):
... def boundf(*args, **kwargs):
... return f(boundf,
En Tue, 05 May 2009 22:35:08 -0300, Rhodri James
escribió:
On Tue, 05 May 2009 21:43:16 +0100, wrote:
wolfram.hinde...:
It is easy to change all references of the function name, except for
those in the function body itself? That needs some explantation.
I can answer this. If I have a rec
On Tue, 05 May 2009 21:43:16 +0100, wrote:
wolfram.hinde...:
It is easy to change all references of the function name, except for
those in the function body itself? That needs some explantation.
I can answer this. If I have a recursive function, I may want to
create a similar function, so I
On Tue, 05 May 2009 06:30:01 -0700, Arnaud Delobelle wrote:
> One issue with automatically binding a local variable to the current
> function is with nested functions:
>
> def foo()
> def bar():
># How do I call foo() from here?
As foo(), just like you would call foo() from outside o
Steve Howell wrote:
On May 4, 11:08 pm, Steven D'Aprano
wrote:
I propose a small piece of sugar. When a function is entered, Python
creates an ordinary local name in the function's local namespace, and
binds the function itself to that name. Two possibilities for the name
are `this` or `__this_
On May 5, 3:54 pm, bearophileh...@lycos.com wrote:
> Aaron Brady:
>
> > >>> def auto( f ):
>
> > ... def _inner( *ar, **kw ):
> > ... return f( g, *ar, **kw )
> > ... g= _inner
> > ... return g
>
> Looks nice, I'll try to the following variant to see if it's usable:
>
> def
Aaron Brady:
> >>> def auto( f ):
>
> ... def _inner( *ar, **kw ):
> ... return f( g, *ar, **kw )
> ... g= _inner
> ... return g
Looks nice, I'll try to the following variant to see if it's usable:
def thisfunc(fun):
"""Decorator to inject a default name of a
funct
wolfram.hinde...:
> It is easy to change all references of the function name, except for
> those in the function body itself? That needs some explantation.
I can answer this. If I have a recursive function, I may want to
create a similar function, so I copy and paste it, to later modify the
copied
Aaron Brady wrote:
> Here is how to get the function into the function as an argument, and
> still permit recursive calls onto it.
>
def auto( f ):
> ... def _inner( *ar, **kw ):
> ... return f( g, *ar, **kw )
> ... g= _inner
> ... return g
> ...
@auto
> ... def
On May 5, 2:50 pm, Steve Howell wrote:
> On May 4, 11:08 pm, Steven D'Aprano
>
> wrote:
>
> > I propose a small piece of sugar. When a function is entered, Python
> > creates an ordinary local name in the function's local namespace, and
> > binds the function itself to that name. Two possibilitie
On May 4, 11:08 pm, Steven D'Aprano
wrote:
>
> I propose a small piece of sugar. When a function is entered, Python
> creates an ordinary local name in the function's local namespace, and
> binds the function itself to that name. Two possibilities for the name
> are `this` or `__this__`, analogous
Steven D'Aprano writes:
> def rvisit(node):
> print node
> if node and node.link is not None:
> rvisit(node.link)
Less redundant (remember the extra "recursion" doesn't cost anything
if the compiler is sane enough to turn it into a jump):
def rvisit(node):
print node
i
On 5 May, 13:33, Luis Zarrabeitia wrote:
> On Tuesday 05 May 2009 02:46:58 am Chris Rebert wrote:
>
> >
> > Adding syntax is EVIL(tm) for it angers the Gods of Backwards
> > Compatibility, and this proposal is completely unnecessary because you
> > could instead just write:
> [...]
> > And there
On Tuesday 05 May 2009 04:25:49 am Carl Banks wrote:
> Iteration should be used instead of recursion anywhere a tail-
> recursive algorithm is possible. Recursion should be used only when
> tail-recursion is not possible.
Why?
Is it because most languages suck at recursion (specially python, as t
On Tuesday 05 May 2009 03:51:19 am Steven D'Aprano wrote:
> def ivisit(node):
> print node
> while node and node.link is not None:
> node = node.link
> print node
>
> def rvisit(node):
> print node
> if node and node.link is not None:
> rvisit(node.link)
>
>
On Tuesday 05 May 2009 02:46:58 am Chris Rebert wrote:
>
> Adding syntax is EVIL(tm) for it angers the Gods of Backwards
> Compatibility, and this proposal is completely unnecessary because you
> could instead just write:
[...]
> And there would be much clashing with existing variable names,
> for
On Tue, 05 May 2009 01:25:49 -0700, Carl Banks wrote:
> *Sigh* Well, I'm out of this debate. Apparently it's not possible to
> argue that recursivie algorithms should be avoided *sometimes* without
> everyone citing cases that obviously aren't from those times (as if I
> had been arguing that re
On Mon, 04 May 2009 23:55:41 -0700, Carl Banks wrote:
> On May 4, 8:26 pm, Steven D'Aprano
> wrote:
>> On Mon, 04 May 2009 16:33:13 -0700, Carl Banks wrote:
>> > On May 4, 4:06 pm, bearophileh...@lycos.com wrote:
>> >> Carl Banks:
>>
>> >> >1. Singly-linked lists can and should be handled with it
On 5 Mai, 08:08, Steven D'Aprano
wrote:
> Self-reflective functions like these are (almost?) unique in Python in
> that they require a known name to work correctly. You can rename a class,
> instance or module and expect it to continue to work, but not so for such
> functions. When editing source
On May 5, 12:51 am, Steven D'Aprano
wrote:
> On Mon, 04 May 2009 23:09:25 -0700, Carl Banks wrote:
> > In Python the One Obvious Way is iteration when possible, recursion when
> > necessary.
>
> There's nothing "obvious" about solving the 8 Queens problem using
> iteration. Or walking a binary tre
On Tue, 05 May 2009 00:09:27 -0700, Arnaud Delobelle wrote:
> Are you aware of PEP 3130? http://www.python.org/dev/peps/pep-3130/
I am now. Very disappointing.
> (BTW, it seems to me that your implementation breaks as soon as two
> functions are decorated - not tested!)
Of course it does! That'
On Mon, 04 May 2009 23:09:25 -0700, Carl Banks wrote:
> On May 4, 8:22 pm, Steven D'Aprano
> wrote:
>> On Mon, 04 May 2009 15:51:15 -0700, Carl Banks wrote:
>> > All
>> > recursion does it make what you're doing a lot less readable for
>> > almost all programmers.
>>
>> What nonsense.
>
> It's n
bearophileh...@lycos.com writes:
> This happens to me more than one time every year.
> So I have written this:
> ...
> self_name = getframeinfo(currentframe()).function
ZOMG, you've got to be kidding. I'd expect Pylint to catch that sort
of error statically. If not, the best approach is
On May 5, 2:08 am, Steven D'Aprano
wrote:
> On Mon, 04 May 2009 17:54:50 -0400, Terry Reedy wrote:
> > bearophileh...@lycos.com wrote:
>
> >> Another possible syntax:
>
> >> def fact(n):
> >> return 1 if n <= 1 else n * return(n - 1)
>
> >> But I guess most people don't see this problem as imp
On 5 May, 07:08, Steven D'Aprano
wrote:
> On Mon, 04 May 2009 17:54:50 -0400, Terry Reedy wrote:
> > bearophileh...@lycos.com wrote:
>
> >> Another possible syntax:
>
> >> def fact(n):
> >> return 1 if n <= 1 else n * return(n - 1)
>
> >> But I guess most people don't see this problem as impor
On May 4, 8:26 pm, Steven D'Aprano
wrote:
> On Mon, 04 May 2009 16:33:13 -0700, Carl Banks wrote:
> > On May 4, 4:06 pm, bearophileh...@lycos.com wrote:
> >> Carl Banks:
>
> >> >1. Singly-linked lists can and should be handled with iteration.<
>
> >> I was talking about a binary tree with list-lik
On Mon, May 4, 2009 at 11:08 PM, Steven D'Aprano
wrote:
> On Mon, 04 May 2009 17:54:50 -0400, Terry Reedy wrote:
>
>> bearophileh...@lycos.com wrote:
>>
>>> Another possible syntax:
>>>
>>> def fact(n):
>>> return 1 if n <= 1 else n * return(n - 1)
>>>
>>> But I guess most people don't see thi
On May 4, 8:22 pm, Steven D'Aprano
wrote:
> On Mon, 04 May 2009 15:51:15 -0700, Carl Banks wrote:
> > All
> > recursion does it make what you're doing a lot less readable for almost
> > all programmers.
>
> What nonsense.
It's not nonsense for a singly-linked list. I don't need to be taught
the
On Mon, 04 May 2009 17:54:50 -0400, Terry Reedy wrote:
> bearophileh...@lycos.com wrote:
>
>> Another possible syntax:
>>
>> def fact(n):
>> return 1 if n <= 1 else n * return(n - 1)
>>
>> But I guess most people don't see this problem as important&common
>> enough to justify changing the l
On Mon, 04 May 2009 16:33:13 -0700, Carl Banks wrote:
> On May 4, 4:06 pm, bearophileh...@lycos.com wrote:
>> Carl Banks:
>>
>> >1. Singly-linked lists can and should be handled with iteration.<
>>
>> I was talking about a binary tree with list-like topology, of course.
>
> "(every node has 1 chi
On Mon, 04 May 2009 15:51:15 -0700, Carl Banks wrote:
> All
> recursion does it make what you're doing a lot less readable for almost
> all programmers.
What nonsense. There are many algorithms that are more understandable
written recursively than iteratively -- consult any good text book for
e
On May 4, 4:06 pm, bearophileh...@lycos.com wrote:
> Carl Banks:
>
> >1. Singly-linked lists can and should be handled with iteration.<
>
> I was talking about a binary tree with list-like topology, of course.
"(every node has 1 child, and they are chained)"
That's a singly-linked list, not a tre
Carl Banks:
>1. Singly-linked lists can and should be handled with iteration.<
I was talking about a binary tree with list-like topology, of course.
>All recursion does it make what you're doing a lot less readable for almost
>all programmers.<
I can't agree. If the data structure is recursiv
On May 4, 1:25 pm, bearophileh...@lycos.com wrote:
> Aahz:
>
> > When have you ever had a binary tree a thousand levels deep?
>
> Yesterday.
>
> >Consider how big 2**1000 is...<
>
> You are thinking just about complete binary trees.
> But consider that a topology like a single linked list (every no
Arnaud Delobelle wrote:
In that case the following would not grow the stack, given tail-call
optimization:
def visit(node):
print 'visiting', node
if node.right is None:
return visit(node.left)
if node.left is not None:
visit(node.left)
return visit(node.right)
bearophileh...@lycos.com wrote:
Another possible syntax:
def fact(n):
return 1 if n <= 1 else n * return(n - 1)
But I guess most people don't see this problem as important&common
enough to justify changing the language.
Actually, I would like a way to refer to the current function from
bearophileh...@lycos.com writes:
> Aahz:
>> When have you ever had a binary tree a thousand levels deep?
>
> Yesterday.
>
>
>>Consider how big 2**1000 is...<
>
> You are thinking just about complete binary trees.
> But consider that a topology like a single linked list (every node has
> 1 child, a
On Mon, May 4, 2009 at 1:25 PM, wrote:
> Aahz:
>> When have you ever had a binary tree a thousand levels deep?
>
> Yesterday.
>
>
>>Consider how big 2**1000 is...<
>
> You are thinking just about complete binary trees.
> But consider that a topology like a single linked list (every node has
> 1 c
Aahz:
> When have you ever had a binary tree a thousand levels deep?
Yesterday.
>Consider how big 2**1000 is...<
You are thinking just about complete binary trees.
But consider that a topology like a single linked list (every node has
1 child, and they are chained) is a true binary tree still.
On Mon, 2009-05-04 at 19:51 +0100, Arnaud Delobelle wrote:
>
> Bearophile, there is a thread on python-ideas about tail-call
> optimization at the moment.
Oooh - haven't noticed that (and don't have time to follow it), but has
anyone seen the results I got a week or so ago from briefly playing wi
In article ,
wrote:
>Arnaud Delobelle:
>>
>> Bearophile, there is a thread on python-ideas about tail-call
>> optimization at the moment.
>
>Someday I'll have to start following those mailing lists...
>But I am not interested in such optimization. It's not going to help
>me significantly. Most t
Arnaud Delobelle:
> def fac(n):
> def rec(n, acc):
> if n <= 1:
> return acc
> else:
> return rec(n - 1, n*acc)
> return rec(n, 1)
Right, that's another way to partially solve the problem I was talking
about. (Unfortunately the performance in Python
bearophileh...@lycos.com writes:
> Steve Howell:
>>two methods with almost identical names, where one function is the
>>public interface and then another method that does most of the
>>recursion.<
>
> Thanks Guido & Walter both Python and D support nested functions, so
> in such situations I put t
Steve Howell:
>two methods with almost identical names, where one function is the public
>interface and then another method that does most of the recursion.<
Thanks Guido & Walter both Python and D support nested functions, so
in such situations I put the recursive function inside the "public
int
On May 3, 3:39 pm, bearophileh...@lycos.com wrote:
> Sometimes I rename recursive functions, or I duplicate&modify them,
> and they stop working because inside them there's one or more copy of
> their old name.
> This happens to me more than one time every year.
> So I have written this:
>
> from i
2009/5/4 :
> An idea-syntax:
>
> def fact(n):
> return 1 if n <= 1 else n * inspect.self(n - 1)
>
> Or even a lambda, because you don't need the name anymore to call the
> function:
>
> fact = lambda n: 1 if n <= 1 else n * self(n - 1)
How would it work with methods?
class Foo:
def fac(se
Arnaud Delobelle:
> >>> def bindfunc(f):
> ... def boundf(*args, **kwargs):
> ... return f(boundf, *args, **kwargs)
> ... return boundf
> ...>>> @bindfunc
> ... def fac(self, n):
> ... return 1 if n <= 1 else n * self(n - 1)
> ...>>> fac(5)
> 120
This is cute, now I have two n
On Sun, May 3, 2009 at 11:29 PM, Arnaud Delobelle
wrote:
> bearophileh...@lycos.com writes:
>
>> Sometimes I rename recursive functions, or I duplicate&modify them,
>> and they stop working because inside them there's one or more copy of
>> their old name.
>> This happens to me more than one time
bearophileh...@lycos.com writes:
> Sometimes I rename recursive functions, or I duplicate&modify them,
> and they stop working because inside them there's one or more copy of
> their old name.
> This happens to me more than one time every year.
> So I have written this:
>
> from inspect import get
On May 3, 5:21 pm, Emile van Sebille wrote:
> On 5/3/2009 3:39 PM bearophileh...@lycos.com said...
>
>
>
> > Sometimes I rename recursive functions, or I duplicate&modify them,
> > and they stop working because inside them there's one or more copy of
> > their old name.
> > This happens to me more
On 5/3/2009 3:39 PM bearophileh...@lycos.com said...
Sometimes I rename recursive functions, or I duplicate&modify them,
and they stop working because inside them there's one or more copy of
their old name.
This happens to me more than one time every year.
So I have written this:
from inspect im
Sometimes I rename recursive functions, or I duplicate&modify them,
and they stop working because inside them there's one or more copy of
their old name.
This happens to me more than one time every year.
So I have written this:
from inspect import getframeinfo, currentframe
def SOMEVERYUGLYNAME(n
67 matches
Mail list logo
