On 24/06/2023 18.18, Jason Friedman wrote:
I'm writing a database connectivity module to be used by other modules and
leveraging the jaydebeapi module.
From what I can tell jaydebeapi contains no built-in timeout capability, so
then I turned to https://pypi.org/project/timeout-decorator
meout-decorator/.
My goal is to have a default timeout of, say, 10 seconds, which can be
overridden by the caller.
import jaydebeapi
from timeout_decorator import timeout
class Database:
database_connection = None
database_name, user_name, password, host, port = stuff
timeout =
I'm writing a database connectivity module to be used by other modules and
leveraging the jaydebeapi module.
>From what I can tell jaydebeapi contains no built-in timeout capability, so
then I turned to https://pypi.org/project/timeout-decorator/.
My goal is to have a default timeout of,
On Thursday, September 29th, 2022 at 07:18, Robert Latest via Python-list
wrote:
> Hi Chris and dh,
>
> thanks for your --as usually-- thoughtful and interesting answers. Indeed,
> when
> doing these web applications I find that there are several layers of useful,
> maybe less useful, and unk
Hi Chris and dh,
thanks for your --as usually-- thoughtful and interesting answers. Indeed, when
doing these web applications I find that there are several layers of useful,
maybe less useful, and unknown caching. Many of my requests rely on a
notoriously unreliable read-only database outside of m
On 29/09/2022 07.22, Robert Latest via Python-list wrote:
...
> This is what I came up with. I'm quite happy with it so far. Question: Am I
> being too clever? is it too complicated? Am I overlooking something that will
> come back and bite me later? Thanks for any comments!
Thank you for the ch
that will
> come back and bite me later? Thanks for any comments!
>
> def lru_ignore_first(timeout=0, **lru_args):
> ...
I think this code is fairly specific to what you're doing, which means
the decorator won't be as reusable (first hint of that is the entire
"timeout&qu
forever (unless it's kicked out of the cache) and
not reflect the (infrequent) changes on the database. So what I need is some
decorator that can be used like this:
@lru_ignore_first(timeout=10)
def query_db(db, args):
# do the "expensive" query
return resul
On 5/28/21 5:23 AM, Ethan Furman wrote:
Greetings!
The Flag type in the enum module has had some improvements, but I find
it necessary to move one of those improvements into a decorator instead,
and I'm having a hard time thinking up a name.
What is the behavior? Well, a name in a
On 2021-05-28 04:23, Ethan Furman wrote:
Greetings!
The Flag type in the enum module has had some improvements, but I find it
necessary to move one of those improvements
into a decorator instead, and I'm having a hard time thinking up a name.
[snip]
So, like the enum.unique decorator
On 2021-05-27 at 20:23:29 -0700,
Regarding "name for new Enum decorator,"
Ethan Furman wrote:
> Greetings!
>
> The Flag type in the enum module has had some improvements, but I find it
> necessary to move one of those improvements into a decorator instead, and
> I'
Greetings!
The Flag type in the enum module has had some improvements, but I find it necessary to move one of those improvements
into a decorator instead, and I'm having a hard time thinking up a name.
What is the behavior? Well, a name in a flag type can be either canonical (it repre
On Mon, Apr 6, 2020 at 6:36 PM ast wrote:
>
> Hello
>
> I wrote a decorator to add a cache to functions.
> I realized that cache dictionnary could be defined
> as an object attribute or as a local variable in
> method __call__.
> Both seems to work properly.
> Can you
Hello
I wrote a decorator to add a cache to functions.
I realized that cache dictionnary could be defined
as an object attribute or as a local variable in
method __call__.
Both seems to work properly.
Can you see any differences between the two variants ?
from collection import OrderedDict
> slots = C.__slots__
> > except AttributeError:
> > assert C is object
> > else:
> > all_slots.update(slots)
> > return all_slots
> >
>
> I have been thinking about
try:
> slots = C.__slots__
> except AttributeError:
> assert C is object
> else:
> all_slots.update(slots)
> return all_slots
>
I have been thinking about this. AFAIU the slots are static data. So
instance, instance, value) NOT whatever he's done.. ? How is
he passing Spam to 'grok'? It should be (self=decorator-instance, Spam-
instance-s and value) being passed to __get__
(for those who don't have the book, he's switched to 'grok' instead of
'b
09.10.19 14:02, Chris Angelico пише:
The decorator has full access to the function object, including a
reference to that function's module globals.
def trace(func):
log = func.__globals__["log"]
... proceed as before
As long as you can depend on "log" al
tion-local "log" or anything.)
I have been up to now, but I will take this under consideration when
thinking
about how to proceed.
>> And from then on I just use log, to do the logging of that module.
>>
>> But now I would like to write a decorator trace, so that a decorated
>&g
__name__, result))
return result
return trace
[useit.py]
from logutil import Logger
log = Logger(__name__)
@log.traced
def some_func(...): ...
But yes, Chris' suggestion is more straight-forward ;)
> And from then on I just use log, to do the logging of that module.
it
as a module-level variable and always called "log", and you never use
the name "log" for anything else? (Namespaced usage like "math.log" is
fine, but you never have a function-local "log" or anything.)
> And from then on I just use log, to do the loggi
I have some logging utilities so that when I write library code, I just use the
following.
from logutil import Logger
log = Logger(__name__)
And from then on I just use log, to do the logging of that module.
But now I would like to write a decorator trace, so that a decorated
function would
On Fri, Sep 6, 2019 at 4:33 AM Serhiy Storchaka wrote:
>
> 04.09.19 17:21, Antoon Pardon пише:
> > What I am trying to do is the following.
> >
> > class MyClass (...) :
> > @register
> > def MyFunction(...)
> > ...
> >
> &
04.09.19 17:21, Antoon Pardon пише:
What I am trying to do is the following.
class MyClass (...) :
@register
def MyFunction(...)
...
What I would want is for the register decorator to somehow create/mutate
class variable(s) of MyClass.
Is that possible or do I have to
Antoon Pardon wrote:
> On 5/09/19 15:30, Peter Otten wrote:
>> Can you provide some context?
>
> Sure I am researching the possibility of writing an easy to use
> lexing/parsing tool. The idea is to write your lexer/parser as
> follows:
>
> class Calculator(metaclass = ...):
> def __init__(
On 5/09/19 15:30, Peter Otten wrote:
>> 2) Is it possible to make MyClass automatically a subclass of an other
>> class
>>through the metaclass?
>>
> While you can modify `bases` before passing it on to `type` this starts to
> get a bit messy. Maybe you need a real metaclass which unlike the r
Antoon Pardon wrote:
> On 4/09/19 17:46, Peter Otten wrote:
>> Antoon Pardon wrote:
>>
>>> What I am trying to do is the following.
>>>
>>> class MyClass (...) :
>>> @register
>>> def MyFunction(...)
>>> ...
>
On 4/09/19 17:46, Peter Otten wrote:
> Antoon Pardon wrote:
>
>> What I am trying to do is the following.
>>
>> class MyClass (...) :
>> @register
>> def MyFunction(...)
>> ...
>>
>> What I would want is for the register deco
On 4/09/19 17:46, Peter Otten wrote:
> Antoon Pardon wrote:
>
>> What I am trying to do is the following.
>>
>> class MyClass (...) :
>> @register
>> def MyFunction(...)
>> ...
>>
>> What I would want is for the register deco
Antoon Pardon writes:
> What I am trying to do is the following.
>
> class MyClass (...) :
> @register
> def MyFunction(...)
> ...
>
> What I would want is for the register decorator to somehow create/mutate
> class variable(s) of MyClass.
>
>
Antoon Pardon wrote:
> What I am trying to do is the following.
>
> class MyClass (...) :
> @register
> def MyFunction(...)
> ...
>
> What I would want is for the register decorator to somehow create/mutate
> class variable(s) of MyClass.
>
>
On Thu, Sep 5, 2019 at 12:23 AM Antoon Pardon wrote:
>
> What I am trying to do is the following.
>
> class MyClass (...) :
> @register
> def MyFunction(...)
> ...
>
> What I would want is for the register decorator to somehow create/mutate
> class
On 04/09/2019 15:21, Antoon Pardon wrote:
What I am trying to do is the following.
class MyClass (...) :
@register
def MyFunction(...)
...
What I would want is for the register decorator to somehow create/mutate
class variable(s) of MyClass.
Is that possible or do I have to
What I am trying to do is the following.
class MyClass (...) :
@register
def MyFunction(...)
...
What I would want is for the register decorator to somehow create/mutate
class variable(s) of MyClass.
Is that possible or do I have to rethink my approach?
--
Antoon Pardon
particular
function should be a module scope function or a static method. The
@staticmethod decorator merely facilitates a particular organisation of the
code allowing us to place what could otherwise be free functions within classes.
I didn’t get quiet well this block of text. My first question
— so you may want to consider carefully whether a particular
function should be a module scope function or a static method. The
@staticmethod decorator merely facilitates a particular organisation of the
code allowing us to place what could otherwise be free functions within classes.
I didn’t get
y want to consider carefully whether a particular
> function should be a module scope function or a static method. The
> @staticmethod decorator merely facilitates a particular organisation of the
> code allowing us to place what could otherwise be free functions within
> classes.
&g
scope function or a static method. The
@staticmethod decorator merely facilitates a particular organisation of the
code allowing us to place what could otherwise be free functions within classes.
I didn’t get quiet well this block of text. My first question is how would I
make a module level
Il giorno martedì 18 settembre 2018 17:36:16 UTC+2, vito.d...@gmail.com ha
scritto:
> > > is there a way to "convert" a "normal" decorator in one that can handle
> > > async functions?
> > In general? No.
> Ouch.
>
> I'm new to the
Il giorno martedì 18 settembre 2018 17:15:22 UTC+2, Thomas Jollans ha scritto:
> > but I cannot rewrite this library.
>
> Perhaps not, but surely you can write your own decorator that does
> whatever this library's decorator does for async functions? Presumably
> you
On 2018-09-18 16:20, vito.detul...@gmail.com wrote:
> but I cannot rewrite this library.
Perhaps not, but surely you can write your own decorator that does
whatever this library's decorator does for async functions? Presumably
you have the code...
> is there a way to "co
Hi.
Let's say I have this library that expose a decorator; it's meant to be used
with normal functions.
but I have to "apply" the decorator to an async function.
>From what I understand I cannot "really" wait for this decorated async
>function, as it'
,
secret=self.settings.SECRET_KEY,
login_path=self.settings.OAUTH2_LOGIN_URL)
return response(env, start_response)
Decorator:
from functools import wraps
from notmm.controllers.oauth import GoogleController
from notmm.utils.django_settings import LazySettings
_settings = Laz
Thanks to Rob, Cameron, Ian, Chris and Kirill for the detailed explanations.
Very helpful,
Irv
> On Dec 20, 2017, at 3:56 PM, Irv Kalb wrote:
>
> I am trying to work through the concept of the @property decorator with
> respect to object oriented programming.
>
>
On 20/12/17 21:39, Stefan Ram wrote:
Irv Kalb writes:
about property decorators.
The code
@property
def salary(self): pass
@salary.setter
def salary(self, newSalary): pass
is an abbreviation for
def salary_get(self): pass
salary = property( salary_get )
def salary_set(self, newSalary
2017-12-21 2:56 GMT+03:00 Irv Kalb :
> My questions about this are really historical. From my reading, it looks
> like using an @property decorator is a reference to an older approach using
> a built in "property" function. But here goes:
>
> 1) Why were these decorator
On 20Dec2017 15:56, Irv Kalb wrote:
I am trying to work through the concept of the @property decorator with
respect to object oriented programming.
I believe that I understand how the @property and @.setter work -
and that they are used to turn what looks like direct access to instance
On Thu, Dec 21, 2017 at 2:38 PM, Ian Kelly wrote:
> On Wed, Dec 20, 2017 at 5:56 PM, Irv Kalb wrote:
>> 2) Alternatively, if the getter was going to use the @property decorator,
>> then it would seem complimentary to have the decorator name for the
>> associated setter
On Wed, Dec 20, 2017 at 5:56 PM, Irv Kalb wrote:
> My questions about this are really historical. From my reading, it looks
> like using an @property decorator is a reference to an older approach using a
> built in "property" function. But here goes:
>
> 1) Why w
On 12/20/2017 03:56 PM, Irv Kalb wrote:
I am trying to work through the concept of the @property decorator with
respect to object oriented programming.
I believe that I understand how the @property and @.setter work -
and that they are used to turn what looks like direct access to instance
I am trying to work through the concept of the @property decorator with
respect to object oriented programming.
I believe that I understand how the @property and @.setter work -
and that they are used to turn what looks like direct access to instance
variables into method calls in an object
On Fri, Dec 15, 2017 at 6:44 AM, Brian Herman wrote:
> However when I add the arguments decorator I cannot access the self of the
> object that calls the decorator.
>
> def decorator_with_arguments(arg1, arg2):
> def decorator(self, method):
> """ Th
I would like to access the instance variable of a class using a decorator
with arguments:
I used to do with with a decorator without arguments:
def decorator(method):
""" This method is a decorator to get a security token each time you
have a service call. ""&quo
As discussed in the Python-Ideas mailing list, sometimes we want to suppress a
particular kind of exception and replace it with another.
For that reason, I'd like to announce exception_guard, a context manager and
decorator which catches specified exceptions and replaces them with a
On 22-2-2017 8:39, Argentinian Black ops lll wrote:
> Thanks for the quick response...! you saved me a lot of time, thank you!
>
I don't know if you want/have to use your own custom caching decorator, but are
you
aware of the lru_cache decorator that's part of the standard
On Wed, Feb 22, 2017 at 8:16 AM, Pavol Lisy wrote:
> Maybe this technique could be reusable (and maybe part of functools?)
>
> With this decorator:
>
> def wrap_args(decorator):
> def decor_out(*args, **kwargs):
> def decor_in(func):
>
ve Cameron's post contains the bones of a solution.
>
> Here's my untested solution.
>
>
> def func_cache(cache):
> # Create a decorator that uses cache.
> def decorate(function):
> @functools.wraps(function)
> def wrapper(*args):
my untested solution.
def func_cache(cache):
# Create a decorator that uses cache.
def decorate(function):
@functools.wraps(function)
def wrapper(*args):
try:
result = cache[args]
except KeyError:
result = function(*args
On Wednesday 22 Feb 2017 08:49 CET, Argentinian Black ops lll wrote:
> *** SOLVED ***
It would be nice if you shared the solution.
--
Cecil Westerhof
Senior Software Engineer
LinkedIn: http://www.linkedin.com/in/cecilwesterhof
--
https://mail.python.org/mailman/listinfo/python-list
*** SOLVED ***
--
https://mail.python.org/mailman/listinfo/python-list
Thanks for the quick response...! you saved me a lot of time, thank you!
--
https://mail.python.org/mailman/listinfo/python-list
On 21Feb2017 22:44, alfredocabre...@gmail.com wrote:
I have a python function and a decorator that works just fine.
def fun_cache(function):
memo = {}
def wrapper(*args):
if args in memo:
return memo[args]
else:
rv = function(*args)
memo
I have a python function and a decorator that works just fine.
def fun_cache(function):
memo = {}
def wrapper(*args):
if args in memo:
return memo[args]
else:
rv = function(*args)
memo[args] = rv
return rv
return wrapper
On Fri, Feb 10, 2017 at 10:18 AM, Terry Reedy wrote:
> Perhaps "There are also cases in which evaluating 'fi(arg)' before rather
> than after the def statement makes a difference." should be added.
Perhaps not. The word "roughly" covers the odd edge cases, and Python
has a general principle of ev
On 2/9/2017 2:03 AM, ast wrote:
Hi
In python courses I read, it is explained that
@decor
def f():
pass
is equivalent to:
def f():
pass
f = decor(f)
But that's not always true. See this code
Which is why the official docs now say 'roughly equivalent'
'''
For example, the following co
"Steven D'Aprano" a écrit dans le message de
news:589c2cdc$0$1584$c3e8da3$54964...@news.astraweb.com...
On Thu, 09 Feb 2017 08:03:32 +0100, ast wrote:
Congratulations, you've found a microscopic corner of the language where
the two different ways of applying decorators are different.
Are y
On Thu, 09 Feb 2017 08:03:32 +0100, ast wrote:
> Hi
>
> In python courses I read, it is explained that
>
> @decor
> def f():
> pass
>
> is equivalent to:
>
> def f():
> pass
>
> f = decor(f)
>
> But that's not always true. See this code
[...]
> any comment ?
Congratulations, you've
def celsius(self, value):<--
> overwrites previous celsius
>self.value = value
>
>celsius = celsius.setter(celsius) <-- error here
>
The difference is that the decorator line is evaluated before the
function is defined. Try this:
class Temperature:
def __init__(self):
Hi
In python courses I read, it is explained that
@decor
def f():
pass
is equivalent to:
def f():
pass
f = decor(f)
But that's not always true. See this code
class Temperature:
def __init__(self):
self.value = 0
# @property
def celsius(self):
return self.va
On Tue, 5 Jul 2016 07:31 pm, Gregory Ewing wrote:
> I wrote:
>> The only shortcoming I can think of is that a nestedmodule
>> inside another nestedmodule won't be able to see the names
>> in the outer nestedmodule
>
> Actually, that's not correct -- the version I posted before
> actually crashes
I wrote:
The only shortcoming I can think of is that a nestedmodule
inside another nestedmodule won't be able to see the names
in the outer nestedmodule
Actually, that's not correct -- the version I posted before
actually crashes if you try to refer to a name in an outer
nestedmodule from an in
Steven D'Aprano wrote:
There's only so far I can go without support from the compiler.
It turns out one can go surprisingly far. Here's something I
cooked up that seems to meet almost all the requirements.
The only shortcoming I can think of is that a nestedmodule
inside another nestedmodule wo
On Monday, July 4, 2016 at 12:06:21 PM UTC+12, Chris Angelico wrote:
> On Mon, Jul 4, 2016 at 9:59 AM, Lawrence D’Oliveiro wrote:
>> #begin try_func
>> result.__name__ = func.__name__
>> result.__doc__ = func.__doc__
>> return \
>> result
>> #end try_func
On Sun, Jul 3, 2016 at 6:06 PM, Lawrence D’Oliveiro
wrote:
> On Monday, July 4, 2016 at 12:02:23 PM UTC+12, Ian wrote:
>> I'm talking about the docstring of the *decorator*, not func.
>
> *Sigh*. Originally somebody was complaining that the lambda version didn’t
>
On Monday, July 4, 2016 at 12:02:23 PM UTC+12, Ian wrote:
> I'm talking about the docstring of the *decorator*, not func.
*Sigh*. Originally somebody was complaining that the lambda version didn’t
allow for good (or any) docstrings. So I posted my version, and I went to all
the e
On Mon, Jul 4, 2016 at 9:59 AM, Lawrence D’Oliveiro
wrote:
> #begin try_func
> result.__name__ = func.__name__
> result.__doc__ = func.__doc__
> return \
> result
> #end try_func
This is the bit we're talking about. You're doing manually what
functools.
On Sun, Jul 3, 2016 at 5:25 PM, Lawrence D’Oliveiro
wrote:
> On Monday, July 4, 2016 at 10:39:30 AM UTC+12, Ian wrote:
>> Sorry, but you're the one who doesn't seem to get it. Because it's a
>> decorator, "your" function is replacing the caller's fun
again, the only docstrings I am setting are for the intermediate functions
*I* generate.
Suppose we have the following:
def try_func(func, arg) :
"sample function to be turned into a decorator."
def result() :
"returns func unchanged."
On Mon, Jul 4, 2016 at 9:25 AM, Lawrence D’Oliveiro
wrote:
> On Monday, July 4, 2016 at 10:39:30 AM UTC+12, Ian wrote:
>> Sorry, but you're the one who doesn't seem to get it. Because it's a
>> decorator, "your" function is replacing the caller's fun
On Monday, July 4, 2016 at 10:39:30 AM UTC+12, Ian wrote:
> Sorry, but you're the one who doesn't seem to get it. Because it's a
> decorator, "your" function is replacing the caller's function in the
> caller's namespace.
No it is not
nction ...
>
> Which I am not “clobbering” at all. Do you get that yet? My docstrings apply
> to *my* functions, not those supplied or generated by the caller.
Sorry, but you're the one who doesn't seem to get it. Because it's a
decorator, "your" function is replacin
On Sunday, July 3, 2016 at 11:53:46 PM UTC+12, Ian wrote:
> On Sat, Jul 2, 2016 at 11:37 PM, Lawrence D’Oliveiro wrote:
>> That is a function that I am generating, so naturally I want to give it a
>> useful docstring. Am I “clobbering” any objects passed in by the caller,
>> or returned by the call
or_with_args
>> ... def my_decorator(func, *args, **kwargs):
>> ... """Returns func unmodified."""
>> ... return func
>> ...
>>>>> my_decorator.__doc__
>> 'generates a decorator which applies my_decorator to the given argumen
ed
>>> function's name and docstring:
>>
>> Where am I doing that?
>
> Using the implementation you posted:
>
>>>> @decorator_with_args
> ... def my_decorator(func, *args, **kwargs):
> ... """Returns func unmodified.""
implementation you posted:
>>> @decorator_with_args
... def my_decorator(func, *args, **kwargs):
... """Returns func unmodified."""
... return func
...
>>> my_decorator.__doc__
'generates a decorator which applies my_decorator to the given arguments'
--
https://mail.python.org/mailman/listinfo/python-list
each function, is a way to address that. Which is my motivation for
this thread.
> but a simple signature transform for a decorator definitition
You're making my case for me: To anyone who doesn't already know exactly
what's going on, that is not at all obvious from the cod
uccess)
that the "thing" is not "complex" at all but a simple signature
transform for a decorator definitition and that the nested function
implementation is natural for this purpose.
--
https://mail.python.org/mailman/listinfo/python-list
On Saturday, July 2, 2016 at 5:10:06 PM UTC+12, Ian wrote:
> You should use functools.wraps instead of clobbering the decorated
> function's name and docstring:
Where am I doing that?
> Just to satisfy my own curiosity, do you have something against
> putting the return keyword and the returned ex
On Fri, Jul 1, 2016 at 11:32 PM, Ben Finney wrote:
> Ian Kelly writes:
>
>> You should use functools.wraps instead of clobbering the decorated
>> function's name and docstring:
>>
>> @functools.wraps(decorator)
>> def decorate(*args, **kw
Ian Kelly writes:
> You should use functools.wraps instead of clobbering the decorated
> function's name and docstring:
>
> @functools.wraps(decorator)
> def decorate(*args, **kwargs):
> ...
Thanks. Can you write the full implementation with th
On Fri, Jul 1, 2016 at 4:08 PM, Lawrence D’Oliveiro
wrote:
> On Tuesday, June 28, 2016 at 5:03:08 PM UTC+12, Ben Finney wrote:
>> There is a clever one-line decorator that has been copy-pasted without
>> explanation in many code bases for many years::
>>
>> d
Ben Bacarisse writes:
> By replying I'm not accepting the premise -- I have no idea if there
> is widespread fear and suspicion of lambdas among Python users but it
> seems unlikely.
I can testify, as the person who started this thread, that there is no
fear or suspicion of lambda here. I use it
On Tuesday, June 28, 2016 at 5:03:08 PM UTC+12, Ben Finney wrote:
> There is a clever one-line decorator that has been copy-pasted without
> explanation in many code bases for many years::
>
> decorator_with_args = lambda decorator: lambda *args, **kwargs: lambda
> func:
dieter writes:
>> Lawrence D’Oliveiro wrote:
>>> I don’t know why this fear and suspicion of lambdas is so widespread among
>>> Python users ... former Java/C# programmers, perhaps?
By replying I'm not accepting the premise -- I have no idea if there is
widespread fear and suspicion of lambdas
Peter Otten <__pete...@web.de> writes:
> Lawrence D’Oliveiro wrote:
>
>> On Tuesday, June 28, 2016 at 5:03:08 PM UTC+12, Ben Finney wrote:
>>
>>> I would like to see a more Pythonic, more explicit and expressive
>>> replacement with its component parts easily understood.
>>
>> I don’t know why t
Lawrence D’Oliveiro wrote:
> On Thursday, June 30, 2016 at 7:26:01 PM UTC+12, Peter Otten wrote:
>> foo = lambda :
>>
>> there is syntactic sugar in Python that allows you to write it as
>>
>> def foo():
>> return
>>
>> with the nice side effects that it improves the readability of traceb
On Thursday 30 June 2016 17:43, Lawrence D’Oliveiro wrote:
> On Thursday, June 30, 2016 at 7:26:01 PM UTC+12, Peter Otten wrote:
>> foo = lambda :
>>
>> there is syntactic sugar in Python that allows you to write it as
>>
>> def foo():
>> return
>>
>> with the nice side effects that it im
On Thursday, June 30, 2016 at 7:26:01 PM UTC+12, Peter Otten wrote:
> foo = lambda :
>
> there is syntactic sugar in Python that allows you to write it as
>
> def foo():
> return
>
> with the nice side effects that it improves the readability of tracebacks
> and allows you to provide a do
func=lambda x, y: x + y): ...
the alternative
def reduce(items, func=add): ...
looks more readable in my eyes even though somewhere -- under the rug or in
the operator module -- you need
def add(x, y):
"""
>>> add(3, 4)
7
"""
return
On Thu, 30 Jun 2016 12:43 pm, Lawrence D’Oliveiro wrote:
> On Tuesday, June 28, 2016 at 5:03:08 PM UTC+12, Ben Finney wrote:
>> There is a clever one-line decorator that has been copy-pasted without
>> explanation in many code bases for many years::
>>
>> d
1 - 100 of 1127 matches
Mail list logo
