Would a frozendict require that keys and values be hashable?
It seems to me that we would need this restriction to make a reasonably
universal frozendict that is, itself, hashable. With this restriction for
the general case, is there still sufficient value for everyone that is
asking for a frozend
May I propose `slice.L` as in "slice literal":
```
class slice:
...
class L:
"""Slice literal.
slice.L[1:2:3, 1] -> (slice(1, 2, 3), slice(1))
"""
@classmethod
def __class_getitem__(cls, item):
return item
```
On Mon, Jul 23, 2018 at 12:02 PM Joseph Jevnik w
I am rather fond of the idea of null-coalescing, at the very least, for
mutable default values:
def foo(a=None):
a ??= []
...
but I worry about the code messes we will run into with some of the other
options.
Woe be unto anyone forced to understand the behavior of:
thing?.attr?[key]?.su
Instead of `imath`, how about `math.integer` for the module name?
On Fri, Jul 13, 2018 at 9:20 AM Tim Peters wrote:
> [Steven D'Aprano]
>> > about 4.7 seconds to test 2**800 + 1;
>>
>> [Jeroen Demeyer]
>>
>>> In SageMath:
>>>
>>> sage: n = 2**800+1; timeit('is_prime(n)')
>>> 625 loops, best of
Semantically, I'm not sure append and extend would be universally
understood to mean don't overwrite.
This can be accomplished with a custom subclass for your use case:
```
import collections
class OverwriteGuardedDict(collections.UserDict):
def append(self, key, value):
if key in s
I have had plenty of instances where destructuring a mapping would have be
convenient. Relating to iterable destructuring, I would expect the syntax
to be of the form "variable: key". I also think the curly-braces make it
harder to visually parse what's going on. So I might suggest something a
litt
I worry about the use of "for" because it will come up in contexts where
"for" already has other meanings. In the case of the example list
comprehension, the word "for" is being used to mean two entirely different
things in a single expression, that seems rather precarious to me.
I prefer "with" i
I really like this proposal in the context of `while` loops but I'm
lukewarm in other contexts.
I specifically like what this would do for repeated calls.
Being able to replace all of these
md5 = hashlib.md5()
with open(filename, 'rb') as file_reader:
for chunk in iter(lambda: file_reader.re
With the stdlib argparse, subparsers can be defined and they can be marked
as required (though this is not documented) but they do not support a
"required" keyword. I think it would make everything more consistent if the
keyword existed.
This won't require any functional changes under the hood.
R
ote:
> I think that settles it -- there's no reason to try to implement this.
>
> On Mon, Jan 29, 2018 at 10:51 AM, George Leslie-Waksman > wrote:
>
>> attrs' seems to also not allow mandatory attributes to follow optional
>> one:
>>
>> In [14]: @a
, hash=None, init=True,
metadata=mappingproxy({}), type=None, converter=None)
On Fri, Jan 26, 2018 at 1:44 PM Guido van Rossum wrote:
> What does attrs' solution for this problem look like?
>
> On Fri, Jan 26, 2018 at 11:11 AM, George Leslie-Waksman > wrote:
>
>> Even if
itVars if you wanted to support them (the stock
> fields(cls) doesn't return them).
>
> For 3.8 we can consider changing dataclasses's APIs if we want to add this.
>
> Eric.
>
> On 1/25/2018 1:38 AM, George Leslie-Waksman wrote:
> > It may be possible but it mak
ry):
>
> @dataclass
> class Foo:
> some_default: dict = field(default_factory=dict)
>
> @dataclass(init=False) # This works
> class Bar(Foo):
> other_field: int
>
> --
> Ivan
>
>
>
> On 23 January 2018 at 03:33, George Leslie-Waksman
> wrote
So, I propose the addition of a keyword_only flag to the @dataclass
decorator that renders the __init__ method using keyword only arguments:
@dataclass(keyword_only=True)
class Bar(Foo):
other_field: int
--George Leslie-Waksman
___
Python-ideas mai
14 matches
Mail list logo
