The proposed implementation of dataclasses prevents defining fields with
defaults before fields without defaults. This can create limitations on
logical grouping of fields and on inheritance.
Take, for example, the case:
@dataclass
class Foo:
some_default: dict = field(default_factory=dict)
@dataclass
class Bar(Foo):
other_field: int
this results in the error:
5 @dataclass
----> 6 class Bar(Foo):
7 other_field: int
8
~/.pyenv/versions/3.6.2/envs/clover_pipeline/lib/python3.6/site-packages/dataclasses.py
in dataclass(_cls, init, repr, eq, order, hash, frozen)
751
752 # We're called as @dataclass, with a class.
--> 753 return wrap(_cls)
754
755
~/.pyenv/versions/3.6.2/envs/clover_pipeline/lib/python3.6/site-packages/dataclasses.py
in wrap(cls)
743
744 def wrap(cls):
--> 745 return _process_class(cls, repr, eq, order, hash, init,
frozen)
746
747 # See if we're being called as @dataclass or @dataclass().
~/.pyenv/versions/3.6.2/envs/clover_pipeline/lib/python3.6/site-packages/dataclasses.py
in _process_class(cls, repr, eq, order, hash, init, frozen)
675 # in __init__. Use "self" if
possible.
676 '__dataclass_self__' if 'self' in
fields
--> 677 else 'self',
678 ))
679 if repr:
~/.pyenv/versions/3.6.2/envs/clover_pipeline/lib/python3.6/site-packages/dataclasses.py
in _init_fn(fields, frozen, has_post_init, self_name)
422 seen_default = True
423 elif seen_default:
--> 424 raise TypeError(f'non-default argument {f.name!r} '
425 'follows default argument')
426
TypeError: non-default argument 'other_field' follows default argument
I understand that this is a limitation of positional arguments because the
effective __init__ signature is:
def __init__(self, some_default: dict = <something>, other_field: int):
However, keyword only arguments allow an entirely reasonable solution to
this problem:
def __init__(self, *, some_default: dict = <something>, other_field: int):
And have the added benefit of making the fields in the __init__ call
entirely explicit.
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
Pickling uses an extensible protocol that lets any class determine how its instances can be deconstructed and reconstructed. Both `pickle` and `copy` use this protocol, but it could be useful more generally. Unfortunately, to use it more generally requires relying on undocumented details. I think we should expose a couple of helpers to fix that:
# Return the same (shallow) reduction tuple that pickle.py, copy.py, and _pickle.c would use pickle.reduce(obj) -> (callable, args[, state[, litems[, ditem[, statefunc]]]])
# Return a callable and arguments to construct a (shallow) equivalent object # Raise a TypeError when that isn't possible pickle.deconstruct(obj) -> callable, args, kw
So, why do you want these?
There are many cases where you want to "deconstruct" an object if possible. Pattern matching depends on being able to deconstruct objects like this. Auto-generating a `__repr__` as suggested in Chris's thread. Quick&dirty REPL stuff, and deeper reflection stuff using `inspect.Signature` and friends.
Of course not every type tells `pickle` what to do in an appropriate way that we can use, but a pretty broad range of types do, including (I think; I haven't double-checked all of them) `@dataclass`, `namedtuple`, `(a)attr.s`, many builtin and extension types, almost all reasonable types that use `copyreg`, and any class that pickles via the simplest customization hook `__getnewargs[_ex]__`. That's more than enough to be useful. And, just as important, it won't (except in intentionally pathological cases) give us a false positive, where a type is correctly pickleable and we think we can deconstruct it but the deconstruction is wrong. (For some uses, you are going to want to fall back to heuristics that are often right but sometimes misleadingly wrong, but I don't think the `pickle` module should offer anything like that. Maybe `inspect` should.)
The way to get the necessary information isn't fully documented, and neither is the way to interpret it. And I don't think it _should_ be documented, because it changes every so often, and for good reasons; we don't want anyone writing third-party code that relies on those details. Plus, a different Python implementation might conceivably do it differently. Public helpers exposed from `pickle` itself won't have those problems.
Here's a first take at the code.
def reduce(obj, proto=pickle.DEFAULT_PROTOCOL): """reduce(obj) -> (callable, args[, state[, litems[, ditem[, statefunc]]]]) Return the same reduction tuple that the pickle and copy modules use """ cls = type(obj) if reductor := copyreg.dispatch_table.get(cls): return reductor(obj) # Note that this is not a special method call (not looked up on the type) if reductor := getattr(obj, "__reduce_ex__"): return reductor(proto) if reductor := getattr(obj, "__reduce__"): return reductor() raise TypeError(f"{cls.__name__} objects are not reducible")
def deconstruct(obj): """deconstruct(obj) -> callable, args, kw callable(*args, **kw) will construct an equivalent object """ reduction = reduce(obj) # If any of the optional members are included, pickle/copy has to # modify the object after construction, so there is no useful single # call we can deconstruct to. if any(reduction[2:]): raise TypeError(f"{type(obj).__name__} objects are not deconstrutable") func, args, *_ = reduction # Most types (including @dataclass, namedtuple, and many builtins) # use copyreg.__newobj__ as the constructor func. The args tuple is # the type (or, when appropriate, some other registered # constructor) followed by the actual args. However, any function # with the same name will be treated the same way (because under the # covers, this is optimized to a special opcode). if func.__name__ == "__newobj__": return args[0], args[1:], {} # Mainly only used by types that implement __getnewargs_ex__ use # copyreg.__newobj_ex__ as the constructor func. The args tuple # holds the type, *args tuple, and **kwargs dict. Again, this is # special-cased by name. if func.__name__ == "__newobj_ex__": return args # If any other special copyreg functions are added in the future, # this code won't know how to handle them, so bail. if func.__module__ == 'copyreg': raise TypeError(f"{type(obj).__name__} objects are not deconstrutable") # Otherwise, the type implements a custom __reduce__ or __reduce_ex__, # and whatever it specifies as the constructor is the real constructor. return func, args, {}
Actually looking at that code, I think it makes a better argument for why we don't want to make all the internal details public. :)
Here are some quick (completely untested) examples of other things we could build on it.
# in inspect def deconstruct(obj): """deconstruct(obj) -> callable, bound_args Calling the callable on the bound_args would construct an equivalent object """ func, args, kw = pickle.deconstruct(obj) sig = inspect.signature(func) return func, sig.bind(*args, **kw)
# in reprlib, for your __repr__ to delegate to def auto_repr(obj): func, bound_args = inspect.deconstruct(obj) args = itertools.chain( map(repr, bound_args.args), (f"{key!r}={value!r}" for key, value in bound_args.kwargs.items())) return f"{func.__name__}({', '.join(args)})"
# or maybe as a class decorator def auto_repr(cls): def __repr__(self): func, bound_args = inspect.deconstruct(self) args = itertools.chain( map(repr, bound_args.args), (f"{key!r}={value!r}" for key, value in bound_args.kwargs.items())) return f"{func.__name__}({', '.join(args)})" cls.__repr__ = __repr__ return cls
I have worked with both C# and Python for a while now and there is one feature of C# I'm missing in the Python language.
This feature is the "nameof" operator. (https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators…).
The place I use this the most in C# is in `ToString()` methods or logging messages.
This makes sure the developer cannot forget to update the name of a member.
As an example I created this `Person` class.
```
class Person:
def __init__(self, name, age):
self.name = name
self.age = age
def __repr__(self):
return f"Person(name: {self.name}, age: {self.age})"
```
With the `nameof` operator this would look like the following:
```
class Person:
def __init__(self, name, age):
self.name = name
self.age = age
def __repr__(self):
return f"{nameof(Person)}({nameof(self.name)}: {self.name}, {nameof(self.age)}: {self.age})"
```
What do you think about this?
Hi,
I think it would be very helpful to have an additional argument (cancel for example) added to Executor.shutdown that cancels all pending futures submitted to the executor. Then context manager would gain the ability to abort all futures incase of a exception, additionally this would also implement the missing cuterpart of the multiprocessing module terminate, currently we only have close.
The types in most programming languages are only technical types. If a variable has a type, you may know that it is of type integer or double, but you don't know if it's a length or an area.
The types required are semantic types.
stypes: length
area
time
speed
scalar
allowed expressions: length = length
length + length : length
time = time
time + time : time
scalar * length : length
scalar * time : time
sqrt(area) : length
speed = speed
length / time : speed
foo : time
bar : length
baz : length
bar = 23
baz = 42.3
foo = 17.4
speed'variable = (bar + baz) / foo
baz = length'5
bar = length'foo
Python's dynamic type checking remains.
These type names are all user defined. A type name with a tick before an expression means that this expression has the semantic type of the type name. The function names in the allowed expressions statement don't need to be names of existing functions.
I would like to see possibility to put spaces
between the string prefix and the string literal
so I could write e.g. like this:
print (f "x: {x}")
IMO it would help with legibility especially
noticable with by proportional fonts.
Mikhail
I'd like to see the ability to do:
if x:
1
and if y:
2
or if z:
3
The truth table for these would be:
x | y | z | result
0 | _ | 0 | (none)
0 | _ | 1 | 3
1 | 0 | _ | 1,3
1 | 1 | _ | 1,2,3
and each statement is evaluated once, when encountered. (as such, y and
z may not be evaluated at all, if their evaluation is not necessary to
determine the outcome.)
This enables the usage of fallthrough - "or if" is a fallthrough case,
and the "or" in it is because its body gets evaluated either if the
parent if's body got evaluated, *or* if the orif expression is truthy.
"and if" is only suggested here for the sake of
analogy/consistency/something. we have "and" and "or" and it'd be kinda
weird to have "or if" without an "and if". it's equivalent to having a
nested "if" at the very end of the "if" body. (only runs if the parent
body ran *and* the expression is truthy.)
also, I'm sure some of you will argue that the truth table should look
more like this instead:
x | y | z | result
0 | _ | 0 | (none)
0 | _ | 1 | 3
1 | 0 | 0 | 1
1 | 0 | 1 | 1,3
1 | 1 | _ | 1,2,3
and I say, no it shouldn't. if it were to do this, you'd have a hard
time defining the semantics of elif and else for this. (just try it,
it'll make your head spin.)
Hello there,
If I have simply missed a double colon starting a for loop
File "./bbq.py", line 160
for config_file in config_files
^
SyntaxError: invalid syntax
the message is not as straightforward.
I am not sure what the status quo of these messages are, but: could it
be enhanced?
Ντέντος Σταύρος
In the PEP-3333[1] they say the following:
"""
After a sufficient number of servers and frameworks have implemented WSGI to provide field experience with varying deployment requirements, it may make sense to create another PEP, describing a deployment standard for WSGI servers and application frameworks.
"""
Did this happen already? Will this happen anytime?
[1] https://www.python.org/dev/peps/pep-3333/
