On Sun, Nov 14, 2021 at 2:50 PM Chris Angelico wrote:
>
> spam(*(1,) * use_eggs)
> spam(**{"eggs": 1} if use_eggs else {})
>
> Still clunky, but legal, and guaranteed to work in all Python
> versions. It's not something I've needed often enough to want
> dedicated syntax for, though.
>
> ChrisA
On Mon, Mar 22, 2021 at 1:28 PM Caleb Donovick
wrote:
> ... One could do something like:
> ```
> def fun(a, b=0): ...
> def wraps_fun(args, b=inspect.signature(fun).parameters['b'].default): ...
> ```
> But I would hardly call that clear.
>
> Caleb
>
I like this approach too - it just needs a
bump!
On Wed, Jan 13, 2021 at 9:32 AM Peter O'Connor
wrote:
> I often find that python lacks a nice way to say "only pass an argument
> under this condition". (See previous python-list email in "Idea: Deferred
> Default Arguments?")
>
> Example 1: Defini
I often find that python lacks a nice way to say "only pass an argument
under this condition". (See previous python-list email in "Idea: Deferred
Default Arguments?")
Example 1: Defining a list with conditional elements
include_bd = True
current_way = ['a'] + (['b'] if include_bd else
On Wed, May 20, 2020 at 5:35 AM Eric V. Smith wrote:
> On 5/20/2020 8:23 AM, James Lu wrote:
> > What's wrong with my := proposal?
> Confusion with unrelated uses of the walrus operator.
>
What's wrong with confusion with the walrus operator?
- If you are confused and don't know what walrus
Alright hear me out here:
I've often found that it would be useful for the following type of
expression to be condensed to a one-liner:
def running_average(x_seq):
averages = []
avg = 0
for t, x in enumerate(x_seq):
avg = avg*t/(t+1) + x/(t+1)
averages.append(avg)
Thanks all for the responses. I read thought them carefully and address
each below.
I don't think any fully address the core problem - The "Argument" - the
tuple of (type, default, documentation) - is currently not a first-class
entity. Because there is no way to reference an Argument, there is
Dear all,
Despite the general beauty of Python, I find myself constantly violating
the "don't repeat yourself" maxim when trying to write clear, fully
documented code. Take the following example:
def func_1(a: int = 1, b: float = 2.5) -> float:
"""
Something about func_1
I find that about 90% of the time I want want to zip iterators together, I
expect them to be the same length and want to throw an exception if they
aren't. Yet there is not currently a solution for this in the standard
library for this, and as a result I always have to take this function
Steven D'Aprano
wrote:
> On Fri, Jul 20, 2018 at 04:43:56PM +0200, Peter O'Connor wrote:
>
> > I still think it would be nice to have this as a built-in python feature,
> > for a few reasons:
> > - When using non-differable functions (say in other codebases
Ah, right, the fix_it(fcn) is a nice idea. It might also be a good idea,
if we're making an external library anyway, to have a "deferred" object to
avoid overloading "None" (which may mean something else than "differ
argument"). I implemented the decorator here
On Fri, Jul 20, 2018 at 1:30 PM, Jonathan Fine wrote:
>
>
> I sort of think we've now got a reasonable answer for Peter's problem.
> What do you think, Peter? And Brice, are you happy with my
> interpretation of your deferred keyword?
I think the problem with the "None" approach (second
Often when programming I run into a situation where it would be nice to
have "deferred defaults". Here is an example of what I mean:
def subfunction_1(a=2, b=3, c=4):
return a+b*c
def subfunction_2(d=5, e=6, f=7):
return d*e+f
def main_function(a=2, b=3, c=4, d=5,
On Thu, May 31, 2018 at 2:55 PM, Chris Angelico wrote:
> [process(tx, y) for x in xs for tx in [transform(x)] for y in yz]
>
...
I think Serhiy was trying to establish this form as a standard idiom,
> with optimization in the interpreter to avoid constructing a list and
> iterating over it (so
On Thu, May 31, 2018 at 1:55 PM, Neil Girdhar wrote:
> Why wouldn't you want to just put the outer given outside the entire
> comprehension?
> retval = [expr(name, x) given name=update(name, x) for x in seq]
> given name=something
>
There seems to be a lot of controversy about updating
Yes, you're right. That's the ambiguity I mentioned in my last message.
> It's too bad because I want given for expressions and given for
> comprehensions. But if you have both, there's ambiguity and you would at
> least need parentheses:
>
> [(y given y=2*x) for x in range(3)]
>
&
a little confusing then, because, given the way given is used
outside of comprehensions, you would expect
[y given y=2*x for x in range(3)]
to return [0, 2, 4], but it would actually raise an error.
On Thu, May 31, 2018 at 10:32 AM, Peter O'Connor wrote:
>
>
> On Thu
On Thu, May 31, 2018 at 4:50 AM, Neil Girdhar wrote:
>
>
>> [expression given name=something for x in seq]
>>
>
> retval = []
> name = something
> for x in seq:
> retval.append(expression)
> return retval
>
That's a little strange confusing then, because, given the way given is
used
On Wed, May 30, 2018 at 7:59 PM, Neil Girdhar wrote:
>
> z = {a: transformed_b
> for b in bs
> given transformed_b = transform(b)
> for a in as_}
>
> There is no nice, equivalent := version as far as I can tell.
>
Well you could just do:
z = {a: b
for b in
On Thu, May 24, 2018 at 2:49 PM, Steven D'Aprano
wrote:
> On Thu, May 24, 2018 at 02:06:03PM +0200, Peter O'Connor wrote:
> > We could use given for both the in-loop variable update and the variable
> > initialization:
> >smooth_signal = [average given average=(1-dec
>
> In comparison, I think that := is much simpler.
In this case that's true, but a small modification:
updates = {
y: do_something_to(potential_update)
for x in need_initialization_nodes
for y in [x, *x.synthetic_inputs()]
if
tax:
smooth_signal = [average for average in [0] for x in signal for average
in [(1-decay)*average + decay*x]]
(y for z in [initial_z] for x in iter_x for z, y in [f(z, x)])
On Tue, Apr 17, 2018 at 12:02 AM, Danilo J. S. Bellini <
danilo.bell...@gmail.com> wrote:
> On 16 Apr
*Correction: Above code should read:
outputs = []
state = initial_state
for inp in inputs:
out, state = my_update_func(inp, state)
outputs.append(out)
On Sun, May 13, 2018 at 11:21 AM, Peter O'Connor <peter.ed.ocon...@gmail.com
> wrote:
> target := expr
target := expr
expr as target
expr -> target
target given target = expr
let target = expr
: target expr ;
Although in general "target:=exp" seems the most palatable of these to me,
there is one nice benefit to the "given" syntax:
Suppose you have a comprehension wherein you want to
explicitly.
On Mon, Apr 16, 2018 at 9:49 AM, Peter O'Connor <peter.ed.ocon...@gmail.com>
wrote:
> Hi Danilo,
>
> The idea of decorating a function to show that the return variables could
> be fed back in in a scan form is interesting and could solve my problem in
> a nic
...@gmail.com> wrote:
> On 5 April 2018 at 13:52, Peter O'Connor <peter.ed.ocon...@gmail.com>
> wrote:
>
>> I was thinking it would be nice to be able to encapsulate this common
>> type of operation into a more compact comprehension.
>>
>> I propose a
Well this may be crazy sounding, but we could allow left or right
assignment with
name := expr
expr =: name
Although it would seem to violate the "only one obvious way" maxim, at
least it avoids this overloaded meaning with the "as" of "except" and "with"
On Fri, Apr 13, 2018 at 9:29 AM,
ra" which might initially
be considered initialization parameters, but then later it turns out they
need to be changed dynamically.
This is why I think the "(y:=f(y, x) for x in xs from y=initial)" syntax
can lead to cleaner, more maintainable code.
On Wed, Apr 11, 2018 at 10:
>
> It's worth adding a reminder here that "having more options on the
> market" is pretty directly in contradiction to the Zen of Python -
> "There should be one-- and preferably only one --obvious way to do
> it".
I've got to start minding my words more. By "options on the market" I more
lt;st...@pearwood.info>
wrote:
> On Tue, Apr 10, 2018 at 12:18:27PM -0400, Peter O'Connor wrote:
>
> [...]
> > I added your coroutine to the freak show:
>
> Peter, I realise that you're a fan of functional programming idioms, and
> I'm very sympathetic to that. I'm a f
again and again. It's
> hard. But it's also why Python stayed sane for decades.
Hey I'll support your campaign if you support mine.
On Tue, Apr 10, 2018 at 4:18 AM, Michel Desmoulin <desmoulinmic...@gmail.com
> wrote:
>
>
> Le 10/04/2018 à 00:54, Peter O'Connor a écr
* correction to brackets from first example:
def iter_cumsum_tolls_from_day(day, toll_amount_so_far):
return accumulate(get_tolls_from_day(day), initial=toll_amount_so_far)
On Mon, Apr 9, 2018 at 11:55 PM, Peter O'Connor <peter.ed.ocon...@gmail.com>
wrote:
> Ok, so it seems e
Ok, so it seems everyone's happy with adding an initial_value argument.
Now, I claim that while it should be an option, the initial value should
NOT be returned by default. (i.e. the returned generator should by default
yield N elements, not N+1).
Example: suppose we're doing the toll booth
Kyle, you sounded so reasonable when you were trashing itertools.accumulate
(which I now agree is horrible). But then you go and support Serhiy's
madness: "smooth_signal = [average for average in [0] for x in signal for
average in [(1-decay)*average + decay*x]]" which I agree is clever, but
Mon, Apr 9, 2018 at 1:44 PM, Peter O'Connor <peter.ed.ocon...@gmail.com>
wrote:
> It seems clear that the name "accumulate" has been kind of antiquated
> since the "func" argument was added and "sum" became just a default.
>
> And people seem to
It seems clear that the name "accumulate" has been kind of antiquated since
the "func" argument was added and "sum" became just a default.
And people seem to disagree about whether the result should have a length N
or length N+1 (where N is the number of elements in the input iterable).
The
there do not seem to be
> any responses to it.
>
> Cammil
>
> On Fri, 6 Apr 2018, 16:14 Guido van Rossum, <gu...@python.org> wrote:
>
>> On Fri, Apr 6, 2018 at 7:47 AM, Peter O'Connor <
>> peter.ed.ocon...@gmail.com> wrote:
>>
>>> Hi all, thank
Ah, ok, I suppose that could easily lead to typo-bugs. Ok, then I agree
that "a:=f()" returning a is better
On Fri, Apr 6, 2018 at 10:53 AM, Eric Fahlgren <ericfahlg...@gmail.com>
wrote:
> On Fri, Apr 6, 2018 at 7:47 AM, Peter O'Connor <peter.ed.ocon...@gmail.com
>
quot;:=" or "f() as a") but that's another discussion
Is there any interest (or disagreement) to these more humble proposals?
- Peter
On Fri, Apr 6, 2018 at 2:19 AM, Serhiy Storchaka <storch...@gmail.com>
wrote:
> 05.04.18 19:52, Peter O'Connor пише:
>
>> I p
k, it could
also kill the need for reduce, as you could instead use:
last_smooth_signal = last(average = (1-decay)*average + decay*x for x
in signal from average=0.)
On Thu, Apr 5, 2018 at 1:48 PM, Clint Hepner <clint.hep...@gmail.com> wrote:
>
> > On 2018 Apr 5 , at 12:52 p, Peter
Dear all,
In Python, I often find myself building lists where each element depends on
the last. This generally means making a for-loop, create an initial list,
and appending to it in the loop, or creating a generator-function. Both of
these feel more verbose than necessary.
I was thinking it
41 matches
Mail list logo
