Abdulla Al Kathiri wrote:
> Oh I forgot what if you want to return a set from your lambda? Maybe a lambda
> set should at least have one assignment statement to qualify it as one.
> Expressions only inside a set syntax will be just a normal set that doesn’t
> care about order as you pointed
Chris Angelico wrote:
> On Wed, Sep 29, 2021 at 10:56 PM Dominik Vilsmeier
> dominik.vilsme...@gmx.de wrote:
> > members.sort(key=(?[1], ?[0]))
> > How do you know whether this is one function that returns a tuple, or
> a tuple of two functions?
> ChrisA
You a
Lambda functions that have a single parameter are a common thing, e.g. for
"key" functions: `sorted(items, key=lambda x: x['key'])`. For these cases
however, the rather long word "lambda" together with the repetition of the
parameter name, results in more overhead than actual content (the
that this is what they were intended to be used for:
"Run the test without collecting the result. This allows exceptions raised by
the test to be propagated to the caller, and can be used to support running
tests under a debugger."
Dominik Vilsmeier wrote:
> Consider the following example:
>
On 01.09.20 17:44, Steven D'Aprano wrote:
(9) Keyword-only subscripts are permitted:
obj[spam=1, eggs=2]
# calls type(obj).__getitem__(spam=1, eggs=2)
del obj[spam=1, eggs=2]
# calls type(obj).__delitem__(spam=1, eggs=2)
but note that the setter is awkward since the
On 01.09.20 11:22, Zig Zigson wrote:
I believe I described my case poorly, the process to get from one state (key)
to the next is an external (slow) process; the value stored is not the next
state but a value calculated while advancing the state. This dict serves as a
way to quickly skip
On 31.08.20 06:01, junkneno...@gmail.com wrote:
I have a use case which relates to this request: iterating over a dict starting
from a given key. I would like to achieve this without having to pay the full
O(n) cost if I'm going to be iterating over only a few items. My understanding
is that
On 12.08.20 10:37, Mathew Elman wrote:
Is there a reason that itertools.islice does not provide its start, stop and
step values as attributes, similar to range?
This seems like a sensible and useful thing to have, and would also allow
islice's to have a __len__.
Not all iterators need to be
On 08.08.20 05:48, David Mertz wrote:
On Fri, Aug 7, 2020, 6:03 PM Paul Moore mailto:p.f.mo...@gmail.com>> wrote:
> x: int[0:] # any ints greater than or equal to zero would
match, others would fail
> x: int[:101] # any ints less than 101 match
> x: int[0:101:2] # even less
On 06.08.20 04:58, Guido van Rossum wrote:
On Wed, Aug 5, 2020 at 6:42 PM Steven D'Aprano mailto:st...@pearwood.info>> wrote:
On Wed, Aug 05, 2020 at 06:15:22PM -0700, Guido van Rossum wrote:
> On Wed, Aug 5, 2020 at 5:55 PM Steven D'Aprano
mailto:st...@pearwood.info>> wrote:
On 05.08.20 12:40, Greg Ewing wrote:
On 5/08/20 9:13 pm, Serhiy Storchaka wrote:
the code can be written as
class Neuron:
activation = linear_activation(activation)
I do not see reasons to introduce special syntax for this very specific
code.
A considerable number of moons
s it, but I have trouble imagining that many others would.
On Tue, Aug 4, 2020, 7:42 AM Dominik Vilsmeier
mailto:dominik.vilsme...@gmx.de>> wrote:
In one of my projects I'm reusing class-level type annotations
to identify relevant attributes for serialization
In one of my projects I'm reusing class-level type annotations to identify
relevant attributes for serialization, e.g. similar to the following:
attrs = {name: getattr(obj, name) for name in get_type_hints(type(obj))}
This is convenient because it merges the type annotations from the
On 02.08.20 15:36, Sebastian M. Ernst wrote:
Hi all,
yet another (possibly bad?) idea from day-to-day work ...
I occasionally need to import a lot of "stuff" from certain modules. The
"stuff" is usually following a pattern. E.g. I have modules that
(mostly) collect special exception classes
On 29.07.20 13:33, Jonathan Fine wrote:
Thank you all, particularly Guido, for your contributions. Having some
examples will help support the exploration of this idea.
Here's a baby example - searching in a nested loop. Suppose we're
looking for the word 'apple' in a collection of books. Once
On 27.07.20 16:01, Peter Moore wrote:
I have had a long standing unanswered question on on stackoverflow: is it
possible to pass a function to a default parameter so that you could do in
essence things like this.
def time_diff(target_time, curr_time= lambda : datetime.now() ):
return
On 17.07.20 22:11, Todd wrote:
On Fri, Jul 17, 2020 at 12:19 PM David Mertz mailto:me...@gnosis.cx>> wrote:
Fwiw, I'm probably -0 on the feature itself. Someone suggested it
could be useful for xarray, but I'm not sure now what that would
look like. If someone had an example, I
But `finally` with a `for` loop is redundant since the code can be
placed just after the loop. For `try/except` it's a different situation
since the exception might bubble up, so "normal" code after the `try`
won't be reached.
Also `on_break` doesn't seem really important since that code can be
On 14.07.20 09:54, Mathew Elman wrote:
What about adding `except` to the compound loop statement?
That way in cases where there needs to be clarity you can raise a
specific exception rather than just `break`.
Keeping the logic of why you "break" the loop inside the loop and
would also allow
On 09.07.20 21:04, Ethan Furman wrote:
On 07/03/2020 05:03 PM, Steven D'Aprano wrote:
def clamp(value, lower, upper):
"""Clamp value to the closed interval lower...upper.
The limits lower and upper can be set to None to
mean -∞ and +∞ respectively.
On 09.07.20 14:25, Chris Angelico wrote:
On Thu, Jul 9, 2020 at 9:16 PM Steven D'Aprano wrote:
Unless I have missed any others, we've only seen three use-cases:
(a) The original post wanted a full sequence API for dictionaries, with
the ability to insert keys at a specific index, not just
On 08.07.20 17:19, Jonathan Fine wrote:
Hi All
This is related to discussion
https://mail.python.org/archives/list/python-ideas@python.org/thread/KWAOQFSV3YJYQV2Y5JXGXFCXHJ3WFLRS/#ZT3OBOPNIMXQ2MU7N5RFBL5AJSYRZJ6Q
In Python, lists don't have a join method. Instead, it's strings that
have the
On 08.07.20 15:09, Hans Ginzel wrote:
Why not to allow tuple as a list index?
T = [[11, 12, 5, 2], [15, 6, 10], [10, 8, 12, 5], [12, 15, 8, 6]]
print(T[1][2])
10
print(T[1, 2])
Traceback (most recent call last):
File "", line 1, in
TypeError: list indices must be integers or slices, not
On 07.07.20 19:41, Stephen J. Turnbull wrote:
Dominik Vilsmeier writes:
> Well, the point is that this "except comparisons" is not quite true:
>
> >>> i = {'a': []}.items()
> >>> s = {('a', 1)}
> >>> i == s
>
On 07.07.20 19:09, Christopher Barker wrote:
On Tue, Jul 7, 2020 at 6:56 AM Dominik Vilsmeier
mailto:dominik.vilsme...@gmx.de>> wrote:
Well, the point is that this "except comparisons" is not quite true:
>>> i = {'a': []}.items()
>>>
On 07.07.20 17:37, Inada Naoki wrote:
On Tue, Jul 7, 2020 at 10:52 PM Dominik Vilsmeier
wrote:
Surely that must be a relic from pre-3.7 days where dicts were unordered
and hence order-based comparison wouldn't be possible (though PEP 3106
describes an O(n*m) algorithm). However the current
On 05.07.20 16:56, Stephen J. Turnbull wrote:
Steven D'Aprano writes:
> Regarding your observation that dict views behave poorly if they
> have unhashable values, I agree, it is both odd and makes them less
> useful. Possibly at some point between the PEP and the release of
> the
On 01.07.20 13:32, Steven D'Aprano wrote:
On Wed, Jul 01, 2020 at 01:07:34PM +0200, Dominik Vilsmeier wrote:
What is the reason for `dict.items` to return a set-like object?
This is the third time I've linked to the PEP:
https://www.python.org/dev/peps/pep-3106/
Thanks for linking
On 30.06.20 05:08, Steven D'Aprano wrote:
On Tue, Jun 30, 2020 at 11:10:20AM +0900, Inada Naoki wrote:
On Mon, Jun 29, 2020 at 9:12 PM Hans Ginzel wrote:
What are the reasons, why object dict.items() is not subscriptable –
dict.items()[0]?
Because dict is optimized for random access by key
On 16.06.20 10:00, redrad...@gmail.com wrote:
You cannot trust PyPi either ...
I think user should decide if it allows code from arbitrary URL to access
filesystem, network or anything else as `wasmtime` and `deno` did
If you want to do this, you can still download the code and use
On 14.06.20 17:52, David Mertz wrote:
On Sun, Jun 14, 2020, 10:22 AM Greg Ewing mailto:greg.ew...@canterbury.ac.nz>> wrote:
On 15/06/20 12:39 am, Sebastian M. Ernst wrote:
> It's such a common problem when dealing with floating point numbers
Is it really? I've done quite a lot of
On 16.06.20 08:40, Paul Sokolovsky wrote:
Hello,
On Tue, 16 Jun 2020 14:37:39 +0900
"Stephen J. Turnbull" wrote:
Soni L. writes:
> so I propose a \z string escape which lets me write the above as
> shown below:
>
> """switches to toml config format. the old
>
On 29.05.20 20:38, David Mertz wrote:
On Fri, May 29, 2020 at 1:56 PM Rhodri James mailto:rho...@kynesim.co.uk>> wrote:
Presumably "delayed" is something that would be automatically
applied to
the actual parameter given, otherwise your call graphs might or might
not actually be
On 29.05.20 15:09, Chris Angelico wrote:
On Fri, May 29, 2020 at 10:51 PM Steven D'Aprano wrote:
On Thu, May 28, 2020 at 08:04:07PM +1000, Chris Angelico wrote:
If it's a
language feature, then the name 'x' must be in the state of "local
variable without a value".
Oh ho, I see what you are
On 28.05.20 17:44, Christopher Barker wrote:
On Thu, May 28, 2020 at 3:50 AM Alex Hall mailto:alex.moj...@gmail.com>> wrote:
On Thu, May 28, 2020 at 12:38 PM Greg Ewing
mailto:greg.ew...@canterbury.ac.nz>>
wrote:
But I'm having trouble thinking of one. I can't remember
hat reason... Unfortunately, so far,
actually using of.NA is cumbersome, but hopefully that gets better
next version.
I wouldn't say it's an abuse, it's an interpretation of these values.
Using NaN has the clear advantage that it fits into a float array so
it's memory efficient.
Within actual Pand
On 26.05.20 06:03, David Mertz wrote:
On Mon, May 25, 2020, 11:56 PM Christopher Barker
well, yes and no. this conversation was in the context of "None"
works fine most of the time.
How many functions take None as a non-sentinel value?! How many of
that tiny numbers do so only
On 25.05.20 18:29, Chris Angelico wrote:
On Tue, May 26, 2020 at 2:24 AM Dominik Vilsmeier
wrote:
On 25.05.20 17:29, Ricky Teachey wrote:
On Mon, May 25, 2020, 6:49 AM Rob Cliffe via Python-ideas
wrote:
(Possibly heretical) Thought:
ISTM that when the decision was made that arg default
On 25.05.20 17:29, Ricky Teachey wrote:
On Mon, May 25, 2020, 6:49 AM Rob Cliffe via Python-ideas
mailto:python-ideas@python.org>> wrote:
(Possibly heretical) Thought:
ISTM that when the decision was made that arg default values
should be evaluated
once, at function
On 25.05.20 03:03, Rob Cliffe via Python-ideas wrote:
On 24/05/2020 21:03, Dominik Vilsmeier wrote:
On 24.05.20 18:34, Alex Hall wrote:
OK, let's forget the colon. The point is just to have some kind of
'modifier' on the default value to say 'this is evaluated on each
function call
On 24.05.20 19:38, David Mertz wrote:
As syntax, I presume this would be something like:
output = []
for x in data:
a = delayed inc(x)
b = delayed double(x)
c = delayed add(a, b)
output.append(c)
total = sum(outputs) # concrete answer here.
Obviously the simple example of adding
On 24.05.20 18:34, Alex Hall wrote:
OK, let's forget the colon. The point is just to have some kind of
'modifier' on the default value to say 'this is evaluated on each
function call', while still having something that looks like
`arg=`. Maybe something like:
def func(options=from
On 09.05.20 22:16, Andrew Barnert wrote:
On May 9, 2020, at 02:58, Dominik Vilsmeier wrote:
Initially I assumed that the reason for this new functionality was
concerned with cases where the types of two objects are not precisely
known and hence instead of converting them to a common type
On 09.05.20 14:16, Dominik Vilsmeier wrote:
On 09.05.20 12:18, Alex Hall wrote:
On Sat, May 9, 2020 at 11:57 AM Dominik Vilsmeier
mailto:dominik.vilsme...@gmx.de>> wrote:
So as a practical step forward, what about providing a wrapper type
which performs all operations eleme
On 09.05.20 12:18, Alex Hall wrote:
On Sat, May 9, 2020 at 11:57 AM Dominik Vilsmeier
mailto:dominik.vilsme...@gmx.de>> wrote:
So as a practical step forward, what about providing a wrapper type
which performs all operations elementwise on the operands. So for
e
On 08.05.20 19:01, Steven D'Aprano wrote:
All this proposal adds is *duck-typing* to the comparison, for when
it doesn't matter what the container type is, you care only about the
values in the container. Why be forced to do a possibly expensive (and
maybe very expensive!) manual coercion to a
On 07.05.20 09:38, Stephen J. Turnbull wrote:
Christopher Barker writes:
> So while yes, alternate constructors are a common pattern, I don't
> think they are a common pattern for classes like zip.
That's a matter of programming style, I think. There's no real
difference between
On 07.05.20 11:11, Steven D'Aprano wrote:
On Sat, May 02, 2020 at 05:12:58AM -, Ahmed Amr wrote:
Currently, when comparing a list of items to an array of the same
items for equality (==) it returns False, I'm thinking that it would
make sense to return True in that context, as we're
On 05.05.20 15:35, Dan Sommers wrote:
On Tue, 5 May 2020 23:06:39 +1000
Steven D'Aprano wrote:
... help me solve the DRY problem for module-level functions:
def function(spam, eggs, cheese, aardvark):
do stuff
call _private_function(spam, eggs, cheese, aardvark)
On 04.05.20 16:14, Steven D'Aprano wrote:
On Sun, May 03, 2020 at 09:41:00PM -0700, Christopher Barker wrote:
On Sun, May 3, 2020 at 6:17 PM Steven D'Aprano wrote:
map(func, x, y, strict=True) # ?
Admittedly the word "strict" in the context of `map` would be rather
confusing.
This
ython-ideas] Re: PEP 618: Add Optional Length-Checking To zip
On 2020-05-04 13:17, Dominik Vilsmeier wrote:
"strict" doesn't say what it's being strict about. That information
has to be inferred by the reader.
[snip]
And "equal" doesn't say what it's equal.
What we need is a
There could be other modes, such as `mode="repeat"` which reuses the
last value of each iterator as a fillvalue, or `mode="wrap"` which is
similar to `zip(*(it.cycle(x) for x in its))`.
So indeed a binary flag protects from additional requests to further
overload that function. This can be a
"strict" doesn't say what it's being strict about. That information has
to be inferred by the reader. As a keyword argument I'd expect it to
relate to the function's main purpose, so for `zip` I can understand how
this refers to the arguments (since their items end up in the resulting
tuples).
If `zip` gets a `strict` keyword-only parameter, a slightly related
question is whether `map` should also receive one?
`map` can be used as zip + transform:
map(func, x, y)
(func(a, b) for a, b in zip(x, y)) # similar
Now if I'm using the first option and I want to enable the strict
`frozenset` and `set` make a counterexample:
>>> frozenset({1}) == {1}
True
On 02.05.20 22:36, Guido van Rossum wrote:
It does look like that would violate a basic property of `==` -- if
two values compare equal, they should be equally usable as dict keys.
I can't think of any counterexamples.
On 22.04.20 11:19, Steven D'Aprano wrote:
On Wed, Apr 22, 2020 at 10:52:44AM +0200, Dominik Vilsmeier wrote:
You can basically use the code from this StackOverflow answer (code
attached below) to cache the last object yielded by each iterator:
https://stackoverflow.com/a/61126744
Caching
On 22.04.20 06:43, Soni L. wrote:
On 2020-04-21 7:12 p.m., Steven D'Aprano wrote:
On Tue, Apr 21, 2020 at 05:33:24PM -0300, Soni L. wrote:
> 1. see the other thread (strict zip), especially the parts where
they > brought up the lack of peekable/unput iterators in the context
of > getting
On 20.04.20 12:52, Steven D'Aprano wrote:
On Mon, Apr 20, 2020 at 11:15:32AM +0200, Alex Hall wrote:
On Mon, Apr 20, 2020 at 2:48 AM Steven D'Aprano wrote:
I have an actual, concrete possible enhancement in mind: relaxing the
restriction on parameter order.
What? Do you think that the
On 19.04.20 12:57, Steven D'Aprano wrote:
On Sat, Apr 18, 2020 at 09:13:44PM +0200, Dominik Vilsmeier wrote:
func(foo, **, bar) vs. func(foo, **{bar})
It's still a mode switch, only the beginning and end markers have
changed. Instead of `**,` (or `**mapping,`) we
On 18.04.20 08:14, Steven D'Aprano wrote:
This proposal is an alternative to Rodrigo's "Keyword arguments
self-assignment" thread.
Rodrigo, please feel free to mine this for useful nuggets in your PEP.
(I don't claim to have invented the syntax -- I think it might have been
Alex Hall?)
On 17.04.20 10:53, Steven D'Aprano wrote:
I think that, as little as I like the original proposal and am not
really convinced it is necessary, I think that it is better to have the
explicit token (the key/parameter name) on the left, and the implicit
token (blank) on the right:
key=
I
On 17.04.20 23:18, Andrew Barnert via Python-ideas wrote:
On Apr 17, 2020, at 13:39, Alex Hall wrote:
I also find the example with :keyword a bit jarring at first glance,
so I propose a double colon to alleviate the problem if we go in
that direction. Compare:
{ :a, "b": x, :c }
{
On 17.04.20 12:49, Alex Hall wrote:
But this means the reader could miss the star, especially with a
very large function call over multiple lines, and if that reader
happens to use that particular function A LOT and know the
parameter order without having to look they would
I agree that introducing a new way for creating implicit dict literals
only for the purpose of saving on keyword arguments seems too much of a
change. Although it would be an elegant solution as it builds on already
existing structures. And I don't think it hurts readability for function
calls,
On 16.04.20 22:28, Alex Hall wrote:
On Thu, Apr 16, 2020 at 10:13 PM Kyle Stanley mailto:aeros...@gmail.com>> wrote:
Dominik Vilsmeier wrote:
> I'm not sure if this is doable from the compiler perspective,
but what
> about allowing tuples after `*
I'm not sure if this is doable from the compiler perspective, but what
about allowing tuples after `**` unpacking:
requests.post(url, **(data, params))
# similar to
requests.post(url, data=data, params=params)
Probably some magic would need to happen in order to merge the names
For function definitions, the introduction of `*` to mark keyword-only
parameters was consistent with existing syntax in a sense that `def
foo(*args, bar)` had `args` consume all positional arguments, so `bar`
can only be passed via keyword. Now using `def foo(*, bar)` just omits
the positional
On 12.04.20 02:20, Soni L. wrote:
I figured something better instead. you can have a class ESpace, but
you use it like so:
espace = ESpace()
try:
foo(espace=espace)
except espace.module.submodule.Exception:
...
e.g. for builtins:
espace = ESpace()
try:
If I understand correctly, you want a way for distinguishing between
exceptions that were explicitly and intentionally `raise`'ed as part of
an API and exceptions that were unintentionally raised due to bugs. So
for example:
raise ValueError(f'Illegal value for xyz: {xyz}') # part of the
On Thu, 12 Mar 2020 at 21:10, Dominik Vilsmeier
wrote:
If I wanted to split the computation over multiple lines and yet have it
optimized I would just reuse the same (target) name instead of creating
a temporary one and then discarding it in the next step:
a = b * c
a += d
I agree, a warning that is never converted to an error indicates that
this is more about style than behavior (and in that sense it is use case
specific). It would also be annoying for people that intentionally
iterate over strings and find this a useful feature.
So this sounds more like the job
for the sake of auto-complete or syntax
highlighting, this is on the IDE and not on the language, in my opinion.
On 24.02.20 17:48, David Mertz wrote:
I get auto-complete on column names in Pandas when I'm in Jupyter. But
yes, I agree with you.
On Mon, Feb 24, 2020, 11:43 AM Dominik Vilsmeier
On 24.02.20 13:24, Rhodri James wrote:
This seems a lot like trying to shoehorn something in so one can write
idiomatic R in Python. That on the whole sounds like a bad idea; a
friend of mine use to say he could write FORTRAN in any language but
no one else could read it. Wouldn't it be more
I don't see what's wrong with the status quo:
smf.ols(formula='Lottery ~ Literacy + Wealth + Region', data=df)
If I understand correctly you want to use instead:
smf.ols(formula=df.Lottery ~ df.Literacy + df.Wealth + df.Region)
Or since some people favor indexing over attribute access
I also use PyCharm but I don't fold comprehensions; ideally I don't have to since comprehensions are meant to be simple and concise. Folding a comprehension takes away all the information, including the input to the operation.Regarding names, the example function you presented, `clean`, isn't
ing the walrus
operator.
I specifically discussed the walrus operator solution, but both you and Dominik Vilsmeier seem to have missed that.
> I'd use the list constructor with a
> named function anyway, rather than inlining it in a comprehension. I
> consider that m
This syntax basically allows to put any code from functions into comprehensions. This enables people to write fewer functions at the cost of more complex comprehensions. But functions are a good idea indeed:* They have a name and from that name it should be clear what that function does
Dan Sommers wrote:
> On Wed, 5 Feb 2020 11:09:16 +
> Jonathan Fine jfine2...@gmail.com wrote:
> > How about something like:
> > def t1(argv):
> > ... value = 0
> > ... for n in argv:
> > ... value = 1_000
> > ... value += n
> > ... return value
> > t1(123, 456, 789)
Steve Jorgensen wrote:
> After messing around with Enum for a while, there's one small thing that
> I'd like to see improved. It seems limiting to me that the only way to trigger
> _generate_next_value is to pass auto().
> What if, for a particular Enum, I would like to be able to use
> () as a
Jan Greis wrote:
> On 22/10/2019 06:43, Richard Musil wrote:
> > It is not a "concatenation" though, because you lost
> > {"key1": "val1"}
> > in the process. The concatenation is not _just_ "writing something
> > after something", you can do it with anything, but the actual
> > operation,
I don't see what's wrong with `["one", "two", "three"]`. It's the most explicit
and from the compiler perspective it's probably also as optimal as it can get.
Also it doesn't hurt readability. Actually it helps. With syntax highlighting
the word boundaries immediately become clear.
If you're
Steven D'Aprano wrote:
> On Sat, Oct 19, 2019 at 02:02:43PM -0400, David Mertz wrote:
> > The plus operation on two dictionaries feels far more
> > natural as a
> > vectorised merge, were it to mean anything. E.g., I'd expect
> > {'a': 5, 'b': 4} + {'a': 3, 'b': 1}
> > {'a': 8, 'b': 5}
> >
Steven D'Aprano wrote:
> On Sat, Oct 19, 2019 at 02:02:43PM -0400, David Mertz wrote:
> > The plus operation on two dictionaries feels far more
> > natural as a
> > vectorised merge, were it to mean anything. E.g., I'd expect
> > {'a': 5, 'b': 4} + {'a': 3, 'b': 1}
> > {'a': 8, 'b': 5}
> >
Steven D'Aprano wrote:
> On Sun, Oct 20, 2019 at 11:29:54PM -0000, Dominik Vilsmeier wrote:
> > The question is, why would someone who has experience
> > with adding
> > counters but never felt the need to add dicts, assume that this
> > behavior is specialized i
Steven D'Aprano wrote:
> On Sun, Oct 20, 2019 at 11:48:10PM -0000, Dominik Vilsmeier wrote:
> > Regarding "|" operator, I think a drawback is the
> > resemblance with
> > "or" (after all it's associated with "__or__") so people might assume
>
Guido van Rossum wrote:
> So the choice is really only three way.
> 1) Add d1 + d2 and d1 += d2 (using similarity with list + and +=)
> 2) Add d1 | d2 and d1 |= d2 (similar to set | and |=)
> 3) Do nothing
> We're not going to introduce a brand new operator for this purpose, nor are
> we going to
Guido van Rossum wrote:
> So the choice is really only three way.
> 1) Add d1 + d2 and d1 += d2 (using similarity with list + and +=)
> 2) Add d1 | d2 and d1 |= d2 (similar to set | and |=)
> 3) Do nothing
> We're not going to introduce a brand new operator for this purpose, nor are
> we going to
Christopher Barker wrote:
> On Sat, Oct 19, 2019 at 3:14 PM Dominik Vilsmeier dominik.vilsme...@gmx.de
> wrote:
> > I like the proposal of adding an operator but I
> > dislike the usage of "+".
> > I'd expect this to do a recursive merge on the dict values f
I like the proposal of adding an operator but I dislike the usage of "+". I'd
expect this to do a recursive merge on the dict values for duplicate keys (i.e.
adding the values), even more so since `Counter` (being a subclass of dict)
already has that behavior. I understand that "+" is meant as
Caleb Donovick wrote:
> > It captures a tiny fraction of Pandas style filtering
> > while complicating
> > the syntax of Python
> > Sure maybe I we can't represent all filters super concisely but at least
> inequalities, or any filter on single axis, would not be hard. E.g.
> db[x=LT(1)] ==
It might be interesting to note that Numpy provides various set routines
operating on their arrays (and hence lists as well, by conversion):
https://docs.scipy.org/doc/numpy/reference/routines.set.html
For
Andrew Barnert wrote:
> On Aug 29, 2019, at 16:03, Dominik Vilsmeier dominik.vilsme...@gmx.de wrote:
> > I never really understood the importance of
> > Optional. Often it can be left out altogether and in other cases I find
> > Union[T, None] more expressive (expl
Guido van Rossum wrote:
> On Thu, Aug 29, 2019 at 4:04 PM Dominik Vilsmeier dominik.vilsme...@gmx.de
> wrote:
> > I never really understood the importance of
> > Optional. Often it can be
> > left out altogether and in other cases I find Union[T, None] more
> > expre
I never really understood the importance of `Optional`. Often it can be left
out altogether and in other cases I find `Union[T, None]` more expressive
(explicit) than `Optional[T]` (+ the latter saves only 3 chars).
Especially for people not familiar with typing, the meaning of `Optional` is
This sounds to me like functionality of a specific type (more specific than
`dict`). `dict` can have any key-value pairs, it is not necessarily a nested
structure of dicts. Thus having a method for such a specific use case with the
general dict type doesn't feel right.
I think it's better if
What about using `(int, str)` for indicating a `Union`? This doesn't have
compatibility issues and it's similar to `isinstance(foo, (int, str))`, so it
should be fairly intuitive:
def bar(foo: (int, str) = 0):
...
Also it's similar to `get_args(Union[int, str])`.
Usually slices are created with integers such as `foo[1:5]`. However slices are
not restricted to having integers for the `start, stop, step` parameters and
thus can be used with any types. The most prominent example is probably
`pandas` which allows slicing by index (and the index can be `str`
Consider the following example:
import unittest
def foo():
for x in [1, 2, 'oops', 4]:
print(x + 100)
class TestFoo(unittest.TestCase):
def test_foo(self):
self.assertIs(foo(), None)
if __name__ == '__main__':
unittest.main()
If
Steven D'Aprano wrote:
> On Tue, Aug 13, 2019 at 06:01:27PM -0400, Eric V. Smith wrote:
> > dataclasses does something similar: it wants to know
> > if something is a
> > typing.ClassVar, but it doesn't want to import typing to find out.
> > Why not? Is importing typing especially expensive or a
Peter O'Connor wrote:
> 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) +
1 - 100 of 108 matches
Mail list logo
