I propose that:
def foo(print(x)):
pass
becomes:
def foo(x):
x = print(x)
pass
or, alternatively we could have decorators in function args:
def foo(@print x):
pass
which would probably be more aligned with the rest of python actually.
anyway, this would be nice I think. I could real
On 2/9/2020 7:34 AM, Soni L. wrote:
I propose that:
def foo(print(x)):
pass
becomes:
def foo(x):
x = print(x)
pass
or, alternatively we could have decorators in function args:
def foo(@print x):
pass
which would probably be more aligned with the rest of python actually.
anyway, thi
On 2020-02-09 9:44 a.m., Eric V. Smith wrote:
On 2/9/2020 7:34 AM, Soni L. wrote:
I propose that:
def foo(print(x)):
pass
becomes:
def foo(x):
x = print(x)
pass
or, alternatively we could have decorators in function args:
def foo(@print x):
pass
which would probably be more align
> On 9 Feb 2020, at 14:01, Soni L. wrote:
>
>
> into this:
>
> [snip]
>
> def my_fn(@MyTrait x):
> x.x()
Can't you look at typing info or something instead? That is a lot of
boilerplate and ceremony even after your proposed addition.
So:
@traits
def my_fn(x: MyTrait):
x.x()
/
On 2020-02-09 10:28 a.m., Anders Hovmöller wrote:
> On 9 Feb 2020, at 14:01, Soni L. wrote:
>
>
> into this:
>
> [snip]
>
> def my_fn(@MyTrait x):
> x.x()
Can't you look at typing info or something instead? That is a lot of
boilerplate and ceremony even after your proposed addition
Figuring out versioning is hard. PyPI should encourage semver by
including PEP 440 version strings that you can copy and paste into
install_requires. This'll encourage module authors to do their best to
follow semver.
And also it means I can copy and paste the things and my code won't
silentl
On Sun, 9 Feb 2020 at 14:39, Soni L. wrote:
>
> Figuring out versioning is hard. PyPI should encourage semver by
> including PEP 440 version strings that you can copy and paste into
> install_requires.
I don't understand what you mean by **PyPI** including version
strings. PyPI just publishes the
> On Feb 9, 2020, at 05:40, Soni L. wrote:
>
> I'd rather have arg decorators tbh. they feel more natural than hacking on
> the type annotations.
Annotations look a lot more natural to me here.
Maybe that’s because your only example (besides the useless original one) looks
like an implicit ca
On Feb 9, 2020, at 11:49, Andrew Barnert wrote:
>
> If there isn’t a library that puts it all together the way you want
I figured there probably was, so I decided to take a look. I got a whole page
of possibly useful things, and the first one I looked at, typical, shows this
as its first examp
On 2020-02-09 4:46 p.m., Andrew Barnert wrote:
> On Feb 9, 2020, at 05:40, Soni L. wrote:
>
> I'd rather have arg decorators tbh. they feel more natural than hacking on the type annotations.
Annotations look a lot more natural to me here.
Maybe that’s because your only example (besides the
On Mon, Feb 10, 2020 at 7:21 AM Soni L. wrote:
>
> > Maybe if you had a good example that wasn’t an implicit type cast, this
> > similarity would be an argument against using annotations rather than an
> > argument for using them? But it’s hard to know without seeing such an
> > example, or eve
>>> On Feb 9, 2020, at 12:20, Soni L. wrote:
>> On 2020-02-09 4:46 p.m., Andrew Barnert wrote:
>>> On Feb 9, 2020, at 05:40, Soni L. wrote:
I'd rather have arg decorators tbh. they feel more natural than hacking on
the type annotations.
>> Annotations look a lot more natural to me here
As of today, in order to make a decorator compatible with both normal and async
functions, you have to write something like this:
def decor(func):
if asyncio.iscoroutinefunction(func):
async def wrapper(*args, **kwargs):
...
await func(*args, **kwargs)
On Feb 9, 2020, at 13:39, [email protected] wrote:
>
> As of today, in order to make a decorator compatible with both normal and
> async functions, you have to write something like this:
>
> def decor(func):
>if asyncio.iscoroutinefunction(func):
>async def wrapper(*args, **kwarg
Daniel Spitz wrote:
>On Fri, Feb 7, 2020 at 1:51 PM Andrew Barnert [email protected] wrote:
> > That being said, if you have a use for the object graph walk, that
> > shouldn’t be too hard to write. It’s just that there
> > are nontrivial design
> > issues to answer. Do we need to expose the graph
On 2020-02-09 5:31 p.m., Chris Angelico wrote:
On Mon, Feb 10, 2020 at 7:21 AM Soni L. wrote:
>
> > Maybe if you had a good example that wasn’t an implicit type cast, this
similarity would be an argument against using annotations rather than an argument for
using them? But it’s hard to know
> On 10 Feb 2020, at 04:18, Soni L. wrote:
>
> Traits are composition tho. I think you missed something I said.
In that case I think we all missed it and then isn't that on you? Remember it
is you who are trying to convince the list so any information missed or
misunderstood is your problem
On Sun, Feb 9, 2020, 11:03 AM Paul Moore wrote:
> On Sun, 9 Feb 2020 at 14:39, Soni L. wrote:
> >
> > Figuring out versioning is hard. PyPI should encourage semver by
> > including PEP 440 version strings that you can copy and paste into
> > install_requires.
>
> I don't understand what you mean
On Mon, Feb 10, 2020 at 6:09 PM Matthew Einhorn wrote:
>
> On Sun, Feb 9, 2020, 11:03 AM Paul Moore wrote:
>>
>> On Sun, 9 Feb 2020 at 14:39, Soni L. wrote:
>> >
>> > Figuring out versioning is hard. PyPI should encourage semver by
>> > including PEP 440 version strings that you can copy and pas
19 matches
Mail list logo
