On 3/11/2021 1:41 AM, Paul Bryan wrote:
In my experience, a dataclass with more than a few attributes makes
using positional arguments unwieldy and error-prone.
Agreed, just like any function or class.
I would think something like @dataclass(kwonly=/bool/) with default of
False would be reasona
In my experience, a dataclass with more than a few attributes makes
using positional arguments unwieldy and error-prone.
I would think something like @dataclass(kwonly=bool) with default of
False would be reasonably clean to implement and understand.
While I appreciate supporting existing behavi
You're right, the goal of my PR is not to allow specifying keyword-only (or
positional-only) `__init__` parameters, but rather the goal is to allow child
classes to be defined with non-defaulted fields (with defaulted fields in
parent classes). Keyword-only parameters is simply an implementation
As I've said before, I'm not opposed to the feature of keyword-only
arguments. I think it would be a great addition.
However, the proposal from Laurie O is only for changing fields without
default values following fields with default values to be keyword-only.
At least that's how I understand
map and filter are already available as comprehension syntax
However zip and merge are tricky because you'd need to schedule all
`__anext__()` coroutines from all input AsyncIterables. The stdlib would need
to know how to spawn tasks in such a way they could be understood by the
framework that
I'm pretty opposed to the idea of adding this functionality *specifically for
JSON*, because JSON loading is not the only use case that could benefit from
the convenience and reduced verbosity.
I propose the following (including type annotations and tests):
https://repl.it/@maximum__/loadfile#m
You can also use typing.cast for the handful of cases where your particular
type checker (e.g. MyPy) fails to refine the type properly in a case like the
following:
def lookup_usernames(db, user_ids: Optional[List[int]] = None) -> List[str]:
if user_ids is None:
return []
By the way, a second problem with __getitem__ and __setitem__ is they are
really messy to type (and this likely would make it worse). If, however, there
was a new __getindex__ and __setindex__ with normal Python *args and **kwargs
symantics, that would be really easy to type. For example, when I
I've seen comments from Eric V Smith in this thread and in the PR. If he's
in favor and it can be done in a backwards compatible way then he can guide
you to acceptance and merging of your PR. But like all of us he has limited
time.
On Wed, Mar 10, 2021 at 6:15 AM Laurie O
wrote:
> I've had tens
I've had tens of people show interest in my proposal, asking what the blocker
is in acceptance. As far as I know, no Python developer has shown any interest
in it.
My proposal is to automatically make any non-default fields become keyword-only
`__init__` parameters, with no need to have any arg
10 matches
Mail list logo
