On Wed, Apr 22, 2015 at 2:00 PM, Ian Kelly wrote:
> On Tue, Apr 21, 2015 at 12:59 AM, Chris Angelico wrote:
>> plus, docstringargs
>> basically implies that all the function parameters are strings, so the
>> annotations are going to be rather less useful.
>
> Why is that? argparse supports non-st
On Tue, Apr 21, 2015 at 12:59 AM, Chris Angelico wrote:
> plus, docstringargs
> basically implies that all the function parameters are strings, so the
> annotations are going to be rather less useful.
Why is that? argparse supports non-string args, so why couldn't
docstringargs as well?
--
https
On Tue, Apr 21, 2015 at 4:46 PM, Paul Rubin wrote:
> Chris Angelico writes:
>> Ow, this is getting extremely complicated. And you still haven't
>> actually answered the fundamental problem, which is: When will you
>> need this? When will you actually want to put two different
>> annotations onto
Chris Angelico writes:
> Ow, this is getting extremely complicated. And you still haven't
> actually answered the fundamental problem, which is: When will you
> need this? When will you actually want to put two different
> annotations onto the same function's parameters?
You've posted this cool a
On Tue, Apr 21, 2015 at 3:54 PM, Paul Rubin wrote:
> Chris Angelico writes:
>> Other decorators have to be able to recognize whether there's an outer
>> dictionary or not. That means they have to dig into the annotating
>> object to inquire as to whether or not their thing is there.
>
> I'm imagi
Chris Angelico writes:
> Other decorators have to be able to recognize whether there's an outer
> dictionary or not. That means they have to dig into the annotating
> object to inquire as to whether or not their thing is there.
I'm imagining the annotation consumers themselves being wrapped by
so
Paul Rubin writes:
> If there's only one annotation it can take a dictionary without an outer
> one. If there's more than one annotation
Hmm, I see what you might be getting at: the decorators run
innermost-first so only the outer ones can tell if there are multiple
ones without some pretty bad
On Tue, Apr 21, 2015 at 3:08 PM, Paul Rubin wrote:
> Chris Angelico writes:
>> PEP 484 says that type hints don't need a decorator, but if it were
>> anything else, then yes, it'd need a second decorator. But what if one
>> of the annotation usages wants to be a dictionary? How can you elide
>> t
Chris Angelico writes:
> PEP 484 says that type hints don't need a decorator, but if it were
> anything else, then yes, it'd need a second decorator. But what if one
> of the annotation usages wants to be a dictionary? How can you elide
> the outer dictionary and still recognize what's going on?
On Tue, Apr 21, 2015 at 2:33 PM, Paul Rubin wrote:
> Chris Angelico writes:
>> @cmdline
>> def adduser(
>> user: {cmdline: "Name of user to add", typing: str},
>> password: {cmdline: "Password for the new user", typing: str}=""):
>> """Add a new user"""
>
> In the case of just
Chris Angelico writes:
> @cmdline
> def adduser(
> user: {cmdline: "Name of user to add", typing: str},
> password: {cmdline: "Password for the new user", typing: str}=""):
> """Add a new user"""
In the case of just one decorator, the dictionary could be omitted. The
decorato
On Tue, Apr 21, 2015 at 1:44 PM, Paul Rubin wrote:
> Chris Angelico writes:
>>> Does this conflict with type signature proposals
>> In the sense that you can't use both together, yes. But docstringargs
>> follows the rule of "if you're going to use annotations, also use a
>> decorator"; and the d
Chris Angelico writes:
>> Does this conflict with type signature proposals
> In the sense that you can't use both together, yes. But docstringargs
> follows the rule of "if you're going to use annotations, also use a
> decorator"; and the decorator removes all the annotations it uses.
This makes
On Tue, Apr 21, 2015 at 11:13 AM, Paul Rubin wrote:
> Chris Angelico writes:
>> @cmdline
>> def adduser(user: "Name of user to add", password: "Password for the
>> new user"=""):
>> """Add a new user"""
>
> Does this conflict with type signature proposals using that annotation
> mechanism? I
Chris Angelico writes:
> @cmdline
> def adduser(user: "Name of user to add", password: "Password for the
> new user"=""):
> """Add a new user"""
Does this conflict with type signature proposals using that annotation
mechanism? I guess that means PEP 0484 but I've lost track of what's
where.
On Mon, Apr 20, 2015 at 5:22 PM, Steven D'Aprano
wrote:
> On Monday 20 April 2015 16:20, Chris Angelico wrote:
>
>> Looking for comments, recommendations, advice that I've just wasted
>> half a day on something utterly useless, whatever it be!
>>
>> I've just posted a new (single-module) package t
On Monday 20 April 2015 16:20, Chris Angelico wrote:
> Looking for comments, recommendations, advice that I've just wasted
> half a day on something utterly useless, whatever it be!
>
> I've just posted a new (single-module) package to PyPI that simplifies
> the creation of an argparse UI for a p
17 matches
Mail list logo
