On Sun, Dec 12, 2021 at 08:44:25PM -0500, Ricky Teachey wrote:
> I'll go ahead and throw this out there: I was talking to a friend about
> this and he pointed out something simple but astute.
>
> Will this be expected to work?
>
> class C:
> x: Annotated [Any, "spam"]
>
> help(C.x)
>
> Obv
Hi Steven,
On Sun, Dec 12, 2021 at 4:52 PM Steven D'Aprano wrote:
> I think you have identified a real pain point, function wrapping, but it
> is a much bigger pain point that just function defaults, and it won't be
> made appreciably worse by late-bound defaults.
Unfortunately I don't think eit
On 2021-12-12 16:22, Steven D'Aprano wrote:
On Sun, Dec 12, 2021 at 03:38:23PM -0800, Paul Bryan wrote:
OK, so it's not the type, except it kind of is.
Except it isn't annotating the type, it is annotating the attribute.
We don't annotate *types*:
int: Sequence[str]
That would be a re
On Mon, Dec 13, 2021 at 11:29 AM MRAB wrote:
>
> Hmm.
>
> What about something like this as a bit of syntax:
>
> def my_decorator(f):
> @wraps
> def wrapper(from my_decorator):
> return f(from my_decorator)
> return wrapper
>
> The idea is that in a fun
I'll go ahead and throw this out there: I was talking to a friend about
this and he pointed out something simple but astute.
Will this be expected to work?
class C:
x: Annotated [Any, "spam"]
help(C.x)
Obviously it shouldn't as things stand now because that's an
AttributeError.
But if I'm
On Mon, 2021-12-13 at 11:22 +1100, Steven D'Aprano wrote:
> On Sun, Dec 12, 2021 at 03:38:23PM -0800, Paul Bryan wrote:
>
> > OK, so it's not the type, except it kind of is.
>
> Except it isn't annotating the type, it is annotating the attribute.
>
> We don't annotate *types*:
>
> int: Sequ
On Sun, Dec 12, 2021 at 03:46:16PM -0800, Christopher Barker wrote:
> I know what a wink means, but I have no idea what your actual point is.
My actual point is that the annotation:
attr: int
is annotating the attribute named "attr". That's pretty basic
stuff: if you don't think that we've
On Wed, Dec 08, 2021 at 11:50:55AM -, tmkehrenb...@gmail.com wrote:
> A few weeks ago, I proposed on this mailing list to write docstrings for
> class attributes like this:
>
> @dataclass
> class A:
> x: int
> """Docstring for x."""
Perhaps I missed it, but I haven't seen anyone point
On 2021-12-12 23:49, Steven D'Aprano wrote:
On Sun, Dec 12, 2021 at 12:07:30PM -0700, Carl Meyer wrote:
I don't think this is a fair dismissal of the concern. Taken broadly,
function "wrapping" is extremely common, in the sense that what many
(most?) functions do is call other functions, and th
On Sun, Dec 12, 2021 at 03:38:23PM -0800, Paul Bryan wrote:
> OK, so it's not the type, except it kind of is.
Except it isn't annotating the type, it is annotating the attribute.
We don't annotate *types*:
int: Sequence[str]
That would be a regular variable or attribute called "int" that j
On Sun, Dec 12, 2021 at 12:07:30PM -0700, Carl Meyer wrote:
> I don't think this is a fair dismissal of the concern. Taken broadly,
> function "wrapping" is extremely common, in the sense that what many
> (most?) functions do is call other functions, and there is a wide
> spectrum of "wrapping" fr
On Sun, Dec 12, 2021 at 3:00 PM Steven D'Aprano wrote:
> > But what's being annotated, the type or the attribute?
>
> That's easy to test:
>
> >>> class A:
> ... attr: Annotated[int, "Doc string"]
> ...
> >>> int.__annotations__
> Traceback (most recent call last):
> File "", line 1, in
>
On Mon, 2021-12-13 at 09:57 +1100, Steven D'Aprano wrote:
> On Sun, Dec 12, 2021 at 12:48:36PM -0800, Paul Bryan wrote:
>
> > But what's being annotated, the type or the attribute?
>
> That's easy to test:
>
>
> > > > class A:
> ... attr: Annotated[int, "Doc string"]
> ...
> > > > int.__an
On Sun, Dec 12, 2021 at 12:48:36PM -0800, Paul Bryan wrote:
> But what's being annotated, the type or the attribute?
That's easy to test:
>>> class A:
... attr: Annotated[int, "Doc string"]
...
>>> int.__annotations__
Traceback (most recent call last):
File "", line 1, in
AttributeError
Thank you for this, Carl. This is an excellent point, and well
articulated. I agree it's important.
I also agree that this should be addressed in the PEP. If nothing else,
it needs to be listed in a "Discussion" section, or similar. I think
pointing to your email would be a good start.
Eric
On Sun, 2021-12-12 at 12:23 -0800, Christopher Barker wrote:
> As for Typing.Annotated: it has one advantage in that typing tools
> currently (presumably) already accommodate extracting the type
> information from it -- see what typing.get_type_hints() does.
Confirmed. I have tooling today using
On Sat, Dec 11, 2021 at 10:55 PM Steven D'Aprano
wrote:
> If dataclasses, and other classes, move to using Annotated and
> __attrdoc__ for docstrings,
OK -- THAT is the point I brought up earlier, and you responded with "this
is settled" -- it's the __attrdoc__ part that needs to be standardiz
This may be a poor choice of time to wade into PEP 671 discussion,
since the consensus seems to be that the thread has exhausted its
usefulness. But there is one specific aspect of the discussion which
(it seems to me, though I may have missed some of the hundreds of
emails) has gotten inadequate d
On Sun, Dec 12, 2021, 1:57 AM Steven D'Aprano wrote:
On Sun, Dec 12, 2021 at 12:38:06AM -0500, Ricky Teachey wrote:
> But Steve, since the most utilized documentation tool in the python
> universe, sphinx, doesn't look at Annotated
Yet.
> or in the lowercase-annotation part of an expression
Y
Rob Cliffe via Python-ideas writes:
> If people have alternative proposals, it's up to them to propose
> them.
I don't understand why you focus on proposals that don't exist yet.
Both alternatives that I can imagine have been proposed.
One alternative proposal is Steven d'Aprano's "put the thu
On Sun, Dec 12, 2021 at 10:25 PM Steven D'Aprano wrote:
>
> It seems to me that Chris is determined to push forward with his ideas
> for default expressions, regardless of the mostly-negative feedback on
> Python-Ideas. I'm also unsure whether he has tried to get any feedback
> on other forums, su
On Sun, Dec 12, 2021 at 06:29:17AM +, Rob Cliffe via Python-ideas wrote:
> That makes no sense to me. If people have alternative proposals, it's
> up to them to propose them. And to propose them as clearly and
> explicitly as possible. (Yes, I understand that writing a fully
> detailed s
On Sun, Dec 12, 2021 at 8:16 PM Stephen J. Turnbull
wrote:
>
> Chris Angelico writes:
>
> > By "alternative ideas", do you mean "alternative ways to implement
> > argument defaults",
>
> As you just phrased it, yes. I do not know how I can make that more
> obvious.
>
So if you ARE talking abou
On 12/12/2021 06:02, Stephen J. Turnbull wrote:
Chris Angelico writes:
Of course, the *thread* is generally about argument defaults, but
"everything" in it is not specifically about defaults. In *this*
subthread Eric was arguing for waiting for a facility for *generic*
deferral of expression
Chris Angelico writes:
> By "alternative ideas", do you mean "alternative ways to implement
> argument defaults",
As you just phrased it, yes. I do not know how I can make that more
obvious.
If you didn't mean what you wrote so generally, but really mean
"concrete, ready for copy-and-paste in
Christopher Barker writes:
> However, what I haven’t seen in this thread is discussion of what I think
> is the key question:
>
> Where/how should class attribute doc strings be stored?
>
> Tacked on to the class __doc__ ?
-10. They need to be accessible via the attribute name. You coul
26 matches
Mail list logo
