On Tue, Dec 20, 2022 at 11:17 PM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:
> Ricky Teachey writes:
>
> > This isn't to say it should definitely be added to the language, that's
> a
> > tough hurdle. But boy would I have used it.
>
> IIUC, Mathe
Chiming in to say this is a really neat idea and I would definitely have
used this in the past, especially when doing programming where it would
have been much more useful to know about errors at coding time and not at
runtime.
This isn't to say it should definitely be added to the language,
On Tue, Apr 12, 2022 at 11:27 AM Christopher Barker
wrote:
> > > I guess you could call the associative law of multiplication "dumb
>> > > luck", but most mathematicians will consider that hate speech.
>> >
>> > My apologies for not understanding your example. The counter
>> > example I
On Fri, Apr 8, 2022, 2:40 AM Stephen J. Turnbull
wrote:
> Brian McCall writes:
> Steven d'Aprano writes:
>
> > > you have shown nothing to justify why unit support must be built
> > > into the language itself.
> >
> > I did what I could, but I'm not going to try and justify any more.
>
On Tue, Apr 5, 2022 at 7:43 AM Steven D'Aprano wrote:
> On Mon, Apr 04, 2022 at 01:53:49PM +1000, Chris Angelico wrote:
>
> > And that's exactly why I think that the *concept* of units could be
> > added to the language, with some syntax and low-level semantics, but
> > the actual units
On Mon, Apr 4, 2022 at 2:24 PM Steven D'Aprano wrote:
> On Sun, Apr 03, 2022 at 10:42:16PM -0400, Ricky Teachey wrote:
>
> > I was cheerleading this effort earlier and I still think it would be a
> > massive contribution to needs of the engineering world to solve this
> >
On Mon, Apr 4, 2022 at 11:55 AM Ken Kundert wrote:
> I think there is one more point worth making here. There is a suggestion
> that
> dimensional analysis can underpin a units system. Actually, the idea that
> all
> units can be broken down into a small set of fundamental units is very
>
On Sun, Apr 3, 2022, 11:03 PM Chris Angelico wrote:
> > I'm unsure simple tags are enough. What should the behavior of this be?
>
> > height = 5ft + 4.5in
>
> My view on this is that it should basically be defined as:
>
> height = ft(5) + in(4.5)
>
> where you register your constructor
On Sun, Apr 3, 2022, 6:27 PM Chris Angelico wrote:
On Mon, 4 Apr 2022 at 07:45, Ethan Furman wrote:
> Mechanically, are `lbs`, `km`, `hr`, etc., something that is imported, or
are they tags attached to the numbers? If
> attached to the numbers, memory size would increase and performance might
HEAR HEAR!
BUT- SI units isn't enough. Engineers in the US and Canada (I have many
colleagues in Canada and when I ask they always say: we pretend to use SI
but we don't) have all kinds of units.
Give us native, customizable units, or give us death! Who's with me??!!
...
I'm kidding to a
parse is a great library! i've used it a lot.
---
Ricky.
"I've never met a Kentucky man who wasn't either thinking about going home
or actually going home." - Happy Chandler
On Wed, Mar 30, 2022 at 1:08 PM Paul Moore wrote:
> On Wed, 30 Mar 2022 at 17:58, Christopher Barker
> wrote:
> >
> >
On Tue, Mar 29, 2022 at 12:49 PM Ethan Furman wrote:
> On 3/29/22 09:14, Christopher Barker wrote:
>
> > [...] I tried to use __slots__ in TupleWithNames, but apparently you
> can't use __slots__ in a
> > tuple subclass ('cause tuple's already using it ??) -- but that could
> be done in a
I think I'd often reach for an optimized version of something like this
over SimpleNamespace or even a Dataclass if it existed.
On Tue, Mar 29, 2022, 2:04 AM Christopher Barker
wrote:
> Finally got around to fleshing out my idea here.
>
> My thought was to make an anonymous names tuple not as a
On Thu, Mar 17, 2022, 5:23 AM Steven D'Aprano wrote:
On Thu, Mar 17, 2022 at 01:21:24AM +0900, Stephen J. Turnbull wrote:
> MRAB writes:
>
> > I'm wondering whether an alterative could be a function for splicing
> > sequences such as lists and tuples which would avoid the need to create
> >
I think I'm -0.5 but I have a question for the people on here smarter than
me (pretty much all):
Is there some opportunity for some kind of compiler magic when the iterable
of a for loop is fully contained in a place easily findable by the
compiler, and not spread over multiple if and for
On Fri, Feb 18, 2022 at 8:46 AM Vishesh Mangla
wrote:
> Ok, then I mean that if this process could be added to the standard.
> Package install means that individually users will have to know this thing
> and they may or may not be able to find this package. I don't know what
> words to google
I realize it's still very new to a lot of people, but doesn't
pyproject.toml solve this problem?
Just include a dependencies entry in there and use a tool like flit or
poetry.
On Fri, Feb 18, 2022, 8:24 AM Vishesh Mangla
wrote:
> Yes, I too think they meant the same.
>
On Wed, Feb 16, 2022, 5:46 AM Paul Moore wrote:
> On Wed, 16 Feb 2022 at 10:23, Chris Angelico wrote:
> >
> > On Wed, 16 Feb 2022 at 21:01, Stephen J. Turnbull
> > wrote:
>
> > > What I think is more interesting than simpler (but more robust for
> > > what they can do) facilities is better
On Fri, Feb 11, 2022 at 5:44 PM Chris Angelico wrote:
> On Sat, 12 Feb 2022 at 09:34, Ricky Teachey wrote:
> >
> > On Fri, Feb 11, 2022 at 4:58 PM MRAB wrote:
> >>
> >> On 2022-02-11 20:05, Ricky Teachey wrote:
> >> > Just had a thought kernel: w
On Fri, Feb 11, 2022 at 4:58 PM MRAB wrote:
> On 2022-02-11 20:05, Ricky Teachey wrote:
> > Just had a thought kernel: what if there were an f-string mini-language
> > directive to grab environment variables and expand user paths? That
> > seems to me like it could be ev
Just had a thought kernel: what if there were an f-string mini-language
directive to grab environment variables and expand user paths? That seems
to me like it could be even more useful beyond just working with paths.
Maybe something like:
f"{my_var:$}"
This would return the same as
On Fri, Jan 21, 2022 at 6:57 AM Chris Angelico wrote:
> On Fri, 21 Jan 2022 at 22:52, Ricky Teachey wrote:
> >
> > On Fri, Jan 21, 2022 at 5:04 AM Steven D'Aprano
> wrote:
> >>
> >> On Fri, Jan 21, 2022 at 11:18:27AM +1100, Cameron Simpson wrote:
> &g
On Fri, Jan 21, 2022 at 5:04 AM Steven D'Aprano wrote:
> On Fri, Jan 21, 2022 at 11:18:27AM +1100, Cameron Simpson wrote:
>
> > Paired with a __freeze__ dunder method, this applies to any type, not
> > just sets. (Where appropriate of course.)
> >
> > So:
> >
> > |{1,2,3}| frozen set
>
On Thu, Jan 20, 2022 at 3:35 AM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:
> Christopher Barker writes:
>
> > If this does all come to pass, then:
> >
> > s = {3,8,2}.frozen()
> > will be slightly faster, in some case, than
> > s = frozenset({3,8,2}
> >
> > but the result
Why does it need to be called at all?
{1, 2, 3}.frozen
Or even:
{1, 2, 3}.f
On Wed, Jan 19, 2022, 6:28 AM Steven D'Aprano wrote:
> On Wed, Jan 19, 2022 at 07:20:12AM +, Ben Rudiak-Gould wrote:
> > My preferred syntax for a frozenset literal would be something like
> >
> > {1, 2,
On Tue, Jan 18, 2022 at 10:02 AM Joao S. O. Bueno
wrote:
> > but I don't think we should underestimate the cost of even this small
> complexity increase in the language.
>
> Actually, I think _maybe_ in this case the "complexity increase" cost is
> _negative_. People might waste
> more time
On Tue, Dec 14, 2021, 9:49 PM Paul Bryan wrote:
> Interesting. Some apparent downsides:
>
> - doesn't apply to class attributes
> - objects with `__slots__` can't dynamically add attributes
>
Also doesn't apply to module level members.
To my mind these are significant downsides. And it also
On Tue, Dec 14, 2021 at 10:23 AM Joao S. O. Bueno
wrote:
> Just a short one, for everyone agreeing type.Annotated does the job,
> but thinks we need new syntax, because it is verbose:
>
> You can already do:
>
> from typing import Annotated as A
>
> And:
>
> attr: A[type, "docstring goes
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 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 e
On Sat, Dec 11, 2021, 10:58 PM Steven D'Aprano wrote:
> On Sat, Dec 11, 2021 at 05:02:39PM -0800, Christopher Barker wrote:
> > On Sat, Dec 11, 2021 at 3:03 PM Steven D'Aprano
> wrote:
>
> > > Didn't we decide there was an existing feature for this, no need for
> > > new syntax?
>
> > Well, no.
On Sat, Dec 11, 2021, 1:19 PM Christopher Barker
wrote:
>
>
> Where/how should class attribute doc strings be stored?
>
> Tacked on to the class __doc__ ?
>
> Another dict?
>
> __attr_doc__
>
> Added to __annotaions__ ?
>
> Something else?
>
> If they are to be available at run time, they
On Sat, Dec 11, 2021, 12:57 AM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:
Simão Afonso writes:
> On 2021-12-10 12:20:44, Ricky Teachey wrote:
> > I meant to ask about a (global) module member, not the module docstring
> > itself.
On Fri, Dec 10, 2021 at 11:46 AM Simão Afonso <
simao.afo...@powertools-tech.com> wrote:
> On 2021-12-10 08:20:25, Ricky Teachey wrote:
> > Very very interesting that Sphinx already treats a bare string under the
> > parameter as documentation! I had no idea. Does
On Fri, Dec 10, 2021, 6:08 AM Simão Afonso
wrote:
> On 2021-12-09 12:47:28, Paul Bryan wrote:
> > On Thu, 2021-12-09 at 19:01 +, Simão Afonso wrote:
> > > I'm using docstrings bellow the attributes (analogous to functions
> > > and
> > > classes), I think it works well.
> > > It helps with
On Thu, Dec 9, 2021 at 3:23 PM Ricky Teachey wrote:
> On Thu, Dec 9, 2021 at 3:08 PM Christopher Barker
> wrote:
>
>> On Thu, Dec 9, 2021 at 11:08 AM Simão Afonso <
>> simao.afo...@powertools-tech.com> wrote:
>>
>>> Shouldn't typing be encouraged
functions and
> classes), I think it works well.
> It helps with distinguishing the class docstring from the arguments.
>
> On 2021-12-08 13:25:55, Ricky Teachey wrote:
> > On Wed, Dec 8, 2021 at 1:20 PM Paul Bryan wrote:
> > > I believe a Annotated[..., str] could become
On Thu, Dec 9, 2021 at 12:12 AM Paul Bryan wrote:
> On Thu, 2021-12-09 at 12:32 +1100, Steven D'Aprano wrote:
>
> On Wed, Dec 08, 2021 at 09:45:35AM -0800, Paul Bryan wrote:
>
> I propose there is already a viable option in typing.Annotated.
> Example:
>
> @dataclass
> class InventoryItem:
>
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
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."]
>
>
On Wed, Dec 8, 2021 at 8:41 AM Steven D'Aprano wrote:
> 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
> >
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:
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
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:
> >
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's n
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
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
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
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
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
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
> "
On Tue, Oct 26, 2021, 9:54 PM Rob Cliffe via Python-ideas <
python-ideas@python.org> 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
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 pass
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
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.
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
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 --
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
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
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
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
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
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
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
On Wed, Oct 13, 2021, 11:01 AM Stephen J. Turnbull <
stephenjturnb...@gmail.com> 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
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 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 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 from
>
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
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
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__
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
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.
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
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.
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
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
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
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
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
>
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
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.
>
>
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:
>
>
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 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:
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
> >
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
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 <
> ri...@teachey.org>:
>
>> I think this idea is promising but instead of doing it by adding new
>> syntax and a totally different objec
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:
>>>
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...
>>
>
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):
f 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:
> > Thes
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
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
>
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
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 = decorat
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
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
ither 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 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)
> >
1 - 100 of 392 matches
Mail list logo
