> On Feb 11, 2020, at 14:02, Eric V. Smith wrote:
>
> One of the goals of the async/await syntax is to make it clear where control
> can yield, and therefor where you need to be concerned about mutating state.
> You don't have this explicitness with threads or with a hypothetical syntax
>
Thanks all for the feedback! I especially appreciate that a couple of you
pointed out that because I am avoiding the standard library threading
constructs like futures I could be limiting the use of other features they
provide. (I am experiencing that issue with other wrapped libraries in my
> Honestly I don't see why the PEP even needs to bring up the matrix multiply
> operator.
I was on the fence when writing this draft anyways. Given that the feedback
ranges from "this problem should be dismissed differently" to "this isn't a
problem", I think I'll just go ahead and drop it. :)
Honestly I don't see why the PEP even needs to bring up the matrix multiply
operator. There is no ambiguity, and there is no backwards compatibility
issue.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*
> i spent a minute or two looking via github search and found this library that
> uses @ for currying...
> fn-compose looks like the right thing...
Hm, exploring these a bit more, both libraries are unstable, haven't been
updated in several years, and have no watchers, stars, or dependents on
On 2/11/2020 2:33 AM, Ben Rudiak-Gould wrote:
On Mon, Feb 10, 2020 at 9:50 AM Andrew Barnert via Python-ideas
wrote:
It’s a well-known problem that async is “contagious”: [...]
But C# and every other language that’s borrowed the idea has the same problem,
and as far as I know, nobody’s
On 02/11/2020 11:49 AM, jdve...@gmail.com wrote:
My point is: is it good to add a new way of causing side effects in assertions?
Good or not, it's not changing now.
It's probably safe to say that every new language feature adds one more way to
break assertions. It is our responsibility to
Yes =
The Walrus operator, poorly used, can caused the problem in the OP, and
many, many others.
It does not make a difference - we discussed and got to the conclusion that
the benefits
of having it surpass whatever bad uses people put it for.
It clearly does not make sense to try to modify
I should perhaps provide a link to the relevant discussion in the Lua
mailing list. For what it's worth, you'll only be looking at C.
https://marc.info/?l=lua-l=157312955532763=2
On 2020-02-11 4:55 p.m., jdve...@gmail.com wrote:
Sorry, Soni, I do no speak Lua. Can you provide any
On Wed, Feb 12, 2020 at 6:51 AM wrote:
>
> Good point, Brandt. However, `global` is not used in the assertion itself as
> walrus operator can be.
>
> My point is: is it good to add a new way of causing side effects in
> assertions?
>
My point is: Is it good to find extremely stupid things that
Sorry, Soni, I do no speak Lua. Can you provide any documentation on that
point? I have found a function called assert but I am not sure that it works
like assertions in Python.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe
Good point, Brandt. However, `global` is not used in the assertion itself as
walrus operator can be.
My point is: is it good to add a new way of causing side effects in assertions?
Thank you.
___
Python-ideas mailing list -- python-ideas@python.org
To
> However, in the case of assertions, a nice and secure feature of Python has
> been lost without any apparent benefit.
It's always been possible to have side effects from an assertion:
>>> always
Traceback (most recent call last):
File "", line 1, in
NameError: name 'always' is not defined
Lua is known for using assignments in asserts in C.
It can come in handy for more complex, multi-part assertions.
On 2020-02-11 4:10 p.m., jdve...@gmail.com wrote:
Hi,
Recently the idea has come to me that walrus operator can have some issues when
use in assertions.
I have been taught that
Hi,
Recently the idea has come to me that walrus operator can have some issues when
use in assertions.
I have been taught that assertions must not produce side effects at all. This
is a problem in languages such as C. But not in Python (until 3.8) since it
does not allow assignment
On Feb 11, 2020, at 10:27, Brandt Bucher wrote:
>
> Thanks for bringing this up; I didn't know that there were any libraries
> using @ like this.
>
> I've spent some time searching on Google, PyPI, and GitHub, though, and I
> can't find anything that advertise this functionality. Do you have
This github search seems to return more direct hits of this usage pattern:
https://github.com/search?l=Python=__matmul__+curry=Code
On Tue, Feb 11, 2020 at 11:38 AM Nathan wrote:
> It doesn't look like it's popular or used much, but i spent a minute or
> two looking via github search and found
It doesn't look like it's popular or used much, but i spent a minute or two
looking via github search and found this library that uses @ for currying:
https://github.com/kanales/spycy/blob/master/spycy/__init__.py#L87
On Tue, Feb 11, 2020 at 11:26 AM Brandt Bucher
wrote:
> Thanks for bringing
> I think it should start with a description of the current expression
> restrictions.
I agree that this would be a good addition. Thanks!
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to
Thanks for bringing this up; I didn't know that there were any libraries using
@ like this.
I've spent some time searching on Google, PyPI, and GitHub, though, and I can't
find anything that advertise this functionality. Do you have the names of any
of them handy, so I could perhaps add a
The idea on the OP can be fully implemented with ~10 lines of code in a
decorator -
which could be further factored out into a decorator-for-decorators:
```
import asyncio, inspect
def hybrid_decorator(func):
coro = inspect.iscoroutinefunction(func)
if coro:
async def
> there are no known examples of binary matrix multiplication results which may
> used as decorators.
This is misleading. There are multiple libraries on PyPI that wrap up functions
to add additional operators and methods including @ for compose. (It’s also
been proposed and rejected
>
> restrictions. It assumes the reader is familiar with them.
>
Yes please — it does note at the end that many people aren’t currently
aware of the restriction(s). Count me in that group.
I have always presumed that any expression that yielded a callable would
work.
But the PEP is quite clear
On 2/11/2020 10:58 AM, Brandt Bucher wrote:
I have just pushed the first draft of PEP 614:
https://www.python.org/dev/peps/pep-0614/
It proposes that the current decorator syntax restrictions be relaxed to allow
any valid expression. Please let me know what you think!
I think it should
I have just pushed the first draft of PEP 614:
https://www.python.org/dev/peps/pep-0614/
It proposes that the current decorator syntax restrictions be relaxed to allow
any valid expression. Please let me know what you think!
Brandt
___
Python-ideas
On 2020-02-11 4:33 a.m., Ben Rudiak-Gould wrote:
On Mon, Feb 10, 2020 at 9:50 AM Andrew Barnert via Python-ideas
wrote:
> It’s a well-known problem that async is “contagious”: [...]
>
> But C# and every other language that’s borrowed the idea has the same
problem, and as far as I know,
On Sat, Feb 08, 2020 at 10:07:27AM +1100, Steven D'Aprano wrote:
> YMMV and this is just my opinion, but personally I think that exception
> chaining is rarely useful even at the best of times. For me, the only
> time I care about "raise from" is to suppress exception chaining by
> setting the
This has been implemented already in attrs
https://www.attrs.org/en/stable/examples.html#keyword-only-attributes
so I think it makes sense to just translate this to dataclasses, or treat it as
a starting point for a discussion if there are any objections to 1-to-1
translation from attrs.
28 matches
Mail list logo
