Here's a related idea you might be interested in:
https://github.com/pypa/pip/issues/5970
On Thu, Dec 17, 2020, 8:19 AM Yash Jha wrote:
> Many open-source developers are committing to several projects, developing
> package (for Python). A fraction of developers might need funds for the
> contin
I really like this idea!
I have very often had to create my own MISSING global in modules where None
might actually be a legitimate value for the dataclass member.
And additionally when I am doing thorough type hinting, I haved at times
ended up not only have to do the MISSING object, but a Missi
You could also do this using just the __init_subclass__ method. Create some
class AddMixin, and use it like:
class _(AddMixin, using=mod.Cls):
...
The AddMixin class is something like:
class AddMixin:
def __init_subclass_(cls, *, using, **kwargs):
super().__init_subclass__(**kwar
On Mon, Feb 15, 2021, 11:34 AM David Mertz wrote:
> On Mon, Feb 15, 2021 at 4:19 PM Guido van Rossum wrote:
>
>> Okay, here’s my dilemma. It looks like this thread wants to devise a new
>> syntax for lambda, using e.g. (x, y) -> x+y, or the same with =>. That’s
>> great, but doesn’t open new vis
On Mon, Feb 15, 2021 at 12:02 PM Ricky Teachey wrote:
> On Mon, Feb 15, 2021, 11:34 AM David Mertz wrote:
>
>> On Mon, Feb 15, 2021 at 4:19 PM Guido van Rossum
>> wrote:
>>
>>> Okay, here’s my dilemma. It looks like this thread wants to devise a new
>&g
On Mon, Feb 15, 2021 at 12:30 PM Guido van Rossum wrote:
> On Mon, Feb 15, 2021 at 9:02 AM Ricky Teachey wrote:
>
>> [...]
>> But if we could expand the proposal to allow both anonymous and named
>> functions, that would seem like a fantastic idea to me.
>>
On Mon, Feb 15, 2021 at 12:55 PM David Mertz wrote:
> On Mon, Feb 15, 2021, 12:26 PM Ricky Teachey
>
>> f(x,y)=>x,y->str
>>>
>>
> I read this as "my cat walked across my keyboard, and I'm very proud she
> wants to be a programmer."
>
Ou
>From other thread:
On Wed, Feb 17, 2021 at 5:19 AM Chris Angelico wrote:
> On Wed, Feb 17, 2021 at 9:11 PM Sven R. Kunze wrote:
> > Still think that "object()" should be writable since this seems like an
> > arbitrary restriction (+SimpleNamespace is no builtin and at least I
> > would use obj
On Wed, Feb 17, 2021 at 2:32 PM <[email protected]> wrote:
> On 2021-02-18 at 06:21:19 +1100,
> Chris Angelico wrote:
>
> > On Thu, Feb 18, 2021 at 1:53 AM Ricky Teachey wrote:
> > >
> > > I would personally love for SimpleNamespace to get
On Wed, Feb 17, 2021, 6:20 PM Daniel Moisset wrote:
> If we're bike shedding, I'd go for "mutableobject". It's not terribly
> short, but it is built on familiar python terminology and does exactly what
> it says in the box: like object() but mutable
>
That is a pretty good suggestion. I'd like
On Sat, Feb 20, 2021, 12:56 PM Jan Kaliszewski wrote:
> 2021-02-17 Ricky Teachey dixit:
>
> > * patsy
>
> I love this one! :-)
>
> Cheers.
> *j
>
> PS. But it should be callable and, when called, it should raise
> RuntimeError("It's only a model
On Wed, Feb 24, 2021 at 8:39 AM Paul Korir wrote:
> Hi All,
>
> I've been using the argparse library for a long time and one use case that
> repeatedly shows us is the need to have two arguments appear together i.e
> either both appear or none of them appear. I'll refer to these as *mutually
> in
This might be a bit of an extreme step to take, but has new syntax for this
ever been discussed? Here I am using the same indicator for keyword
arguments as in a function signature, hanging on a line by itself:
@dataclasses.dataclass
class Comparator:
a: Any
b: Any
*
key: Optional[
On Thu, Mar 11, 2021 at 10:00 AM Ethan Furman wrote:
> On 3/11/21 4:20 AM, Ricky Teachey wrote:
>
> > This might be a bit of an extreme step to take, but has new syntax for
> this ever been discussed? Here I am using the same indicator for keyword
> arguments as in a function
On Thu, Mar 11, 2021 at 10:20 AM Paul Bryan wrote:
> Given that @dataclass is a decorator, and otherwise you're just defining a
> class, some concerns:
>
> 1. Such proposed syntax would require a change to the language
> specification.
>
> 2. It would seem that / and * in a class not decorated wi
On Thu, Mar 11, 2021 at 11:59 AM Eric V. Smith wrote:
> On 3/11/2021 10:23 AM, Ricky Teachey wrote:
>
> On Thu, Mar 11, 2021 at 10:20 AM Paul Bryan wrote:
>
>> Given that @dataclass is a decorator, and otherwise you're just defining
>> a class, some concerns:
>&g
On Fri, Mar 12, 2021 at 4:52 PM Ethan Furman wrote:
> A question that comes up quite a bit on Stackoverflow is how to test to
> see if a value will result in an Enum member, preferably without having to
> go through the whole try/except machinery.
>
> A couple versions ago one could use a contain
Fwiw I read Eric's entire proposal (I like it) but totally missed the
presence of single, double, triple underscores.
Which caused me to be very confused reading Matt De Valle's reply, until I
went back and noticed them, and the lightbulb went on.
Based on that experience, and also Matt's comment
On Mon, Mar 15, 2021 at 2:28 PM Guido van Rossum wrote:
>
> ...
>>
>> I think I like your constructor change idea, with a small twist:
>>
>> Color(value=, name=, default=)
>>
>> This would make it possible to search for an enum by value or by name,
>> and also specify a default return value
On Tue, Mar 16, 2021 at 9:23 AM Eric V. Smith wrote:
> On 3/16/2021 7:01 AM, Simão Afonso @ Powertools Tech wrote:
> >> The problem is that if you have 1 normal parameter and 10 keyword-only
> >> ones, you'd be forced to say:
> >>
> >> @dataclasses.dataclass
> >> class LotsOfFields:
> >> a:
On Tue, Mar 16, 2021 at 10:03 AM Eric V. Smith wrote:
> On 3/16/2021 9:48 AM, Ricky Teachey wrote:
>
> On Tue, Mar 16, 2021 at 9:23 AM Eric V. Smith wrote:
>
>> On 3/16/2021 7:01 AM, Simão Afonso @ Powertools Tech wrote:
>> >> The problem is that if you have 1 n
On Tue, Mar 16, 2021 at 11:59 AM Eric V. Smith wrote:
> On 3/16/2021 10:06 AM, Ricky Teachey wrote:
>
> ...
> I think I prefer it, too. But what about using something like
> `mark=dataclasses.KW_ONLY` rather than `kw_only=True` (in the field
> constructor)? So it isn't an
On Wed, Mar 17, 2021, 5:34 AM Serhiy Storchaka wrote:
> 12.03.21 23:48, Ethan Furman пише:
> > A question that comes up quite a bit on Stackoverflow is how to test to
> > see if a value will result in an Enum member, preferably without having
> > to go through the whole try/except machinery.
> >
On Fri, Apr 9, 2021 at 3:20 AM Serhiy Storchaka wrote:
> 08.04.21 19:58, [email protected] пише:
> > I would like to propose adding literal syntax to allow creation of an
> empty set without the need to call the type constructor. I believe the best
> choice for such a literal, and one that has be
On Fri, Apr 9, 2021 at 1:30 PM David Mertz wrote:
> I don't do twitter, so hadn't seen Raymond's comment. But I agree that
> `{*()}` is too-clever-by-half. Moreover, it's the same character count as
> `set()`, so it doesn't even save anything.
>
> Using five characters to create an empty `set()
On Fri, May 14, 2021 at 12:02 PM Chris Angelico wrote:
> On Sat, May 15, 2021 at 1:47 AM Martin Teichmann
> wrote:
> >
> > Hi David,
> >
> > > A toy example with a half dozen operations won't make huge fractions. A
> > > loop over a million operations will often be a gigantic memory hog.
> >
> >
On Fri, May 14, 2021 at 1:14 PM André Roberge
wrote:
>
> You can already experiment with this.
>
>
> First, install a few packages
>
> python -m pip install ideas # will also install token-utils
> python -m pip install fraction-literal
>
>
> Next, start your standard Python interpreter and do th
On Fri, May 14, 2021 at 2:09 PM Ricky Teachey wrote:
> On Fri, May 14, 2021 at 1:14 PM André Roberge
> wrote:
>
>>
>> You can already experiment with this.
>>
>>
> Thanks Andre I tried it out and it works great.
>
> Do the appended capital Fs
On Tue, May 18, 2021, 8:07 AM Steven D'Aprano wrote:
> What's the actual problem you are solving with this complex, complicated
> proposal? In other words, what is the motivation? You mentioned symbolic
> maths in the previous thread.
>
It seems to me the motivation is only related to looks inso
On Tue, May 18, 2021 at 10:55 AM Paul Moore wrote:
> On Tue, 18 May 2021 at 15:16, Martin Teichmann
> wrote:
> >
> > Because reality. People would like to write 1/2 * m * v**2 to mean the
> obvious thing, without having to think about the details. And there are
> many people like this, this is w
On Tue, May 18, 2021, 9:18 PM Steven D'Aprano wrote:
> On Tue, May 18, 2021 at 05:21:28PM +0100, Oscar Benjamin wrote:
>
> > I think that maybe the best solution here is something more like a
> > domain-specific language that can be used with ipython/jupyter as an
> > alternative profile.
>
> Not
It's a neat idea but I agree with the others that as proposed, it's
probably too focused on turning python into a better mathematics tool,
rather than turning python into a better programming language.
That being said, from a more generalist standpoint I wonder if it would be
useful in many connec
On Sun, May 23, 2021, 9:35 AM Stestagg wrote:
> FYI, default here is unused.
>
Thanks! Yes I had put that at the first and intended to remove it.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to python-ideas-le..
On Sun, May 23, 2021, 12:02 PM Damian Shaw
wrote:
> FYI,
>
> Something very similar already exists in the standard library,
> contextlib.suppress:
> https://docs.python.org/3/library/contextlib.html#contextlib.suppress
>
> It makes a nice 2+ liner for a lot of situations:
>
> with suppress(Except
I don't have much of substance to say other than this proposal really made
me go "oh I like that" several times. There may be downsides/arguments
against I'm not considering, but I look forward to following the
conversation and hope it gets a serious hearing.
On Mon, May 24, 2021, 9:38 PM micro co
On Tue, May 25, 2021 at 8:11 AM Chris Angelico wrote:
> On Tue, May 25, 2021 at 5:29 PM Steven D'Aprano
> wrote:
> > Here's a counter-proposal: we have a special symbol which is transformed
> > at compile-time to the left hand assignment target as a string. Let's
> > say we make that special exp
On Tue, May 25, 2021 at 8:11 AM Chris Angelico wrote:
> On Tue, May 25, 2021 at 5:29 PM Steven D'Aprano
> wrote:
> > Here's a counter-proposal: we have a special symbol which is transformed
> > at compile-time to the left hand assignment target as a string. Let's
> > say we make that special exp
On Wed, May 26, 2021 at 7:54 AM Steven D'Aprano wrote:
> On Wed, May 26, 2021 at 01:33:07PM +0200, Stéfane Fermigier wrote:
>
> > Last point that I like in the decorator syntax: it's
> >
> > I can compose N different decorators and keep the intent obvious:
> >
> > @acl(READ, WRITE)
> > @constrain
n't either thinking about going home
or actually going home." - Happy Chandler
On Wed, May 26, 2021 at 12:43 PM Ricky Teachey wrote:
> On Wed, May 26, 2021 at 7:54 AM Steven D'Aprano
> wrote:
>
>> On Wed, May 26, 2021 at 01:33:07PM +0200, Stéfane Fermigier wrote:
On Wed, May 26, 2021 at 2:22 PM Matt del Valle wrote:
> I'm still digesting this proposal (though I think I like it quite a bit),
> but there's one thing in particular that just really doesn't gel with me.
>
> Is there any particular reason why you've proposed assignment decorators
> as being on
On Thu, May 27, 2021 at 8:19 AM Steven D'Aprano wrote:
> On Thu, May 27, 2021 at 07:56:16AM -, Shreyan Avigyan wrote:
>
> > This idea proposes to add a keyword
> > (static, maybe?) that can create static variables that can persist
> > throughout the program yet only accessible through the fun
On Thu, May 27, 2021 at 10:25 AM Steven D'Aprano
wrote:
> On Wed, May 26, 2021 at 12:43:48PM -0400, Ricky Teachey wrote:
>
> [...]
> > These two ideas of a decorator syntax result are not the same:
> >
> > RESULT A: function decorator
> > # func = de
On Thu, May 27, 2021 at 11:09 AM Matt del Valle
wrote:
>
>> I'm not the OP, but the way I understand the proposal __decoration_call__
> is only invoked when you actually *use an object to decorate something*.
> That means that a decorator factory will just invoke __call__ as normal,
> because it'
On Thu, May 27, 2021 at 1:40 PM Matt del Valle wrote:
> ...
Oh, and I think I've just discovered another thing that I'm not 100% sure I
> like. Even putting aside that I'm not a fan of decorators on the same line
> as the statement they are decorating (as I mentioned in an earlier
> response),
On Thu, May 27, 2021 at 2:00 PM micro codery wrote:
> ...
>
By providing the name as the first argument, all
> of my examples of callables currently in the standard library will work as
> you
> say out of the box. If it were to be passed in last, this new syntax would
> not be
> usable by any sta
nd a lot of time thinking through these examples and
suggesting behavior. Anyone is welcome to do that though, this isn't MINE
in the sense I am jealously guarding ownership of the details. :)
On Thu, May 27, 2021 at 3:03 PM Brendan Barnwell
wrote:
> On 2021-05-26 09:43, Ricky Teachey wrote:
Something I don't understand is whether there is anything about this
proposed feature that can't be accomplished with a simple function.
IIUC, the proposal turns this:
foo = "spam & eggs"
`Here, have some {foo}.`
...into something like this (I am making up a more readable repr):
TemplateLiteral
On Thu, Jun 10, 2021 at 10:12 AM Stestagg wrote:
>
> On Thu, Jun 10, 2021 at 2:58 PM Ricky Teachey wrote:
>
>> Something I don't understand is whether there is anything about this
>> proposed feature that can't be accomplished with a simple function...
>>
I think this idea is promising but instead of doing it by adding new syntax
and a totally different object, why not attach a __templates__ dunder
member to every string but only OPTIONALLY populate it when a string is
formatted?
For every regular string it would just be None:
>>> "".__template__
On Fri, Jun 11, 2021 at 10:12 AM Thomas Güttler
wrote:
>
>
> Am Fr., 11. Juni 2021 um 14:51 Uhr schrieb Ricky Teachey <
> [email protected]>:
>
>> I think this idea is promising but instead of doing it by adding new
>> syntax and a totally different objec
On Sat, Jun 19, 2021, 5:00 AM Steven D'Aprano wrote:
Why are we arguing about `[x,y for y in a]` when nobody has requested
that syntax?
--
Steve
I've wanted many times to be able to write the star unpack there, even as a
relatively modestly experienced python user. But it has never occurred t
Would this feature allow me to declare str objects as not iterable in some
contexts?
If so, +1.
On Thu, Jun 24, 2021, 3:22 PM Chris Angelico wrote:
> On Fri, Jun 25, 2021 at 3:31 AM Steven D'Aprano
> wrote:
> >
> > Here's a quick and dirty proof of concept I knocked up in about 20
> > minutes,
On Thu, Aug 12, 2021 at 9:02 AM Calvin Spealman wrote:
> An alternative suggestion, which works today (... is a valid object called
> Ellipsis):
>
>Foobar.search(
> attr1="foo",
> attr2=[10, ...],
> attr3=[42, ..., 50]
> )
>
This got me thinking just now: allowing
On Thu, Aug 12, 2021 at 5:16 PM Steven D'Aprano wrote:
> On Thu, Aug 12, 2021 at 09:57:06AM -0400, Ricky Teachey wrote:
>
> > This got me thinking just now: allowing ellipses instead of None for the
> > first two arguments of the slice() constructor might be a n
On Sun, Aug 22, 2021, 1:07 PM MRAB wrote:
> On 2021-08-22 17:36, Thomas Grainger wrote:
> > bool((len(collection) == 0) is True) == True and issubclass(True, bool)
> >
> 'True' is a reserved word, so you don't need to check it.
>
> However, 'bool' might have been overridden, so:
>
> __builtins__.
On Mon, Aug 23, 2021 at 12:13 AM David Mertz, Ph.D.
wrote:
> Everyone in this thread should absolutely read Lewis Caroll's delightful
> and "What the Tortoise Said to Achilles." It's a very short 3-page story
> that addressed exactly this topic in 1895... even before Guido's Time
> Machine.
>
>
Can someone explain why enum-vs-string is being discussed as if it is an
either-or choice? Why not just call the enum class using the input so that
you can supply a string or enum?
NanChoice(nan_choice_input)
I understand this would not be a really great choice for a flags enum or
int enum, but f
On Tue, Aug 31, 2021 at 9:17 AM Ricky Teachey wrote:
> Can someone explain why enum-vs-string is being discussed as if it is an
> either-or choice? Why not just call the enum class using the input so that
> you can supply a string or enum?I understand this would not be a really
>
On Wed, Sep 1, 2021 at 1:32 PM Nick Parlante wrote:
> In fairness to Nick, he is not talking about the real world. Nick is
>> talking about the hot-house environment of *education*, where fragile
>> newbies are generally protected from real world issues.
>
>
> Let me unpack this just a teeny bit.
On Thu, Sep 9, 2021 at 12:38 PM Christopher Barker
wrote:
> Take a look at the archives of this list -- there was a large
> conversation about DBC a while back (a year, two years ??? )
>
> I think if you really want to support DBC, there will need to be more
> changes than this -- though there ar
May I ask what you are actually doing with upper and lower after creating
them? Are you checking to see if another value is between? Something else?
If they are always being used together and you're doing the same things
with them all the time, it starts to smell like you might want to just
write a
On Tue, Sep 14, 2021 at 11:02 PM Valentin Berlier
wrote:
> I find that when I run into a similar scenario the reason why I need the
> iterable to be non-empty is because I'm trying to find something in it, and
> for this the `else` clause works pretty well:
>
> for item in get_items():
> if c
On Sun, Sep 19, 2021, 6:42 PM Andre Delfino wrote:
> Your code has an unpacking error in the first line. I think you mean this,
> right?
>
> no_items = object()
> item = no_items
>
> for item in get_items():
> frob(item)
>
> if item is no_items:
> raise ValueError()
>
Sorry yes. Actually
My first thought was: it would be very nice, when doing quick and dirty
scratch code, to not have to resort to a full fledged test framework to get
readable assertions. You could just throw an assert statement in a if
__name__ == '__main__' block at the bottom, click the run arrow next to it
in pyc
Will we be able to splat/unpack the `?`?
>>> args = get_starting_list_values()
>>> args
(1, 2, 3)
>>> dd = defaultdict([*?])
>>> dd["spam"]
[1, 2, 3]
or:
>>> kwargs = get_kwargs()
>>> kwargs
{'x': 1, 'y' 2, 'z': 3}
>>> dd = defaultdict(Node(**?))
>>> dd["eggs"]
Node(x=1, y=2, z=3)
---
Ricky.
"
On Fri, Oct 1, 2021 at 8:02 AM Matt del Valle wrote:
> In the spirit of 3.9 allowing builtin collections like `list`, `dict`,
> `tuple`, and `set` to be subscripted for type-hinting to remove the need
> for importing their equivalents from `typing`, I'd like to propose the same
> thing for a few
On Fri, Oct 1, 2021 at 9:49 AM Matt del Valle wrote:
> I had no idea that type[Something] was already a thing, and this makes me
> so happy! :)
>
> It's true that `any` would have to converted to be either:
>
> 1) an object implementing __call__ and __getitem__
> 2) a type implementing __new__ an
On Fri, Oct 1, 2021 at 2:52 PM Christopher Barker
wrote:
> On Fri, Oct 1, 2021 at 8:05 AM Paul Moore wrote:
>
>> Having to take the runtime cost of an import to do a development-time
>> static analysis of the code, sort of is, though...
>
>
> Perhaps so — though I’d think that could be addressed
Just spitballing but how about any.obj as an alias for typing.Any? It
suffers from the same problem as using naked any- which is that any doesn't
really have anything to do with type hinting... but it doesn't suffer from
the problem of having to convert any to a type. It would just grow a class
att
On Sat, Oct 2, 2021, 10:40 AM Ricky Teachey wrote:
> Just spitballing but how about any.obj as an alias for typing.Any? It
> suffers from the same problem as using naked any- which is that any doesn't
> really have anything to do with type hinting... but it doesn't suffer fr
On Wed, Oct 6, 2021 at 10:55 AM Finn Mason wrote:
> I'm not a huge fan. Sure, dicts are ordered now, but I doubt that many
> people use that feature. I honestly still think of them as unordered ;)
>
I've seen several people say this so I'll be a voice on the other side: I
am not a pro developer
On Tue, Oct 12, 2021 at 9:40 AM MRAB wrote:
> On 2021-10-12 13:49, Steven D'Aprano wrote:
> > On Tue, Oct 12, 2021 at 11:36:42PM +1100, Chris Angelico wrote:
> >
> >> You haven't given any reason why unary plus should imply ord().
> >
> > I think the question Chris is really asking is why should
On Wed, Oct 13, 2021, 11:01 AM Stephen J. Turnbull <
[email protected]> wrote:
Chris Angelico writes:
> +1, although it's debatable whether it should be remove suffix or
> remove all. I'd be happy with either.
If by "remove all" you mean "efefef" - "ef" == "", I think that's a
footgun
I think all of this additional syntax is just a mistake.
The reason is it will encourage people to not properly annotate their input
types for duck typing. Some of these shortcuts might be nice for output
types. But the more general trying.Mapping, typing.Sequence and friends
should be preferred f
On Thu, Oct 14, 2021 at 8:46 AM Paul Moore wrote:
>
> ...maybe the energy focused on "making basic types easier to write"
> should be focused on making protocols easier to write, instead.
>
> Paul
>
+ a billion
Rick.
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about g
On Fri, Oct 15, 2021 at 1:06 PM Finn Mason wrote:
> I love the proposal for dicts, but I agree that this discourages duck
> typing. Could the curly braces notation represent Mapping, not dict
> specifically?
>
> +1 to shortening tuples but not other sequences.
>
>
> --
> Finn Mason
>
That might
On Fri, Oct 15, 2021 at 6:02 PM Jeremiah Paige wrote:
>
>
> On Fri, Oct 15, 2021 at 2:32 PM Guido van Rossum wrote:
>
>> I suspect there won’t be enough support for this proposal to ever make it
>> happen, but at the very least could you think of a different token? The
>> three left arrows just
I kind of like this idea. I wrote this curry helper module as a proof of
concept of how to implement it in Python, today, without having to add
features:
https://gist.github.com/Ricyteach/b290849da903135a1ed5cce9b161b8c9
Using that, you can write code like this:
from typing import Any
@curry_he
Yeah if you change the API to be a bit more powerful, you could build all
kinds of ideas on top of the basic kernel of idea...
Here's some others I was shooting around with a python-eque buddy of mine
this morning:
@curry_helper
def is_(x):
... # elsewhere
@is_.add_predicate
def a_number(x)
On Mon, Oct 18, 2021 at 2:13 PM Matt del Valle wrote:
>
> Ricky's curry helper decorator is cool, but for me the drawback that makes
> it a dealbreaker is that it is too dynamic for IDE's to understand. I write
> a lot of library code and find myself routinely foregoing metaprogramming
> and run
I'm here all week. Tip your wait staff.
Also, genuine apologies if mine was perceived as mean-sarcastic. It was
definitely sarcastic but I hoped it was fun enough in tone not to seem
mean-spirited. I apologize sincerely and without reservation and I would do
it better next time. :)
On Tue, Oct 19
This might be a dumb question but is the context built only left to right?
Or will this be legal?
def f(a, *, b=:c, c=:b):
print(f"{a=} {b=} {c=}")
>>> f(1, b=2)
a=1 b=2 c=2
>>> f(1, c=2)
a=1 b=2 c=2
___
Python-ideas mailing list -- python-ideas@py
It seems to me that the syntax for late binding could be chosen so as to
leave the possibility of expansion open in the future, and defer (har har)
the entire generalized thunk discussion?
So why not go with syntax like this, where before the ? just represents a
keyword to be bike shedded ("defer"
On Mon, Oct 25, 2021 at 3:42 PM Mike Miller
wrote:
>
> On 2021-10-25 11:27, Ethan Furman wrote:
> > - `deferred` soft keyword
>
>
> "defer" please.
>
> This construct did not happen in the past, and it's shorter of course.
>
> -Mike
>
For soft keyword options, defer is better than deferred.
But
On Tue, Oct 26, 2021 at 2:05 PM Paul Moore wrote:
> On Tue, 26 Oct 2021 at 16:48, Eric V. Smith wrote:
> >
> > And also the "No Loss of Abilities If Removed" section sort of applies
> > to late-bound function arguments: there's nothing proposed that can't
> > currently be done in existing Python
On Tue, Oct 26, 2021 at 2:40 PM Chris Angelico wrote:
> On Wed, Oct 27, 2021 at 5:30 AM Ricky Teachey wrote:
> > But with function k below, where the b parameter is deferred, you can't
> get the default b parameter by dynamically unpacking some values; you would
> have to
On Tue, Oct 26, 2021, 9:54 PM Rob Cliffe via Python-ideas <
[email protected]> wrote:
>
>
> On 27/10/2021 01:47, Chris Angelico wrote:
> > The idea that a
> > parameter is optional, but doesn't have a value, may itself be worth
> > exploring (maybe some way to say "arg=pass" and then have an
On Tue, Oct 26, 2021 at 10:44 PM Chris Angelico wrote:
> On Wed, Oct 27, 2021 at 1:13 PM Ricky Teachey wrote:
> >
> > I'll try to summarize why I still have pause even though after thinking
> about it I still can't really think of a solid example showing that this
&
Are you familiar with the f-string self-documentation operator in python
3.8?
https://docs.python.org/3/whatsnew/3.8.html#f-strings-support-for-self-documenting-expressions-and-debugging
With it you can say:
print(f"{a==b=}")
---
Ricky.
"I've never met a Kentucky man who wasn't either thinkin
On Wed, Nov 3, 2021, 5:41 PM Chris Angelico wrote:
On Thu, Nov 4, 2021 at 6:37 AM Ethan Furman wrote:
>
> On 11/3/21 12:21 PM, Florian Wetschoreck wrote:
>
> > In order to prevent confusion, I want to point out that the primary
scenario that I meant is not that the file imports
> > itself but
On Wed, Nov 3, 2021, 2:40 PM MRAB wrote:
> On 2021-11-03 18:14, Ethan Furman wrote:
> > On 11/3/21 10:35 AM, Steven D'Aprano wrote:
> >
> > > I suppose that we could even add yet another overloaded meaning on
> the
> > > asterix:
> > >
> > > # with no default, * keeps the old meaning
On Thu, Nov 11, 2021 at 9:33 PM Ethan Furman wrote:
> I think what Paul is referring to is that according to PEP 8:
>
> - functions: Function names should be lowercase, with words separated by
> underscores as necessary
>to improve readability.
>
> - types: Class names should normally use the
Could this be a use case for typing.Annotated?
In [6]: from dataclasses import dataclass
In [7]: from typing import Annotated
In [8]: class A:
...: """Docstring for class A."""
...: x: Annotated[int, "Docstring for x"]
...: y: Annotated[bool, "Docstring for y"] = True
In [9
On Thu, Nov 18, 2021 at 10:28 AM Ricky Teachey wrote:
> Could this be a use case for typing.Annotated?
>
> ...
>
> The syntax is a bit arduous; I'd be in favor of thinking through ways to
> make it easier to write. But the basic functionality already exists;
> there&#
On Thu, Nov 18, 2021 at 1:39 PM Thomas Grainger wrote:
> Ricky Teachey wrote:
> > Could this be a use case for typing.Annotated?
> > In [6]: from dataclasses import dataclass
> > In [7]: from typing import Annotated
> > In [8]: class A:
> >
This might be a weird idea but I think it looks nice, is backward
compatible, and flexible.
It could be a convention to have the type hint syntax location (ie, the
syntax location after the colon that usually contains type hints only
today) do double duty. It could be used for documentation as lon
I think it's an interesting idea. I made the same or at least similar
suggestion in the previous thread, but it didn't receive any responses. I
assume this is because people weren't very interested (but I also
understand people are busy).
Here's that message:
https://mail.python.org/archives/list
On Wed, Dec 8, 2021 at 8:41 AM Steven D'Aprano wrote:
> On Wed, Dec 08, 2021 at 11:50:55AM -, [email protected] wrote:
> > A few weeks ago, I proposed on this mailing list to write docstrings for
> > class attributes like this:
> >
> > @dataclass
> > class A:
> > x: int
> > """Do
On Wed, Dec 8, 2021 at 12:46 PM Paul Bryan wrote:
> I propose there is already a viable option in typing.Annotated. Example:
>
> @dataclass
>
> class InventoryItem:
>
> """Class for keeping track of an item in inventory."""
>
> name: Annotated[str, "Short name of the item."]
>
> u
On Wed, Dec 8, 2021 at 1:20 PM Paul Bryan wrote:
> I believe a Annotated[..., str] could become an attribute docstring if by
> consensus we deem it to be so. I can't see any disadvantages, perhaps save
> for the verbosity of `Annotated`. It certainly seems like an advantage to
> use an existing m
1 - 100 of 397 matches
Mail list logo
