[Python-ideas] Re: Double "at" operator for matmul exponentiation
None of the other repeated infix operators follow the same "repeated application" relation that * and ** have, i.e. // isn't repeated division, << and >> aren't repeated inequality comparisons (whathever that may be), and == isn't repeated assignment. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/X6JVECQNENCOWXVVAXMMOYXW2HXR365G/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Structure Pattern for annotation
I guess you could work around this by exploiting the slicing operator: GenericClass[:(A, B)] It makes sense to use the : in the context of typing, but I can see how this syntax can be confusing. The least confusing implementation I could think of is to limit the use of GenericClass[:_] to tuples, lists, sets and dicts (and future callable type signatures?), i.e.; it should only be used for structural type pattern matching. Here is a simple demo: https://gist.github.com/jorenham/1c241a1cf33d2cc8235631b63fa8f279 ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/JDBJGEPF2HVRJKZIWDU6CM5SW7ABDWZQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP idea
See https://www.python.org/dev/peps/pep-0645/ ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UYSUJOZOWOYQ26CI5EXLZNAXUU3AUYON/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Why do we have two obvious ways to create a simple data structure? Let's deprecate one.
What about creating a dataclasses.datatuple decorator, that replaces typing.NamedTuple, and offers the same (or restricted) interface as regular dataclasses? This would make the distinction explicit between a mutable, object-like dataclass, and the immutable, tuple-like named-/datatuple. With this, we could also get rid of the fake-immutable frozen dataclasses. In the same way, a dataclasses.datadict could replace typing.TypedDict, which is very limited at this point anyway. So instead of trying to merge different concepts, let's use one create one interface to rule them all. Because, after all: "There should be one-- and preferably only one --obvious way to do it." ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VJ7WPV6564BJQDNGQZXC5HPCT22SKNM4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Currying syntax with multiple parameter lists
> Flat is better than nested. I remember being confused a lot when I was learning how to write my first decorator. Now eight years later, with the last two spent full-time writing Python, I introduced a bug in production because I forgot to return the inner function from within a decorator. By introducing multiple parameter lists when defining a function, Scala does a great job at improving readability for curried functions (https://docs.scala-lang.org/tour/multiple-parameter-lists.html). In Python, that could look like e.g.: def log(level=logging.DEBUG, logger=logging.root)(func)(*args, **kwargs): logger.log(level, 'call: %s', func.__qualname__) return func(*args, **kwargs) Which would be sugar for: def log(level=logging.DEBUG, logger=logging.root): def _log(func): def __log(*args, **kwargs): logger.log(level, 'call: %s', func.__qualname__) return func(*args, **kwargs) return __log return _log The obvious problem in this example, is that `functools.wraps` is missing. One solution would be for me to flex my 8 years of experience, and present these two (super/meta-)decorators: def wraps_decorator(decorator: Callable[[F], F]): @functools.wraps(decorator) def _wraps_decorator(func): return functools.wraps(func)(decorator(func)) return _wraps_decorator @wraps_decorator def wraps_decorator_factory(decorator_factory)(*args, **kwargs): return wraps_decorator(decorator_factory(*args, **kwargs)) Applying the latter on the first example, it becomes @wraps_decorator_factory def log(level=logging.DEBUG, logger=logging.root)(func)(*args, **kwargs): logger.log(level, 'call: %s', func.__qualname__) return func(*args, **kwargs) which is equivalent to: def log(level=logging.DEBUG, logger=logging.root): def _log(func): @functools.wraps(func) def __log(*args, **kwargs): logger.log(level, 'call: %s', func.__qualname__) return func(*args, **kwargs) return __log return _log Implementation-wise, I think it's very feasible since it's only sugar. And I'm sure that the required grammar changes are possible with the shiny new parser. And considering PEP 659, I can imagine that this syntax is beneficial because the closure variables coincide with the parameter lists. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2HGGXLQGGIUOG2ENLNAAT3YY6GPDD3DF/ Code of Conduct: http://python.org/psf/codeofconduct/
