On Wed, Feb 11, 2015 at 8:56 PM, Chris Angelico wrote:
> On Thu, Feb 12, 2015 at 1:57 PM, Ian Kelly wrote:
>> The reason I don't like this replacing def isn't because the name is
>> necessarily lost. It's because the lack of the well-defined def
>> statement encourages more complex usages like
>>
On Thu, Feb 12, 2015 at 1:57 PM, Ian Kelly wrote:
> The reason I don't like this replacing def isn't because the name is
> necessarily lost. It's because the lack of the well-defined def
> statement encourages more complex usages like
>
> functions['f'] = x -> x**2
>
> where such implicit tran
On Wed, Feb 11, 2015 at 7:06 PM, Terry Reedy wrote:
>> I can't see why the parser would understand more easily
>>
>> def f(x):
>> return x**2
>> than
>>
>> f = x->
>> return x**2
>
>
> The parser parses both equally well. That is not the issue.
The compiler could at some point recogniz
On 2/11/2015 8:04 AM, Albert van der Horst wrote:
It is not until we assign the object to a name (which becomes thereby a
function)
that the __name__ thingy comes into play, like so.
But __name__ would not come into play.
f = x->x**2
This would mean to create an anonymous function object
On 02/11/2015 05:04 AM, Albert van der Horst wrote:
> That's the reason why my ideal Python doesn't attach a name to a lambda
> denotation:
>
> x -> x**2
Hmmm. So now let's say you have a few dozen of these types of functions, and
you want to talk about the twenty-sixth
one with a peer... are
On Wednesday, February 11, 2015 at 8:04:33 AM UTC-5, Albert van der Horst wrote:
> In article ,
> Ethan Furman wrote:
> >-=-=-=-=-=-
> >
> >On 01/24/2015 11:55 AM, Chris Angelico wrote:
> >> On Sun, Jan 25, 2015 at 5:56 AM, Ethan Furman wrote:
> >>> If the non-generic is what you're concerned ab
In article ,
Ethan Furman wrote:
>-=-=-=-=-=-
>
>On 01/24/2015 11:55 AM, Chris Angelico wrote:
>> On Sun, Jan 25, 2015 at 5:56 AM, Ethan Furman wrote:
>>> If the non-generic is what you're concerned about:
>>>
>>> # not tested
>>> dispatch_table_a = {}
>>> dispatch_table_b = {}
>>> dispatch_tabl
Yawar Amin wrote:
> Hi Steven,
>
> On Saturday, January 24, 2015 at 11:27:33 PM UTC-5, Steven D'Aprano
> wrote:
>> [...]
>> > Doesn't the traceback tell us exactly where the lambda was called
>> > from?
>>
>> Yes (assuming the source code is available, which it may not be), but
>
> If the sourc
Hi Steven,
On Saturday, January 24, 2015 at 11:27:33 PM UTC-5, Steven D'Aprano
wrote:
> [...]
> > Doesn't the traceback tell us exactly where the lambda was called
> > from?
>
> Yes (assuming the source code is available, which it may not be), but
If the source code is not available, then you're
On Sat, Jan 24, 2015 at 5:58 PM, Ethan Furman wrote:
> On 01/24/2015 11:55 AM, Chris Angelico wrote:
>> On Sun, Jan 25, 2015 at 5:56 AM, Ethan Furman wrote:
>>> If the non-generic is what you're concerned about:
>>>
>>> # not tested
>>> dispatch_table_a = {}
>>> dispatch_table_b = {}
>>> dispatch
Yawar Amin wrote:
> Hi Ethan,
>
> On Saturday, January 24, 2015 at 9:00:12 PM UTC-5, Ethan Furman wrote:
>> [...]
>> __name__ being one of them. One of the reasons lambda
>> is not encouraged is because its name is always '', which just
>> ain't helpful when the smelly becomes air borne! ;)
>
Hi Ethan,
On Saturday, January 24, 2015 at 9:00:12 PM UTC-5, Ethan Furman wrote:
> [...]
> __name__ being one of them. One of the reasons lambda
> is not encouraged is because its name is always '', which just
> ain't helpful when the smelly becomes air borne! ;)
Doesn't the traceback tell us e
On 01/24/2015 11:55 AM, Chris Angelico wrote:
> On Sun, Jan 25, 2015 at 5:56 AM, Ethan Furman wrote:
>> If the non-generic is what you're concerned about:
>>
>> # not tested
>> dispatch_table_a = {}
>> dispatch_table_b = {}
>> dispatch_table_c = {}
>>
>> class dispatch:
>> def __init__(self, dis
Hi,
On Saturday, January 24, 2015 at 3:36:04 PM UTC-5, Devin Jeanpierre
wrote:
> [...]
> Obviously, nobody will be happy until you can do:
>
> def call(*a, **kw): return lambda f: f(*a, **kw)
>
> @call()
> def x, y ():
> yield 1
> yield 2
>
> Actually, maybe not even then.
You're proba
On 2015-01-24 19:55, Chris Angelico wrote:
On Sun, Jan 25, 2015 at 5:56 AM, Ethan Furman wrote:
If the non-generic is what you're concerned about:
# not tested
dispatch_table_a = {}
dispatch_table_b = {}
dispatch_table_c = {}
class dispatch:
def __init__(self, dispatch_table):
self.disp
On Sat, Jan 24, 2015 at 11:55 AM, Chris Angelico wrote:
> That's still only able to assign to a key of a dictionary, using the
> function name. There's no way to represent fully arbitrary assignment
> in Python - normally, you can assign to a name, an attribute, a
> subscripted item, etc. (Augment
On Sun, Jan 25, 2015 at 5:56 AM, Ethan Furman wrote:
> If the non-generic is what you're concerned about:
>
> # not tested
> dispatch_table_a = {}
> dispatch_table_b = {}
> dispatch_table_c = {}
>
> class dispatch:
> def __init__(self, dispatch_table):
> self.dispatch = dispatch_table
> de
On 01/23/2015 10:28 PM, Chris Angelico wrote:
>
> cmd = {}
> def command(func):
> cmd[func.__name__] = func
> return func
>
> @command
> def foo(*args):
> print("You asked to foo.")
>
> but this is hardly generic. There's no convenient way to give an
> argument to a decorator that sa
On 2015-01-24 17:28, Chris Angelico wrote:
> but this is hardly generic. There's no convenient way to give an
> argument to a decorator that says "please assign this here", short
> of using some stupid eval hack... is there?
>
> (Incidentally, for a non-generic dispatch table, a callable dict
> su
In some random and rambling discussion about Python, the notion came
up that multi-line lambda functions are often sought as a means of
populating dictionaries and other such structures. Conceptually, "def
foo(...): ..." is broadly equivalent to "foo = FunctionType(...)"; but
the only type of assig
20 matches
Mail list logo
