[Python-ideas] Re: Questions about using PEP 637 syntax in PEP 646
On Sat, 30 Jan 2021 at 00:10, Guido van Rossum wrote: > I think for PEP 646 it doesn't matter. That PEP is mostly concerned with > static checks and the static checker can assign this any meaning it wants as > long as it is syntactically allowed. > > Honestly I think it's fine the way you have implemented it -- since there is > a difference between a[1] and a[1,], a[*t] where len(t) == 1 has to make a > choice, and it's fine if this always passes a tuple. All right, but then I have to fix the PEP and the test that is currently failing. I'll do it tonight. Thanks -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/OT234JYHAQKOSG225TLL2A3XSLF744R4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Questions about using PEP 637 syntax in PEP 646
On Tue, 19 Jan 2021 at 13:51, wrote: > > Hello, > > This is a great PEP. It turns out to be applicable in a variety of scenarios. > > Case in point: Matthew Rahtz and I are working on PEP 646: Variadic Generics > (https://www.python.org/dev/peps/pep-0646/; discussion on typing-sig). It is > a type system feature that allows specifying an arbitrary tuple of type > variables instead of a single type variable. > > We plan to use your proposed syntax to represent unpacking a tuple type. This > would be analogous to `*` for unpacking a tuple value: > > + `Tensor[int, *Ts, str]` and `Tensor[*Ts1, *Ts2]` > + such variadic classes would be declared as `class Tensor(Generic[T, *Ts, > T2]):` > > Questions: > > 1. Does PEP 637 support unpacking multiple `*` arguments? >- e.g., Tensor[int, *Ts, str, *Ts2] Yes, technically yes, and it does in our experimental branch. _but_ Brandt and I are unsure about the semantics of it, specifically the corner case of star unpacking a tuple with one element. The current PEP says that the following two are equivalent: a[1] and a[*(1,)]. (calls __getitem__ with index = 1) However, the way it's implemented now, these two are equivalent a[1,] and a[*(1,)] (calls __getitem__ with index = (1,)) I think we would both love a discussion over it. > 2. Does PEP 637 allow a positional argument after a `*`? >- e.g., Generic[T, *Ts, T2] Yes. > PEP 637 says "Sequence unpacking is allowed inside subscripts", so it looks > like these should be allowed (just as in function calls). But I wanted to > confirm it explicitly since this is our core use case and there was no > example with multiple sequences being unpacked. They are. > 3. We also wanted to ask - how's your implementation going? It's ready, but not reviewed, and not matching the PEP for the point above. https://github.com/stefanoborini/cpython/tree/PEP-637-implementation-attempt-2 I'll update against master tonight. >We'll be starting implementation in typing.py soon. Since there's some > overlap we wanted to make sure we're not duplicating your work, and that > there won't be any merge conflicts later. Do you have a fork we might be able > to get early access to? We're also targeting the 3.10 release for our > implementation. Contact me directly if you have any issues with it. -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GXWMB63R763FSUJVPAJWDWO4D4X2B2XQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)
On Wed, 7 Oct 2020 at 11:39, Steven D'Aprano wrote: > One possible advantage is that with axis='row', I don't have to > worry about, or test for, mutually exclusive keywords: > > matrix[row=2, col=3] > # can't get both a row and a column at the same time Well, they are not mutually exclusive in this case. You would get the element at row 2 col 3. -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4XUCAVPLLWVNPT6ZCTC7OBRVEFIRIWVB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)
On Tue, 29 Sep 2020 at 22:31, wrote: > Furthermore, you currently can't tell the difference between `x[(a, b)]` and > `x[a, b]`; with the new function, libraries could differentiate, and maybe > eventually make them behave reasonably (you can always use x[*c] if you > already have a tuple, just like for a function, and it's one of the rare / > only places where list vs. tuple matters in Python). You still would not be able to. The semantics of that operation are unchanged (for backward compatibility) -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/XDWQSKYIOHUVRKMMDRDIST757LLVFFXD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)
On Wed, 30 Sep 2020 at 06:44, Steven D'Aprano wrote: > matrix[3, 4] # unambiguously a cell reference > matrix[3] # ambiguous, forbidden > matrix[3, axis='row'] # unambiguously a row > matrix[3, axis='col'] # unambiguously a column I guess everybody already knows this, but I would hope the obvious choice here is matrix[row=3] But in any case, the PEP does not prescribe how the keyword arguments should be used, only that are possible. How they are used (or misused.. :) ) is of course up to the implementation. -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/SAO2MSJGHZ5AN3WHWYF24DUT33WGUJGA/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 637 and keyword only subscripts
On Mon, 28 Sep 2020 at 15:45, Eric Wieser wrote: > > Would another option be to just stop using the tuple-less index in the > presence of new syntax - so by example, I don't think it would be a reliable approach. Now you end up with a "randomly" occurring special case depending on how it's invoked. Also, it would give different behavior between d[x] and d[x, **kw], which in my opinion should be a fully degenerate case. -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UJR4GMFJ2KHHBLKWIKP2JIU2PZUVJK6M/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 637 and keyword only subscripts
On Sun, 27 Sep 2020 at 12:28, Stefano Borini wrote: > I am not sure. I am on the fence on many topics. There seem to be no > clear solution on many of them, it boils down to taste and compromise. > In any case, I listen to all proposals (although with a small delay). > I am working on the sentinel issue at the moment > > https://github.com/python/peps/compare/master...stefanoborini:pep-637-on-default-sentinel-value Sentinel is now a PR https://github.com/python/peps/pull/1626 I kept the tuple as the accepted option, but I am personally open to NoIndex as well. I am not sure how the SC would take a non-hashable, new constant to be honest, for such a specific use case. It would help if more people replied to Steven's poll to gather a clearer picture of the general opinion. -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/II2YFQC2OQGMBPMLUX2BUIHOGMS73V2S/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)
On Sun, 27 Sep 2020 at 06:27, Steven D'Aprano wrote: > As far as speed and complexity goes, I do not understand the C > implementation well enough to categorically dismiss your claims, but > from everything I have seen, neither is true: this should not have any > significant slowdown, and the increase in complexity should be quite > small. If my understanding of the C part is correct, this will have practically zero impact on speed. The compiler will (should) be able to create BINARY_SUBSCR opcodes when it sees an invocation without keyword arguments. It will use a new opcode BINARY_SUBSCR_KW when there's a keyword argument. The only loss in performance is that the C handler for the old variant will likely end up calling the new handler with a kwarg set to NULL, so the total cost is one routine call. But I am not an expert in the C interpreter internals, so I might be wrong. -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PSLXFMOLVHIZIO6U2ENYR3XQS746FEBG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 637 and keyword only subscripts
On Sun, 27 Sep 2020 at 05:06, Ricky Teachey wrote:
>>> obj[**d] = "foo" # no kwd arguments provided here
I committed yesterday the following proposal
https://github.com/python/peps/pull/1622
But to be honest I am not sure if we should disallow these two constructs
d[*()]
d[**{}]
as equivalent to the disallowed d[] or allow them as equivalent to
d[()] (or whatever the sentinel will be)
>> PS. Maybe we can just stop debating this PEP? I have a feeling that we're
>> going around in circles. I think Stefano has some changes that he would like
>> to see vetted, but the best way to signal an empty index is not one of them.
I am not sure. I am on the fence on many topics. There seem to be no
clear solution on many of them, it boils down to taste and compromise.
In any case, I listen to all proposals (although with a small delay).
I am working on the sentinel issue at the moment
https://github.com/python/peps/compare/master...stefanoborini:pep-637-on-default-sentinel-value
--
Kind regards,
Stefano Borini
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/BJK6QY6GM2LQK5BSVCZVUNYBSODNV6G4/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)
On Sat, 26 Sep 2020 at 04:02, Steven D'Aprano wrote: > Did you just completely undermine the rationale for your own PEP? > > Isn't the entire purpose of this PEP to allow subscripts to include > keyword arguments? And now you are describing it as "poor design"? Not really. to _me_, an indexing operation remains an indexing operation. My personal use cases are two: 1. naming axes (e.g. replace, if desired obj[1, 2] with obj[row=1, col=2]) 2. typing generics MyType[T=int] Other use cases are certainly allowed, but to me, something like a[1, 2, unit="meters"] makes me feel uncomfortable, although I might learn to accept it. In particular, the above case becomes kind of odd when you use it for setitem and delitem a[1, 2, unit="meters"] = 3 what does this mean? convert 3 to meters and store the value in a? Then why isn't the unit close to 3, as in a[1,2] = 3 * meters and what about this one? del a[1, 2, unit="meters"] # and this one? I feel that, for some of those use cases (like the source one), there's a well established, traditional design pattern that fits it "better" (as it, it feels "right", "more familiar") > I'm not really sure why this hypothetical call: > > snapshot1 = remote_array[300:310, 50:60, 30:35, source=worker1] > > is "abuse" or should make us more uneasy that this hypothetical call: I don't know... it just doesn't feel... "right" :) but maybe there's a logic to it. You are indexing on the indexes, and also on the source. Yeah, makes sense. Sold. -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IUGWBNNFF275HVRNDRJ2RWR53ZJYMPBN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 9999 (provisional): support for indexing with keyword arguments
On Sat, 26 Sep 2020 at 05:10, Steven D'Aprano wrote: > > I recommend that the PEP be changed to allow `*args` inside subscripts. Will do. -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BMD6SINF7JRMVA7CIXD6CDMRHIWCW2V7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)
Ricky, I'd love new dunders too but it would explode in complexity. The likelihood of being approved is pretty much non-existent as far as I understand. If you want, we can write together a competing PEP with that solution, so that the Steering Council can have two ideas. I would not mind exploring that option a bit more, but it's likely to become an exercise. On Fri, 25 Sep 2020 at 22:06, Ricky Teachey wrote: > > On Fri, Sep 25, 2020 at 4:57 PM Stefano Borini > wrote: >> >> On Fri, 25 Sep 2020 at 14:07, Ricky Teachey wrote: >> > >> > I'd like to hear more about why the empty tuple has been selected as the >> > default index. >> >> It's still not settled. Steven proposed None, I propose empty tuple >> for affinity with *args behavior, others proposed no positional arg at >> all, but then there's the problem of the setter. >> I sent a mail to the numpy mailing list yesterday, and all people who >> replied seemed to prefer empty tuple. >> >> Here is the thread >> >> http://numpy-discussion.10968.n7.nabble.com/Request-for-comments-on-PEP-637-Support-for-indexing-with-keyword-arguments-td48489.html >> >> >> >> -- >> Kind regards, >> >> Stefano Borini > > > * sheepishly, whispering mostly to myself * > > All of that could be solved with new dunders. > > --- > Ricky. > > "I've never met a Kentucky man who wasn't either thinking about going home or > actually going home." - Happy Chandler > > -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TVDJHXCDPL4POOFMF4WKKDAPIRHJ4LUO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)
On Fri, 25 Sep 2020 at 14:07, Ricky Teachey wrote: > > I'd like to hear more about why the empty tuple has been selected as the > default index. It's still not settled. Steven proposed None, I propose empty tuple for affinity with *args behavior, others proposed no positional arg at all, but then there's the problem of the setter. I sent a mail to the numpy mailing list yesterday, and all people who replied seemed to prefer empty tuple. Here is the thread http://numpy-discussion.10968.n7.nabble.com/Request-for-comments-on-PEP-637-Support-for-indexing-with-keyword-arguments-td48489.html -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5CGHSL5G3ILP5FLX4PY4VDGSRAXKOL3S/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)
On Fri, 25 Sep 2020 at 05:55, David Mertz wrote: > Smuggling in a generic function calls in square brackets is undesirable (but > obviously not preventable at a language level). However, I feel like > keywords might very often "alter the behavior." > > For example, imagine we have a distributed array within an engine that is > intended to be "eventually consistent." I would find code like this, in some > hypothetical library, to be clear and useful, and not to violate the spirit > of indexing. > >> snapshot1 = remote_array[300:310, 50:60, 30:35, source=worker1] >> snapshot2 = remote_array[300:310, 50:60, 30:35, source=worker2] I would personally be very uneasy with this. A better solution would be to have a proxy object that handles that: >> snapshot1 = remote_array.source(worker1)[300:310, 50:60, 30:35] Of course people can (and will) abuse the feature, but I would personally consider it poor design. These tricks were discussed in PEP-472 (e.g. specify the unit to be returned), but I always felt uncomfortable with them. -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZJHMFBANR3FZLYMEAM4XX5LYLGTTMZ3Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)
On Thu, 24 Sep 2020 at 22:22, Guido van Rossum wrote:
> - I recommend that you carefully look over the PEP as rendered on python.org
> (link above) and try to fix any markup oddities. E.g. some comments are
> line-wrapped, which looks ugly, and some bulleted lists have an extra blank
> line above.
>
> - Looking at the generated ToC, you have two top-level sections labeled
> "Syntax and Semantics". That seems a bit odd. I'm not sure what you meant to
> happen here, but I recommend renaming at least one of these. (Another
> recommendation: don't mix description of the status quo with the
> specification.)
No matter how many times one re-reads something, there's always going
to be a typo :)
Just as a question, the generated html using make pep-0637.html are
not supposed to get the css style. I get no stylisation, but I do see
a .css file. Code seems to support that css is only there to be pushed
to remote deployment, but maybe there's a trick I haven't spotted.
> - While I can understand the desire to keep C function names short, I don't
> see we should continue the tradition of using the meaningless 'Ex' suffix for
> API variations that take an additional dict of keywords. Looking through the
> existing APIs, I recommend PyObject_{Get,Set,Del}ItemWithKeywords instead.
> (Note you have a typo here, "DetItem". Also I recommend adding markup (e.g.
> bullets) so each signature is on a line by itself.
Will do. Thanks.
In fact I'll focus tonight on fixing the visual aspect and typos. I
also have feedback from the numpy mailing list about the argument to
pass in case no positional index is specified), but I'll add that
later, as well as the rest of this ml feedback.
I also tried to start implementing the feature as a PoC... but the
parser grammar is beyond my skills I fear. I understand it, but unsure
(at the moment) how to modify it. Nevertheless I am willing to spend
some days and do some experiments. I'll keep you all posted if I can
achieve something that seems to work.
--
Kind regards,
Stefano Borini
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/FZT3EY3TRKVRWBD4F3QBG6NNI32BBO5F/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] PEP 637 - support for indexing with keyword arguments (Was: Re: PEP 9999 (provisional): ...)
Dear all, "Support for indexing with keyword arguments" has now been merged with the assigned PEP number 637. For future reference, this email will be added to the Post-History of the PEP. On Mon, 21 Sep 2020 at 21:34, Stefano Borini wrote: > > PEP for support for indexing with keyword arguments is now submitted as PR. > > https://github.com/python/peps/pull/1612 > > Thanks to everybody involved in the development of the PEP and the > interesting discussion. All your contributions have been received and > often added to the document. > If the PEP is approved, I would like to attempt an implementation, but > I am not particularly skilled in the python internals. If a core > developer is willing to teach me the ropes (especially in the new > parser, I barely understood the syntax of the old one, but have no > idea about the new one) and review my code I can give it a try. I > would not mind refreshing my C a bit. -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/25ZPXADTQNJRMCSG4BJO4QJ7OQAL67N6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] PEP 9999 (provisional): support for indexing with keyword arguments
PEP for support for indexing with keyword arguments is now submitted as PR. https://github.com/python/peps/pull/1612 Thanks to everybody involved in the development of the PEP and the interesting discussion. All your contributions have been received and often added to the document. If the PEP is approved, I would like to attempt an implementation, but I am not particularly skilled in the python internals. If a core developer is willing to teach me the ropes (especially in the new parser, I barely understood the syntax of the old one, but have no idea about the new one) and review my code I can give it a try. I would not mind refreshing my C a bit. -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BGN2O42LY7GCXDA5DRV5NOQL77LDV7CF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)
On Wed, 2 Sep 2020 at 05:20, Christopher Barker wrote: > And, in fact, the current sytax is pretty tricky as well. Say you want to > make a class that takes multiple indices -- like a Mtraix, for instance. > > your __getitem__ looks like: > > def __getitem__(self, index): > > as they all do. But what might index be? > > It could be one of: > * an object with an __index__ method -- so a single index, simple > * a slice object > * a tuple, where each item in the tuple could be both of the above. And this is the reason why personally I would prefer to add a new dunder with more defined semantics. This poor sod of a method has already a lot to handle, exactly because it's behaving nothing like a function. As a programmer developing that method, you are essentially doing the job of the interpreter. > But that's all OK, as the number of people that need to write these methods > is small, and the number of people that can use the feature is large. True but there's a point where one should question if the direction getitem has taken is the right one. -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/6X6WNL4NDKGTMOWLGEQG6CZDVO2ER56F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] PEP-0472 revisited - draft
For those interested in the new draft of ex PEP-0472 (which has joined the choir invisible), I opened a draft PR https://github.com/python/peps/pull/1579 This first draft contains only the revisited motivation and background. I'll add the technical decisions etc in the upcoming nights. -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/PMSOJNLNEHOPD3VPDDAN4NJTDK5FGKAB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)
On Sun, 30 Aug 2020 at 04:09, Steven D'Aprano wrote: > > Nobody disputes that it *could* be made to work that way. But I'm > > not convinced that it's the *best* way for it to work. The killer > > argument in my mind is what you would have to do to make an object > > where all of the following are equivalent: > > > >a[17, 42] > >a[time = 17, money = 42] > >a[money = 42, time = 17] > > I don't think that something like that is exactly the intended use-case > for the feature, at least not intended by *me*, that looks more like it > should be a function API. The above feature is well intended and part of the original PEP, mostly for two reasons: 1. During my career I encountered issues where people confused the axis of a matrix. This is especially problematic when the matrix is symmetric. 2. pandas has this exact problem with column names, and while they have a workaround, in my opinion it is suboptimal > But as I mention above, if we did introduce this, I'd rather we keep the > dunders and change the name rather than introduce confusable names. that is something it's hard to fight against. unless we call it something like _extended_getitem_? getItemEx was proposed by GvR for the C API... it seems to be a frequent convention. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZNX6PB7NI4YIN5SZLVXZDV3QOH46MUVZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access
I am going to put everything in the new PEP tonight.
On Sun, 30 Aug 2020, 08:47 Guido van Rossum, wrote:
> On Sat, Aug 29, 2020 at 10:29 PM Guido van Rossum
> wrote:
>
>> FYI, Jonathan's post (once I "got" it) led me to a new way of reasoning
>> about the various proposals (__keyfn__, __subscript__ and what I will keep
>> calling "Steven's proposal") based on what the compiler and interpreter
>> need to do to support this corner case. My tentative conclusion is that
>> Steven's proposal is superior. But I have been reviewing my reasoning and
>> pseudo-code a few times and I'm still not happy with it, so posting it will
>> have to wait.
>>
>
> I've spent some more thinking about this, focused on two things: absolute
> backwards compatibility for d[1] vs. d[1,], and what should happen at the C
> level. There are both the type slots and API functions like
> PyObject_{Get,Set}Item to consider.
>
> Interestingly, it seems Jonathan's proposal and __subscript__ seem
> inspired by the desire to keep both type slots and PyObject{Get,Set}Item
> unchanged, but have the disadvantage that it's hard to keep d[1] vs. d[1,]
> straight, and add a lot of complexity to the bytecode interpreter.
>
> At this point my recommendation is to go with Steven's proposal,
> constructing a "key" from the positional args, taking d[1] vs. d[1,] into
> account for backwards compatibility, and passing keywords as a dict to new
> C API functions PyObject_GetItemEx and PyObject_SetItemEx. These functions
> then call the mp_subscript and mp_ass_subscript slots. There will have to
> be a flag in the type object to declare whether the slot functions take a
> dict of keywords. This flag is off by default (for backwards compatibility)
> but on for type objects wrapping Python classes -- the dict of keywords
> will then be passed as **kwargs to __getitem__ or __setitem__ (the call
> will fail if the Python __getitem__ or __setitem__ doesn't take the
> specific keywords in the dict).
>
> If the flag in the type slot says "doesn't take dict of keywords" then
> passing a non-empty dict causes a type error. Ditto if there are keywords
> but the type slots are in tp_as_sequence rather than in tp_as_mapping. (The
> sequence slots only take a single int and seem to be mostly a legacy for
> sequences -- even slices go through tp_as_mapping.)
>
> There is one final case -- PyObject_GetItem on a type object may call
> __class_getitem__. This is used for PEP 585 (list[int] etc.). In this case
> we should pass keywords along. This should be relatively straightforward
> (it's not a slot).
>
> A quick summary of the proposal at the pure Python level:
>
> ```
> d[1] -> d.__getitem__(1)
> d[1,] -> d.__getitem__((1,))
> d[1, 2] -> d.__getitem__((1, 2))
> d[a=3] -> d.__getitem__((), a=3)
> d[1, a=3] -> d.__getitem__((1,), a=3)
> d[1, 2, a=3] -> d.__getitem__((1, 2), a=3)
>
> d[1] = val -> d.__setitem__(1, val)
> d[1,] = val -> d.__setitem__((1,), val)
> d[1, 2] = val -> d.__setitem__((1, 2), val)
> d[a=3] = val -> d.__setitem__((), val, a=3)
> d[1, a=3] = val -> d.__setitem__((1,), val, a=3)
> d[1, 2, a=3] = val -> d.__setitem__((1, 2), val, a=3)
> ```
>
> Do we want to support d[**kwargs]? It can be done, alternatively we could
> just ask the user to write the __getitem__/__setitem__ call explicitly.
>
> I think we should say no to d[*args], because that will just become
> d[(*args)], with awkward questions around what if args == (1,). Maybe then
> for consistency we needn't bother with **kwargs, though the case for that
> is definitely stronger.
>
> Sorry for telegraphing this -- I am way past my bedtime but looking at
> this from the C API POV definitely made some things clear to me. I'm
> probably posting this in the wrong thread -- I can't keep up (and GMail
> splits threads after 100 messages, which doesn't help).
>
> --
> --Guido van Rossum (python.org/~guido)
> *Pronouns: he/him **(why is my pronoun here?)*
>
[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access
Ok then it is my understanding that Steven D'Aprano is willing to sponsor it. Steven please correct me if I am dead wrong, and apologies if that's not the case. On Thu, 27 Aug 2020 at 08:39, Chris Angelico wrote: > > On Thu, Aug 27, 2020 at 5:26 PM Stefano Borini > wrote: > > So the question is: is a core developer willing to sponsor the _idea_ > > (not the PEP, as it doesn't exist yet)? > > It comes to the same thing (it's really just a matter of terminology). > Before the PEP can be created, it needs a sponsor, which means someone > needs to be willing to support the idea before you write the PEP. It's > called "sponsoring the PEP" but the PEP won't exist without > sponsorship. > > ChrisA > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/QQBAVZ47ALZ77OTH5G2GB3VZVJLINT74/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/A5GKIES3UJP4DCHWQMIMTPWCF6ETWGAO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access
On Thu, 27 Aug 2020 at 03:00, Steven D'Aprano wrote: > > To me, most of the discussion is being derailed in deciding how this > > should look like on the __getitem__ end and how to implement it, but > > we haven't even decided what it should look like from the outside > > Is that even a question? > > obj[index, keyword=value] > > where index is any comma-separated list of expressions, including > slices, keyword is an identifier, and value is any expression including > slices. Are there even any other options being considered? Well, there are a lot of corner cases, such as what to do with obj[]. We already discussed it and we both agreed that it was a bad idea to allow it. Plus there's no consensus, as far as I can tell, if the index and the keyword should interact or not. I say they should, but others say they should not. With interact I mean that anonymous axes exist and live an independent life from named axes, and this behavior is different from function call, where you always give names to arguments on the function declaration side (unless you have *args, of course). > - You can have multiple keyword=value pairs, separated by commas. They > must all follow the index part. Duplicate keywords is a runtime error, > just as they are are for function calls. > > - An empty subscript remains a syntax error, even if the method > signature would allow it. > All right. So we agree on that. I wanted to be sure that we were not excluding at all the possibility to do _either_ no keyword _or_ only keywords. We do want to allow mixing. So now the question is what to do with the mixing. > > (although it's probably in the massive number of emails I am trying to > > aggregate in the new PEP). > > As PEP author, you don't have to include every little tiny detail of > every rejected idea. It should be a summary, and it is okay to skip over > brief ideas that went nowhere and just point back to the thread. > > One of the weaknesses, in my opinion, of the existing PEP is that it > tries to exhaustively cover every possible permutation of options (and > in doing so, managed to skip the most useful and practical option!). Completely agree with your observation. The main problem when I wrote it is that there was no consensus. I had my preference, the other author had a different one, and the mailing list also didn't settle on a plausible, dead sure implementation. We were as confused back then as we are today. > So my advise is: choose the model you want, and write the PEP to > persuade that is the best model, why the others fail to meet the > requirements. I really hope the model you choose is the one I describe > above, in which case I will support it, but if you hate that model and > want something else that's your right as the PEP author. Will do. > (Although the earlier co-authors may no longer wish to be associated > with the PEP if you change it radically.) I lost contact with the other author. I haven't heard of him since, even on the mailing list. -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DNHM3A36JMXQS6EHBYRVMTADZN62OD6J/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access
We surely can't deprecate them, but the naming of axes is done at the dunder level, not at the client level. and if the idea were to add a new dunder, then of course you can always name them post-facto, and pass through to your older __getitem__ function. if you so wish. I need to take a look at xarray tonight. I am not familiar with its interface. On Thu, 27 Aug 2020 at 02:27, Todd wrote: > > On Wed, Aug 26, 2020 at 7:11 PM Stefano Borini > wrote: >> >> On Wed, 26 Aug 2020 at 23:56, Todd wrote: >> > Again, implicit on your argument here is the assumption that all keyword >> > indices necessarily map into positional indices. This may be the case >> > with the use-case you had in mind. But for other use-cases brought up so >> > far that assumption is false. Your approach would make those use cases >> > extremely difficult if not impossible. >> >> Please remind me of one. I'm literally swamped. > > > xarray, which is the primary python package for numpy arrays with labelled > dimensions. It supports adding and indexing by additional dimensions that > don't correspond directly to the dimensions of the underlying numpy array, > and those have no position to match up to. They are called "non-dimension > coordinates". > > Other people have wanted to allow parameters to be added when indexing, > arguments in the index that change how the indexing behaves. These don't > correspond to any dimension, either. > >> In any case, this leads to a different question: should we deprecate >> anonymous axes, and if not, what is the intrinsic meaning and >> difference between anonymous axes and named axes? > > > Anonymous axes are axes that someone hasn't spent the time adding names to. > Although they are unsafe, there is an absolutely immense amount of code built > around them. And it takes a lot of additional work for simple cases. So I > think deprecated them at this point would be completely unworkable. > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/NJM5HO5ROVPO3ES73PV633UNUCJD22ZI/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NTRKX44IBMIZ3QGZSYEATZGMW4B72XOZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access
I already sent a mail to D'Aprano and he said (please Steven correct me if I am wrong) that basically PEP-472 as is is not acceptable (and I agree) without modifications. But in my opinion the argument is circular. Who is willing to sponsor a PEP that doesn't exist yet? it's like putting a signature on a blank piece of paper. So the question is: is a core developer willing to sponsor the _idea_ (not the PEP, as it doesn't exist yet)? On Thu, 27 Aug 2020 at 00:33, Chris Angelico wrote: > > On Thu, Aug 27, 2020 at 8:20 AM Stefano Borini > wrote: > > > > Personally I think Jonathan and I (and possibly a couple others) > > should form a separate subgroup and come up with a sensible and > > logical set of options in a proto-PEP. The topic has been discussed > > and we have plenty of ideas and opinions, and if we want to achieve > > something coherent we need to take it aside and dig deeper the various > > options until the whole proposal (or set of proposals) has been > > considered fully. There's little sense in going back and forth in the > > mailing list. > > > > One thing I want to understand though, and it's clear that this is a > > potential dealbreaker: is there any chance that the steering council > > will actually accept such a feature once it's been fully fleshed out, > > considering that it's undeniable that there are use cases spanning > > through multiple fields? > > Because if not (whatever the reason might be) regardless of the > > possible options to implement it, it's clear that there's no point in > > exploring it further. > > > > Another way to word that question is: Do you have a sponsor for your > PEP? Every PEP needs a core dev (or closely connected person) to > sponsor it, otherwise it won't go forward. Do you have any core devs > who are on side enough to put their name down as sponsor? If not, it's > not even going to get as far as the Steering Council. > > ChrisA > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/3LQCUFFBGLA5DJGTPLTSO4UAN7SQ2HHN/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/TX2KNOKNRAVNXGKW4F4YA3XUNTKG5G3F/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access
On Wed, 26 Aug 2020 at 23:56, Todd wrote: > Again, implicit on your argument here is the assumption that all keyword > indices necessarily map into positional indices. This may be the case with > the use-case you had in mind. But for other use-cases brought up so far that > assumption is false. Your approach would make those use cases extremely > difficult if not impossible. Please remind me of one. I'm literally swamped. In any case, this leads to a different question: should we deprecate anonymous axes, and if not, what is the intrinsic meaning and difference between anonymous axes and named axes? -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UK7XFPZUDJTZGW4W5FM5ERDPKCJUK4WD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access
Personally I think Jonathan and I (and possibly a couple others) should form a separate subgroup and come up with a sensible and logical set of options in a proto-PEP. The topic has been discussed and we have plenty of ideas and opinions, and if we want to achieve something coherent we need to take it aside and dig deeper the various options until the whole proposal (or set of proposals) has been considered fully. There's little sense in going back and forth in the mailing list. One thing I want to understand though, and it's clear that this is a potential dealbreaker: is there any chance that the steering council will actually accept such a feature once it's been fully fleshed out, considering that it's undeniable that there are use cases spanning through multiple fields? Because if not (whatever the reason might be) regardless of the possible options to implement it, it's clear that there's no point in exploring it further. On Wed, 26 Aug 2020 at 12:58, Chris Angelico wrote: > > On Wed, Aug 26, 2020 at 9:44 PM Jonathan Fine wrote: > > > > PROPOSAL > > I think it will help solve our problem, to give Z = type(z) a new dunder > > attribute that either is used as the internal_get_function, or is used > > inside a revised system-wide internal_get_function. > > > > That way, depending on the new dunder attribute on Z = type(z), sometimes > > >>> z[1, 2, a=3, b=4] > > >>> z.__getitem__(1, 2, a=3, b=4) > > are equivalent. And sometimes > > >>> z[1, 2, a=3, b=4] > > is equivalent to > > >>> key = K(1, 2, a=3, b=4) > > >>> z.__getitem__(key) > > all depending on the new dunder attribute on Z = type(z). > > > > -1. We have already had way WAY too much debate about the alternative > ways to handle kwargs in subscripts, and quite frankly, I don't think > this is adding anything new to the discussion. Can we just stop > bikeshedding this already and let this matter settle down? You still > aren't showing any advantage over just allowing the current dunder to > receive kwargs. > > ChrisA > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/UCYMGB4BKZK7HHUNEBA6OIMCGIZFRXMA/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4637KB2T45S7BTWZU4RNXXBZTWPV24ZD/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 472 - new dunder attribute, to influence item access
On Wed, 26 Aug 2020 at 17:50, David Mertz wrote: > > In my mind, *anything* other than the straightforward and obvious signature > `__getitem__(self, index, **kws)` is a pointless distraction. It isn't. and the reason why it isn't is that it makes it much harder for the implementing code to decide how to proceed, for the following reasons: 1. you will have to check if the keywords you receive are actually in the acceptable set 2. you will have to disambiguate an argument that is supposed to be passed _either_ as position or with keyword. Always remember this use case: a matrix of acquired data, where the row is the time and the column is the detector. I've seen countless times situations where people were creating the matrix with the wrong orientation, putting the detector along the rows and the time along the column. so you want this acquired_data[time, detector] to be allowed to be written as acquired_data[time=time, detector=detector] so that it's unambiguous and you can even mess up the order, but the right thing will be done, without having to remember which one is along the row and which one is along the column. If you use the interface you propose, now the __getitem__ code has to resolve the ambiguity of intermediate cases, and do the appropriate mapping from keyword to positional. Which is annoying and you are basically doing manually what you would get for free in any standard function call. Can you do it with that implementation you propose? sure, why not, it's code after all. Is it easy and/or practical? not so sure. Is there a better way? I don't know. That's what we are here for. To me, most of the discussion is being derailed in deciding how this should look like on the __getitem__ end and how to implement it, but we haven't even decided what it should look like from the outside (although it's probably in the massive number of emails I am trying to aggregate in the new PEP). -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QQBD4LNE46C7NIKSH5VWT7MBTJYTMHNB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)
On Tue, 25 Aug 2020 at 22:42, Ricky Teachey wrote:
> Actually I think this *may not* be true. Consider, if we were starting at
> zero ,and we agreed we wanted dict literal behavior to work like the
> following:
>
> >>> idx1 = 1,2,3
> >>> idx2 = 1,2
> >>> idx3 = 1
> >>> d = {idx1: "foo", idx2: "bar", idx2: "baz"}
>
> This is what we have today, and I think most agree this is all a Good Thing.
>
> Then, we might reason, if I want to be able to do a lookup using tuple
> literals, I'd do this, just as we do today:
>
> >>> d[1,2,3]
> 'foo'
> >>> d[1,2]
> 'bar'
> >>> d[1]
> 'baz'
>
> No tuple brackets required.
>
> I think it is REALLY NICE not to have to do THIS, which is what we'd have to
> do if things behaved the function-call-way inside square brackets:
>
> >>> d[(1,2,3)]
> 'foo'
> >>> d[(1,2)]
> 'bar'
> >>> d[1]
> 'baz'
>
> Of course all of these DO work today-- it just isn't required to use the
> tuple brackets. They're optional.
>
> Could it be that the convenience of not needing to give the tuple brackets,
> if we were starting at zero, might win out over the function-call syntax even
> today? I don't know. I wonder.
If we were to start from scratch, dict.__getitem__ would probably
accept *args, **kwargs, and use them to create the index.
I would also say that very likely it would not accept kwargs at all.
But you have a point that whatever the implementation might be, it has
to play nice with the current dict() behavior. Yet, if we were to add
an enhanced dunder, nothing for the current dict would change. It
would still use the old getitem, and it would still create a tuple
from its (nameless) index group to be used as a key.
--
Kind regards,
Stefano Borini
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/XR6SFHPVCXE5D4IB77MBDKNT36DHU276/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)
On Sat, 8 Aug 2020 at 02:34, Stephan Hoyer wrote: > I'm sorry, I did a poor job of editing this. > > To fill in my missing word: From my perspective, the *only* reasonable way to > add keyword arguments to indexing would be in a completely backwards > compatible way with **kwargs. Let me clarify that I don't like the kwargs solution to the current getitem, and the reason is simple. The original motivation for PEP-472 was to do axis naming, that is, to be sure you would be able to clearly indicate (if you so wished) data[23, 2] explicitly as e.g. data[day=23, detector=2] or data[detector=2, day=23] If you have **kwargs, now the first case would send the two values to the nameless index, the second case to the kwargs, and inside the getitem you would have to reconcile the two, especially if someone then writes data[24, 5, day=23, detector=2] typing of course has the same issue. What this extended syntax is supposed to be used for is to define specialisation of generics. but it's difficult to now handle the cases List[Int] vs List[T=Int] vs List[Int, T=int], which are really telling the same thing the first two, and something wrong (TypeError multiple arguments) the second. -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/FW453Q3PMRP6ECNATRPCSLQNNCROFOG6/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)
this?
>
>
> > 4.m.__get__(KeyObject( (1, 2), {'a': 3, 'b': 4} )) # change
> > positional argument handling from current behavior only in the case that
> > kwd args are provided
>
> Use-case: you want to wrap an arbitrary number of positional arguments,
> plus an arbitrary set of keyword arguments, into a single hashable "key
> object", for some unstated reason, and be able to store that key object
> into a dict.
>
> Advantage (double-edged, possible):
>
> (1) Requires no change to the method signature to support keyword
> parameters (whether you want them or not, you will get them).
>
> Disadvantages:
>
> (1) If you don't want keyword parameters in your subscript methods, you
> can't just *do nothing* and have them be a TypeError, you have to
> explicitly check for a KeyObject argument and raise:
>
> def __getitem__(self, index):
> if isinstance(item, KeyObject):
> raise TypeError('MyClass index takes no keyword arguments')
>
> (2) Seems to be a completely artificial and useless use-case to me. If
> there is a concrete use-case for this, either I have missed it, (in
> which case my apologies) or Jonathan seems to be unwilling or unable to
> give it. But if you really wanted it, you could get it with this
> signature and a single line in the body:
>
> def __getitem__(self, *args, **kw):
> key = KeyObject(*args, **kw)
>
> (3) Forces those who want named keyword parameters to parse them from
> the KeyObject value themselves.
>
> Since named keyword parameters are surely going to be the most common
> use-case (just as they are for other functions), this makes the common
> case difficult and the rare and unusual case easy.
>
> (4) KeyObject doesn't exist. We would need a new builtin type to support
> this, as well as the new syntax. This increases the complexity and
> maintenance burden of this new feature.
>
> (5) Compounds the "kind of screwy" (Greg's words) nature of subscripting
> by extending it to keyword arguments as well as positional arguments.
>
>
>
> --
> Steven
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/DAND7BJXUAVPGQU4EDHX2YIZ7HUNDASJ/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Kind regards,
Stefano Borini
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/FK3LOXO66WELOOBRXUCCEKP4QKFUIMTU/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 472 - slices in keyword indices, d[x=1:3]
On Mon, 24 Aug 2020 at 02:42, Todd wrote: > So I think any revision to PEP 472 or new PEP should directly and explicitly > support the use of slices. Duly noted (I am revisiting the PEP in light of all your comments starting from 2019) but yes, I fully agree that slicing should be supported for keyed arguments. -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EJEYN7XKI6NF62PYXCAL46CZZKTKYBIP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic
On Mon, 24 Aug 2020 at 22:00, Guido van Rossum wrote: > > Well then you can keep wondering. Sorry I don't get your point. I do understand that changing all the method names would have been a major breakage, but I don't see how it would affect git history (sure, I understand that changing all the tests in the testsuite would throw a wrench in blame, but it would not be mandatory to do so), nor I understand how providing pep-8 compliant names as preferred and recommended names while keeping the old ones for compatibility would be a problem. > On Mon, Aug 24, 2020 at 13:59 Stefano Borini wrote: >> >> On Mon, 24 Aug 2020 at 21:54, Guido van Rossum wrote: >> >> > >> >> > Because all the git history would be lost, and lots of code would break. >> >> >> >> Well, names could have been converted to their snake case counterpart, >> >> possibly even leaving the old camelcase form as deprecated, and in any >> >> case the breakage was already being performed for many modules such as >> >> e.g. StringIO.StringIO >> >> >> >> >> >> > On Mon, Aug 24, 2020 at 13:14 Stefano Borini >> > wrote: >> >> >> >> >> >> Brings me to a question. Why weren't the logger and unittest module >> >> >> >> >> >> "PEP-8"ified in the transition from 2 to 3? -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/7JNJKUID4IIPZH2ZXIOP4QBQXRGQR45S/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic
On Mon, 24 Aug 2020 at 21:54, Guido van Rossum wrote: > > Because all the git history would be lost, and lots of code would break. Well, names could have been converted to their snake case counterpart, possibly even leaving the old camelcase form as deprecated, and in any case the breakage was already being performed for many modules such as e.g. StringIO.StringIO > On Mon, Aug 24, 2020 at 13:14 Stefano Borini wrote: >> >> Brings me to a question. Why weren't the logger and unittest module >> >> "PEP-8"ified in the transition from 2 to 3? >> >> >> >> And I agree that both modules are a bit odd. >> >> >> >> On Mon, 24 Aug 2020 at 17:31, Christopher Barker wrote: >> >> > >> >> > I agree about the heavy rhetoric, but the OP has a good point. I have >> > often thought the same thing. >> >> > >> >> > Isn’t it a bit ironic that the stdlib version of an important module is a >> > poor example of Pythonic style[*] and we have to find a third party >> > package to do something as important as logging? >> >> > >> >> > But the way forward would be to suggest an alternative, rather than rant >> > about it :-) >> >> > >> >> > So the question is: would an update/addition/alternative API to the >> > logging module be considered for inclusion in the stdlib? >> >> > >> >> > -CHB >> >> > >> >> > [*] Of course, it is not a given that logging IS non-Pythonic, if the >> > community likes it as it is, then this, of course, is a non starter. >> >> > >> >> > PS: unittest is another candidate, though even more integral to core >> > Python. But I’d love to see a “pytest lite” in the stdlib. I suspect I’m >> > not the only one that only uses unittest for the stdlib. >> >> > >> >> > IIUC, both the logging and unittest design were inspired (if not directly >> > ported) from Java. Which explains their out-of-place feeling design. As >> > the say, “Python is not Java” — so maybe Python should not log and test >> > like java? >> >> > >> >> > -CHB >> >> > >> >> > >> >> > >> >> > On Mon, Aug 24, 2020 at 7:41 AM Guido van Rossum wrote: >> >> >> >> >> >> There is no need for all that heavy rhetoric. >> >> >> >> >> >> There are many 3rd party modules that provide simpler interfaces to the >> >> logging module. >> >> >> >> >> >> Go do some Googling. >> >> >> >> >> >> On Mon, Aug 24, 2020 at 06:03 Adam Hendry >> >> wrote: >> >> >>> >> >> >>> Dear Python-ideas, >> >> >>> >> >> >>> After looking at the `logging` module, I slammed my fist on my desk and >> >>> declared "There has to be a better way!" >> >>> (https://www.youtube.com/watch?v=wf-BqAjZb8M). Can we make the `logging` >> >>> module more "Pythonic" per Raymond Hettinger's presentation "Beyond PEP >> >>> 8 -- Best practices for beautiful intelligible code - PyCon 2015"? >> >> >>> >> >> >>> Thank you, >> >> >>> Adam Hendry >> >> >>> >> >> >>> >> >> >>> ___ >> >> >>> >> >> >>> Python-ideas mailing list -- python-ideas@python.org >> >> >>> >> >> >>> To unsubscribe send an email to python-ideas-le...@python.org >> >> >>> >> >> >>> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> >> >>> >> >> >>> Message archived at >> >>> https://mail.python.org/archives/list/python-ideas@python.org/message/BK6P32YAUZ2D763LJXKI6WNVUNHQIBKH/ >> >> >>> >> >> >>> Code of Conduct: http://python.org/psf/codeofconduct/ >> >> >>> >> >> >> -- >> >> >> --Guido (mobile) >> >> >> >> >> >> >> >> >> ___________ >> >> >> >> >> >> Python-ideas mailing list -- python-ideas@python.org >> >> >> >> >> >> To unsubscribe send a
[Python-ideas] Re: FEATURE REQUEST: Make `logging` Module more Pythonic
Brings me to a question. Why weren't the logger and unittest module "PEP-8"ified in the transition from 2 to 3? And I agree that both modules are a bit odd. On Mon, 24 Aug 2020 at 17:31, Christopher Barker wrote: > > I agree about the heavy rhetoric, but the OP has a good point. I have often > thought the same thing. > > Isn’t it a bit ironic that the stdlib version of an important module is a > poor example of Pythonic style[*] and we have to find a third party package > to do something as important as logging? > > But the way forward would be to suggest an alternative, rather than rant > about it :-) > > So the question is: would an update/addition/alternative API to the logging > module be considered for inclusion in the stdlib? > > -CHB > > [*] Of course, it is not a given that logging IS non-Pythonic, if the > community likes it as it is, then this, of course, is a non starter. > > PS: unittest is another candidate, though even more integral to core Python. > But I’d love to see a “pytest lite” in the stdlib. I suspect I’m not the only > one that only uses unittest for the stdlib. > > IIUC, both the logging and unittest design were inspired (if not directly > ported) from Java. Which explains their out-of-place feeling design. As the > say, “Python is not Java” — so maybe Python should not log and test like java? > > -CHB > > > > On Mon, Aug 24, 2020 at 7:41 AM Guido van Rossum wrote: >> >> There is no need for all that heavy rhetoric. >> >> There are many 3rd party modules that provide simpler interfaces to the >> logging module. >> >> Go do some Googling. >> >> On Mon, Aug 24, 2020 at 06:03 Adam Hendry >> wrote: >>> >>> Dear Python-ideas, >>> >>> After looking at the `logging` module, I slammed my fist on my desk and >>> declared "There has to be a better way!" >>> (https://www.youtube.com/watch?v=wf-BqAjZb8M). Can we make the `logging` >>> module more "Pythonic" per Raymond Hettinger's presentation "Beyond PEP 8 >>> -- Best practices for beautiful intelligible code - PyCon 2015"? >>> >>> Thank you, >>> Adam Hendry >>> >>> >>> ___ >>> >>> Python-ideas mailing list -- python-ideas@python.org >>> >>> To unsubscribe send an email to python-ideas-le...@python.org >>> >>> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >>> >>> Message archived at >>> https://mail.python.org/archives/list/python-ideas@python.org/message/BK6P32YAUZ2D763LJXKI6WNVUNHQIBKH/ >>> >>> Code of Conduct: http://python.org/psf/codeofconduct/ >>> >> -- >> --Guido (mobile) >> >> >> ___ >> >> Python-ideas mailing list -- python-ideas@python.org >> >> To unsubscribe send an email to python-ideas-le...@python.org >> >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/4M6NMEGR32DTY4T5S5UMTQV7LAQKEKCU/ >> >> Code of Conduct: http://python.org/psf/codeofconduct/ >> > -- > Christopher Barker, PhD > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/MXQPMHKA6D63OAAWJIOPF7QBSUB33FN2/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/DP4T757D4UHQ2PX7NJ3EZE7763R4Z5QC/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Changing item dunder method signatures to utilize positional arguments (open thread)
On Sat, 8 Aug 2020 at 05:12, Ricky Teachey wrote:
> The semantic meaning of m[1, 2, a=3, b=2] might be made to mean:
>
> 5.m.__getx__(1, 2, a=3, b=4)
>
> ...which would in turn call, by default:
>
> m.__getitem__((1, 2), a=3, b=4)
I am currently in the process of scouting the whole set of threads and
rewrite PEP-472, somehow.
but just as a 2 cents to the discussion, the initial idea was focused
on one thing only: give names to axes.
When you have a getitem operation, you are acting on a set of axes.
e.g. a[4,5,6] acts on three axes. The first axis index is 4, the
second is 5 and the third is 6.
These axes currently are anonymous, but the whole idea is that a name
could be assigned to them.
Which is kind of asymmetric with the whole args/kwargs structure of a
function. In a function, your "axes" (which are your arguments)
_always_ have a name. Not so in getitem operations:
naming axes is optional. There's no such thing as optionally named
function arguments.
Given the asymmetry, and the need for backward compat, would it make a
possible solution to have __getitem__() accept one additional argument
"names" containing a tuple with the names?
e.g. if you call a[1,2] __getitem__(index, names) will receive
index=(1,2), names=(None, None)
if you call a[foo=1, bar=2] __getitem__ will receive index=(1,2),
names=("foo", "bar")
if you call a[1, bar=2] __getitem__ will receive index=(1,2),
names=(None, "bar")
Now, I personally don't like this solution, especially because now
passing names depend if it was declared in the signature to begin
with, but I am just throwing also this idea in the mix. Apologies if
it was already passed by someone else.
My point is that the core of the issue is to name axes (with loose
definition of what axes are. In the case of generic types, they are
the degrees of freedom of the type).
How these names are then handled (and recognised) _could_ be put in
the hands of the user (in other words, python will say "here are the
names, I have no idea if they mean something or not. it's your duty to
find out, if you care about it")
But I would like to raise another question. Is there another language
out there that provides the same feature? I am not aware of any.
--
Kind regards,
Stefano Borini
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/QUXRDOLBUNJGSTTCWA2Y5WBGSGM457D7/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 472 - regarding d[x=1, y=2] and similar
On Fri, 14 Aug 2020 at 11:07, Jonathan Fine wrote: > NO ARGUMENTS > > I'd like d[] to become valid syntax. This makes me a bit uncomfortable. > SEMANTICS OF NO ARGUMENTS > I can see two basic ways of allowing no arguments. One is for the interpreter > to construct an object that is the argument passed to __getitem__ and so > forth. The other is to not pass an argument at all. I see this as a secondary > question. I understand it makes sense if you assume that you can have default arguments. but still it's kind of weird. and it's not always obvious how each structure is going to implement it. > NO POSITIONAL ARGUMENTS > I'd like > >>> d[x=1, y=2] > to be valid syntax. It's not clear to me that all agree with this. Even if > there are no objections, I'd like positive confirmation. Yes, it should be. > CONSEQUENCE > Suppose >>>> d[x=1, y=2] > is valid syntax. If so, then there is I think consensus that > >>> d[x=1, y=2] = 42 > >>> d[x=1, y=2] > 42 > can be implemented, where d is an instance of a suitable class. Otherwise, > what's the point? Yes. Agreed. > QUESTION > Suppose we have > >>> d[x=1, y=2] = 42 > >>> d[x=1, y=2] > 42 > where d is an instance of a suitable class X that has no special knowledge of > keywords. Initially, when I wrote the pep, the idea was that there was no distinction of kwargs and normal args. Basically the idea was that currently the only "metainfo" associated to every argument is purely positional (e.g. the meaning of position 1 is implicit). But index 1 can have a specific semantic meaning (e.g. it could be a day). So in practice they would be one and the same, just that you add non-positional semantic meaning to indexes, and you can refer to them either through the position, or this additional semantic meaning. In other words, if you claim that the first index is day, and the second index is detector, somehow, there is no difference between these d[3, 4] d[day=3, detector=4] d[detector=4, day=3] In fact, my initial feeling would be that you can use either one or the other. You should not be able to mix and match. the pep went through various revisions, and we came to a possible proposal, but it's not set in stone. > In other words, we also have for example > >>> d[a='alpha', g='gamma', z=12] = 'cheese' > >>> d[a='alpha', g='gamma', z=12] > 'cheese' > > My question is this: Should such a class >>>> X = type(d) > be part of standard Python, as part of PEP 472? (My answer is: Yes, it should > be in standard Python.) Yes and no. In my opinion, the current classes (e.g. dict) *may* be extended to support this (optional) functionality. But the target should probably be something like numpy or pandas, or any other class that wants the flexibility for a named index approach. I would not add X to python stdlib. -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BEVAR5LB5SN66RBR7DRAHSBWMHUUKLSJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: basic matrix object
On Fri, 14 Aug 2020 at 05:37, Guido van Rossum wrote: > My own strawman would be to limit a Matrix to 2-dimensionality -- I believe > that even my college linear algebra introduction (for math majors!) didn't > touch upon higher dimensionality, and I doubt that what I learned in high > school about the topic went beyond 3x3 (it might not even have treated > non-square matrices). Absolutely agree, dimensionality 2 is a must. For two reasons. First, it's easy to understand and implement. Second it actively discourages those who would like to use this matrix for real calculations. The main point is basic and simple: teaching, geometry computation (e.g. on point rotation/translation) etc. Things like that. Anything else is beyond the scope of such a module and should be implemented using numpy. Calculations about determinant, element-wise operations, matrix multiplication, inverse, etc are also basic operations that are likely to come up during either a course or trivial computations for e.g. geometry. I would not add things like QR or Cholesky factorization. -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UQDBXSVCLARFIGNIZPYGIJ5S4M7VPMCO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] basic matrix object
Excuse me if I am out of the loop and this is already available, but I haven't seen it and googling is not exactly easy as numpy introduces considerable noise. With the introduction of the statistics module, the standard library provides basic statistical functions that can be useful in many scenarios, including teaching. The math module has plenty of mathematical functions that are very interesting, but no Matrix object. When newcomers want to have a matrix object, they end up implementing a list of lists (as suggested by the documentation, e.g. see https://docs.python.org/3/tutorial/datastructures.html?highlight=matrix#nested-list-comprehensions and https://docs.python.org/3/faq/programming.html?highlight=matrix#how-do-i-create-a-multidimensional-list) but it's ambiguous (is each entry a row or a column?), and does not enforce types or equal length of each entry. Generally, when a Matrix object is needed, numpy is the point of reference, but numpy requires understanding pip, installing modules, maybe creating a virtual environment and finally understanding numpy. I would propose a simple, straightforward, low performance object to perform trivial operations such as matrix multiplication, transposition, addition, linear problem solving, determinant. The absolute bare minimum for an introductory linear algebra course. The syntax should mimic numpy to train newcomers to the numpy syntax whenever possible, and of course should implement the @ operator. There is already a similar entity in the "array" module, which is a simple version of a numpy array, except that is only one-dimensional. -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/R334EPWCXRM3RXFEUXVN4HYG6WQKKCGT/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Aside RE: Re: macaddress or networkaddress module
On Mon, 6 Apr 2020 at 09:40, Steve Barnes wrote: > > As an aside I have a perfect example to back up what Paul is saying below. I > work for a large corporation where developers are permitted to install python > modules on their development machines, (subject to some licence > restrictions), but the proxy settings required to get to PyPi vary from user > to user, site to site, day to day (sometimes hour to hour) and connection > type to connection type, e.g. If you are connected via WiFi you need to use a > different proxy to that needed if you are on a wired connection and on a VPN > (we have more than one in use) different again. FYI there's an issue open on pip to allow for multiple proxies. I have this exact situation as well. https://github.com/pypa/pip/issues/8232 -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/X7OFRRGBWGSAPC6VW55SG3NBIBZL33UU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments
On Mon, 20 Jul 2020 at 03:26, Jonathan Goble wrote: >> One use case that comes up in xarray and pandas is support for indicating >> indexing "modes". For example, when indexing with floating point numbers >> it's convenient to be able to opt-in to approximate indexing, e.g., >> something like: >> array.loc[longitude, latitude, method='nearest', tolerance=0.001] > > > I had to stare at this for a good 30 seconds before I realized that this > wasn't a function/method call. Except for the square brackets instead of > parentheses, it would be. > > Honestly, this whole idea smells to me like just wanting another type of > function call with different semantics. I agree and in fact it was a very weak point. The main point, in my opinion, would be axis naming. Whatever the term "axis" means. In the case of an array, it can be obvious. In the case of the starting mail, axis is basically the degree of freedom of customisation of a typing class. -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/IGFJK7S5YGD22Z2SQV3OZXYIETM6VDBH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments
On Fri, 17 Jul 2020 at 20:58, Christopher Barker wrote: > So what would the “key object” be I the proposed case: > > d2[a=1, b=2] > > A namedtuple? Or namedtuple-like object? This was already discussed in PEP-472 as the "namedtuple" strategy, but among the various negative points were the relative lack of maturity of the namedtuple and the _n magic field that we assigned to it. I kind of feel they are still relevant, but I might be wrong. The PEP is 5 years old. -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/EK6LXJ453JCU3HUAMDNPZSWGBOAJFATV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Function suggestion: itertools.one()
+1 very useful also for me. Once in a while I have this exact
scenario. Not often enough to get annoyed, but often enough that it
would be nice to have.
On Tue, 28 Jul 2020 at 20:27, Noam Yorav-Raphael wrote:
>
> Hello,
>
> There's a simple function that I use many times, and I think may be a good
> fit to be added to itertools. A function that gets an iterator, and if it has
> exactly one element returns it, and otherwise raises an exception. This is
> very useful for cases where I do some sort of query that I expect to get
> exactly one result, and I want an exception to be raised if I'm wrong. For
> example:
>
> jack = one(p for p in people if p.id == '1234')
>
> sqlalchemy already has such a function for queries:
> https://docs.sqlalchemy.org/en/13/orm/query.html#sqlalchemy.orm.query.Query.one
>
> more-itertools has this exact function:
> https://more-itertools.readthedocs.io/en/latest/api.html#more_itertools.one
>
> Here is a simple implementation:
>
> def one(iterable):
> it = iter(iterable)
> try:
> first = next(it)
> except StopIteration:
> raise ValueError("Iterator is empty")
> try:
> second = next(it)
> except StopIteration:
> return first
> else:
> raise ValueError("Iterator has more than one item")
>
> I brought this up on python-dev, but it should be discussed here.
> Here is the discussion:
> https://mail.python.org/archives/list/python-...@python.org/thread/D52MPKLIN4VEXBOCKVMTWAK66MAOEINY/
>
> Brett Cannon said that this idea has been brought up at least twice before. I
> found:
> https://mail.python.org/archives/list/python-ideas@python.org/thread/FTJ6JRDTZ57HUVZ3PVIZV2NHU2NLAC4X/#RMWV3SNZ2N4KZLPKPIDE42H46QDEIVHE
>
> https://mail.python.org/archives/list/python-ideas@python.org/thread/REYDJFCXQNQG4SAWKELQMCGM77IZG47Q/#ITR2ILPVCKYR52U2D7RHGENASZTNVDHN
>
> The first thread hasn't reached any operative conclusion. The second thread
> was very long, and seemed to focus mostly on another function, first(), that
> doesn't check if there is more than one item. Joao S. O Bueno said that it
> passed "general approval". I think that perhaps a new discussion, focused
> just on one (no pun intended) function in the itertools module may reach a
> conclusion.
>
> It was suggested that instead of an additional function, one can use iterator
> unpacking:
>
> jack, = (p for p in people if p.id == '1234')
> or
> [jack] = (p for p in people if p.id == '1234')
>
> I still think that having a one() function would be useful, since:
> 1. I think it spells the intention more clearly. It is not symbols that you
> need to understand their meaning in order to understand that I expect the
> iterable to have exactly one item, it's spelled in code.
> 2. The exception would be easier to understand, since errors in tuple
> unpacking usually mean something else.
> 3. The one() function allows you to use the result inside an expression
> without assigning it to a variable. Therefore, I think it encourages writing
> better code. It's very easy to write:
> print([p for p in people if p.id == '1234][0])
> (which has the problem of not verifying the assumption that there's no more
> than one result), and I find it easier to replace _[0] with one(_) than to be
> required to name a new variable, and instead of having an operation on the
> iterable, change the way I'm assigning to it.
>
> WDYT?
>
> Cheers,
> Noam
>
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/6OLEL4XTUWXRI7ENODKEDOYFBRVDYKI7/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Kind regards,
Stefano Borini
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/FZGXJ36VUMU5XYVOSZR4AXV2FDSQLXEJ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Package kwkey and PEP 472 -- Support for indexing with keyword arguments
Ok so let's do it like this. I'll open a PR against the PEP and I will aggregate all the feedback from this discussion as additional notes. I'll have to re-read the PEP myself, It's been a while. As I said, I'm swamped so I might start working on it probably on Monday. On Wed, 5 Aug 2020 at 23:08, Christopher Barker wrote: > > On Wed, Aug 5, 2020 at 3:01 PM Stefano Borini > wrote: >> >> Maybe I should open a new PEP? > > > I"ll let teh PEP editors decide, but it look slike it was "rejected"m with > this comment: > > "The idea never seemed to gain any traction over its near 5 years in > existence as a PEP." > > So I'd think re-opening it would be fine -- rather than clutter up the PEP > namespace... > > Maybe we could use a "suspended" status for PEPs? > > -CHB > > > >> On Tue, 4 Aug 2020 at 14:26, Jonathan Fine wrote: >> > >> > Thank you all for your posts. I'm busy now and for the next few days, so >> > have little time to respond. Here's some comments and suggestions. >> > >> > I hope that Andras, Caleb, Stefano, Neil, Joao Bueno, Todd and Stephan >> > will take a special interest in this post. In the previous thread, these >> > people saw that the proposed new syntax >> > d[1, 2, a=3, b=4] >> > would bring benefits to their own particular use of Python. (Apologies for >> > any omitted names or misunderstanding of posts). >> > >> > I hope the package kwkey shows that it is possible now to write >> > from kwkey import o >> > d[o(1, 2, a=3, b=4)] >> > as a workable present day substitute for the proposed syntax >> > d[1, 2, a=3, b=4] >> > >> > I think using this can safely go ahead, even though there may be >> > disagreements on the meaning of 'o' and the implementation of classes that >> > take advantage of the new syntax. Indeed, I think going ahead now will >> > contribute to understanding and resolving the disagreements, by creating a >> > shared experience. >> > >> > I suggest that those who previously suggested uses for the proposed syntax >> > now implement some examples. (I give a list below.) They can do this using >> > my API, Steven's API, or any other API. Or indeed now, using the return >> > value of 'o' directly. >> > >> > I've started this process with a toy example: >> > https://github.com/jfine2358/python-kwkey/blob/master/kwkey/example_jfine.py >> > >> > Here are three aspects to the proposed syntax. They are all important, and >> > good design will balance between the various parts and interests. >> > >> > First, ordinary programmers, who perhaps want >> > d[1, 2] >> > d[x=1, y=2] >> > d[1, y=2] >> > d[y=2, x=1] >> > to all be equivalent, for d a mapping of whose domain is points in the x-y >> > plane. More complicated examples might be found in function annotations >> > (Andras Tantos, Caleb Donovick), quantum chemistry (Stefano Borini), >> > networkx (Neil Girdhar), numpy and pandas (Joao Bueno), xarrary (Todd, >> > Stephan Hoyer). >> > >> > Second, there are those who implement classes that make use of the >> > proposed syntax. >> > >> > Third, there are those who implement the extension of Python that allows >> > d[o(1, 2, a=3, b=4)] >> > to be replaced by >> > d[1, 2, 3, 4] >> > >> > I suggest that those who see benefits in feature produce experimental >> > implementations via kwkey, just as I did in my kwkey.example_jfine. It is >> > possible to do this now, and so have benefits now, in a way that is >> > reasonably future proof regarding implementation of the proposed new >> > syntax. >> > >> > If you're a user of kwkey, I will have some time available to help you if >> > you want it. >> > >> > I hope this helps some, and harms none. >> > -- >> > Jonathan >> > >> > >> >> >> -- >> Kind regards, >> >> Stefano Borini >> ___ >> Python-ideas mailing list -- python-ideas@python.org >> To unsubscribe send an email to python-ideas-le...@python.org >> https://mail.python.org/mailman3/lists/python-ideas.python.org/ >> Message archived at >> https://mail.python.org/archives/list/python-ideas@python.org/message/QK3YV3BUTF4VCPKNNMHFDWVJDQIJMZ3A/ >> Code of Conduct: http://python.org/psf/codeofconduct/ > > > > -- > Christopher Barker, PhD > > Python Language Consulting > - Teaching > - Scientific Software Development > - Desktop GUI and Web Development > - wxPython, numpy, scipy, Cython -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3ZVAM2G2MEFID3I767EUVV54MXLG3TET/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Package kwkey and PEP 472 -- Support for indexing with keyword arguments
I am following, but very swamped with work so I am kind of to the side for a few more days. I am thinking about looking for a sponsor for the PEP, but at this point it's better if I rework the current analysis in light of what you made and the current discussion. Maybe I should open a new PEP? On Tue, 4 Aug 2020 at 14:26, Jonathan Fine wrote: > > Thank you all for your posts. I'm busy now and for the next few days, so have > little time to respond. Here's some comments and suggestions. > > I hope that Andras, Caleb, Stefano, Neil, Joao Bueno, Todd and Stephan will > take a special interest in this post. In the previous thread, these people > saw that the proposed new syntax > d[1, 2, a=3, b=4] > would bring benefits to their own particular use of Python. (Apologies for > any omitted names or misunderstanding of posts). > > I hope the package kwkey shows that it is possible now to write > from kwkey import o > d[o(1, 2, a=3, b=4)] > as a workable present day substitute for the proposed syntax > d[1, 2, a=3, b=4] > > I think using this can safely go ahead, even though there may be > disagreements on the meaning of 'o' and the implementation of classes that > take advantage of the new syntax. Indeed, I think going ahead now will > contribute to understanding and resolving the disagreements, by creating a > shared experience. > > I suggest that those who previously suggested uses for the proposed syntax > now implement some examples. (I give a list below.) They can do this using my > API, Steven's API, or any other API. Or indeed now, using the return value of > 'o' directly. > > I've started this process with a toy example: > https://github.com/jfine2358/python-kwkey/blob/master/kwkey/example_jfine.py > > Here are three aspects to the proposed syntax. They are all important, and > good design will balance between the various parts and interests. > > First, ordinary programmers, who perhaps want > d[1, 2] > d[x=1, y=2] > d[1, y=2] > d[y=2, x=1] > to all be equivalent, for d a mapping of whose domain is points in the x-y > plane. More complicated examples might be found in function annotations > (Andras Tantos, Caleb Donovick), quantum chemistry (Stefano Borini), networkx > (Neil Girdhar), numpy and pandas (Joao Bueno), xarrary (Todd, Stephan Hoyer). > > Second, there are those who implement classes that make use of the proposed > syntax. > > Third, there are those who implement the extension of Python that allows > d[o(1, 2, a=3, b=4)] > to be replaced by > d[1, 2, 3, 4] > > I suggest that those who see benefits in feature produce experimental > implementations via kwkey, just as I did in my kwkey.example_jfine. It is > possible to do this now, and so have benefits now, in a way that is > reasonably future proof regarding implementation of the proposed new syntax. > > If you're a user of kwkey, I will have some time available to help you if you > want it. > > I hope this helps some, and harms none. > -- > Jonathan > > -- Kind regards, Stefano Borini ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QK3YV3BUTF4VCPKNNMHFDWVJDQIJMZ3A/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments
I am unsure of the process if there's interest. Should I revise the
PEP and create a new one?
On Tue, 21 Jul 2020 at 06:29, Christopher Barker wrote:
>
> On Mon, Jul 20, 2020 at 3:17 AM Rhodri James wrote:
>>
>> Ironically that example pushes me back to -1. It may look a lot like
>> xarray and pandas working, but that just means it should be in xarray
>> and/or pandas.
>
>
> after following most of this discussion, I'm still not sure what we'd get
> with keywords in indexing.
>
> But I do think it would be nice of we could use slice syntax in other places.
> That would allow things like xarray and pandas to use slices in regular
> function calls. here's an example from the xarray docs:
>
> da.isel(space=0, time=slice(None, 2))
>
> wouldn't that be nice as:
>
> da.isel(space=0, time=:2)
>
> or:
>
> da.sel(time=slice("2000-01-01", "2000-01-02"))
>
> could be:
>
> da.sel(time="2000-01-01":"2000-01-02")
>
> As far as I can tell, slicing syntax is currently a syntax error in these
> cases, and any others I thought to test.
>
> Is there a reason to not allow syntax for creating a slice object to be used
> anywhere (Or more places, anyway)?
>
> By the way, I just noticed this note in the xarray docs:
>
> """Note: We would love to be able to do indexing with labeled dimension names
> inside brackets, but unfortunately, Python does yet not support indexing with
> keyword arguments like da[space=0]
> """
> So they would like it :-)
>
> -CHB
>
>
>
> --
> Christopher Barker, PhD
>
> Python Language Consulting
> - Teaching
> - Scientific Software Development
> - Desktop GUI and Web Development
> - wxPython, numpy, scipy, Cython
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/VSQO7A6K2SA7KI25U25CHROPEHCZFEG2/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Kind regards,
Stefano Borini
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/FVBXHEKTOTRXBBQ2AVUHTF72YFD4HCCH/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Bringing the print statement back
-1 because it will introduce potential ambiguities and will generate
stylistic battles between developers. It will also add questions when
teaching python, having to explain the potentially different syntax
one might find around.
On Wed, 10 Jun 2020 at 01:07, Guido van Rossum wrote:
>
> In Python 3.10 we will no longer be burdened by the old parser (though 3rd
> party tooling needs to catch up).
>
> One thing that the PEG parser makes possible in about 20 lines of code is
> something not entirely different from the old print statement. I have a
> prototype:
>
> Python 3.10.0a0 (heads/print-statement-dirty:5ed19fcc1a, Jun 9 2020,
> 16:31:17)
> [Clang 11.0.0 (clang-1100.0.33.8)] on darwin
> Type "help", "copyright", "credits" or "license" for more information.
> Cannot read termcap database;
> using dumb terminal settings.
> >>> print 2+2
> 4
> >>> print "hello world"
> hello world
> >>> print "hello", input("Name:")
> Name:Guido
> hello Guido
> >>> print 1, 2, 3, sep=", "
> 1, 2, 3
> >>>
>
> But wait, there's more! The same syntax will make it possible to call *any*
> function:
>
> >>> len "abc"
> 3
> >>>
>
> Or any method:
>
> >>> import sys
> >>> sys.getrefcount "abc"
> 24
> >>>
>
> Really, *any* method:
>
> >>> class C:
> ... def foo(self, arg): print arg
> ...
> >>> C().foo 2+2
> 4
> >>>
>
> There are downsides too, though. For example, you can't call a method without
> arguments:
>
> >>> print
>
> >>>
>
> Worse, the first argument cannot start with a parenthesis or bracket:
>
> >>> print (1, 2, 3)
> 1 2 3
> >>> C().foo (1, 2, 3)
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: C.foo() takes 2 positional arguments but 4 were given
> >>> print (2+2), 42
> 4
> (None, 42)
> >>> C().foo [0]
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: 'method' object is not subscriptable
> >>>
>
> No, it's not April 1st. I am seriously proposing this (but I'll withdraw it
> if the response is a resounding "boo, hiss"). After all, we currently have a
> bunch of complexity in the parser just to give a helpful error message to
> people used to Python 2's print statement:
>
> >>> print 1, 2, 3
> File "", line 1
> print 1, 2, 3
> ^
> SyntaxError: Missing parentheses in call to 'print'. Did you mean print(1, 2,
> 3)?
> >>>
>
> And IIRC there have been a number of aborted attempts at syntactic hacks to
> allow people to call functions (like print) without parentheses, although (I
> think) none of them made it into a PEP. The PEG parser makes this much
> simpler, because it can simply backtrack -- by placing the grammar rule for
> this syntax (tentatively called "call statement") last in the list of
> alternatives for "small statement" we ensure that everything that's a valid
> expression statement (including print() calls) is still an expression
> statement with exactly the same meaning, while still allowing parameter-less
> function calls, without lexical hacks. (There is no code in my prototype that
> checks for a space after 'print' -- it just checks that there's a name,
> number or string following a name, which is never legal syntax.)
>
> One possible extension I didn't pursue (yet -- dare me!) is to allow
> parameter-less calls inside other expressions. For example, my prototype does
> not support things like this:
>
> >>> a = (len "abc")
> File "", line 1
> a = (len "abc")
> ^
> SyntaxError: invalid syntax
> >>>
>
> I think that strikes a reasonable balance between usability and reduced
> detection of common errors.
>
> I could also dial it back a bit, e.g. maybe it's too much to allow 'C().foo
> x' and we should only allow dotted names (sufficient to access functions in
> imported modules and method calls on variables). Or maybe we should only
> allow simple names (allowing 'len x' but disallowing 'sys.getrefcount x'. Or
> maybe we should really only bring back print statements.
>
> I believe there are some other languages that support a similar grammar
> (Ruby? R? Raku?) but I haven't investigated.
>
> Thoughts?
>
> --
> --Guido van Rossum (python.org/~guido)
> Pronouns: he/him (why is my pronoun here?)
> _
[Python-ideas] Re: PEP 472 -- Support for indexing with keyword arguments
I am one of the authors of the PEP. My problem was to deal with
natural notation in quantum chemistry mostly. It had no technical
purpose, but I still think it would open some interesting options.
The PEP was rejected mostly because of lack of interest.
On Mon, 4 May 2020 at 00:07, Andras Tantos wrote:
>
> Hello!
>
> I'm not sure I'm addressing the right audience here, so please direct me to
> the appropriate channel if that's the case...
>
> My name is Andras Tantos and I'm working on a Python library desscribing HW
> designs. I came across this problem of __getitem__ and co. not supporting
> kwargs. Apparently this extension was proposed and rejected as PEP 472.
>
> Apart from my use-case, which is arguably a corner-case and not worth
> modifying the language for, I believe there are two important use-cases that
> are worth considering with the latest improvements in the language:
>
> 1. With the recent type-hint support, the feature could be made way more
> descriptive if this PEP got implemented.
>
> For example, instead of doing the following:
>
> def func(in: Dict[str, int])
>
> one could write:
>
> def func(in: Dict[key=str, value=int])
>
> 2. It would also make 'generic classes' much cleaner to implement, similar to
> the way type-hints look. Consider the following code:
>
> class _Generic(object):
> Specializations = []
> @classmethod
> def __getitem__(cls, *args):
> name = f"Generic_{len(cls.Specializations)}"
> Specialized = type(name, (cls,), {"specials": tuple(args)})
> cls.Specializations.append(Specialized)
> return Specialized
> def __init__(self, value = None):
> self.value = value
> def __str__(self):
> if hasattr(self, "specials"):
> return(f"[{type(self)} - " + ",".join(str(special) for special in
> self.specials) + f"] - {self.value}")
> else:
> return(f"[{type(self)} - GENERIC" + f"] - {self.value}")
> Generic = _Generic()
> #g = Generic() - fails because of no specialization is given
> s1 = Generic[12]()
> s2 = Generic[42]("Hi!")
> print(s1)
> print(s2)
>
> Running this simple example results in:
>
> python3 -i python_test.py
> [ - 12] - None
> [ - 42] - Hi!
>
> You can see how the specialized parameters got passed as well as the ones to
> '__init__'. Obviously, in real code the idea would be to filter generic
> parameters and set up 'Specialized' with the right set of methods and
> arguments.
>
> Now, without kwargs support for __getitem__, it's impossible to pass named
> arguments to the specialization list, which greatly limits the usability of
> this notation.
>
> I don't know how convincing these arguments and use-cases are for you, but
> could you advise me about how to start the 'ball rolling' to drum-up support
> for re-activating this PEP?
>
> Thanks again,
> Andras Tantos
>
>
> ___
> Python-ideas mailing list -- python-ideas@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/6OGAFDWCXT5QVV23OZWKBY4TXGZBVYZS/
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Kind regards,
Stefano Borini
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/UHVZLOU57HS2HGH6E4JCDW6ETAIORKG7/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Update pep8 for stressing type hinted long parameter in functions
Thanks. I'll check black behavior and file an issue there tonight. In
any case, the point stands. I think new, rather expected case should
be clarified explicitly in the pep.
On Wed, 27 Nov 2019 at 14:53, Ivan Levkivskyi wrote:
>
> IIRC, black actually uses the first style you mention, so maybe you should
> rather discuss it there first. Otherwise this will create a weird situation
> where one of the most popular auto-formatter formats code in violation of PEP
> 8.
>
> --
> Ivan
>
>
>
> On Wed, 27 Nov 2019 at 11:42, Stefano Borini wrote:
>>
>> This may be a pet peeve of mine, but with the introduction of type
>> hints, more and more function definitions have become longer than 80
>> characters. This used to seldom happen in the past.
>> The problem, as I see it, is that there seem to be a general tendency
>> to use this way of indenting, e.g. see (among many):
>>
>> https://github.com/samuelcolvin/pydantic/blob/c71326d4a6898612597d3c647a4256f168818e30/pydantic/parse.py#L47
>>
>> def load_file(
>> path: Union[str, Path],
>> *,
>> content_type: str = None,
>> encoding: str = 'utf8',
>> proto: Protocol = None,
>> allow_pickle: bool = False,
>> ) -> Any:
>> path = Path(path)
>> b = path.read_bytes()
>> if content_type is None:
>> if path.suffix in ('.js', '.json'):
>> proto = Protocol.json
>> elif path.suffix == '.pkl':
>> proto = Protocol.pickle
>>
>> This violates pep8
>>
>> # Add 4 spaces (an extra level of indentation) to distinguish
>> arguments from the rest.
>> def long_function_name(
>> var_one, var_two, var_three,
>> var_four):
>> print(var_one)
>>
>> However, no coding styles tools report that. Flake8 does however
>> report a similar error for if conditions
>>
>> if path.suffix in (
>> '.js', '.json'
>> ):
>> proto = Protocol.json
>>
>> x.py:20:5: E125 continuation line with same indent as next logical line
>>
>> But says nothing for this monstrosity, which is the equivalent of the
>> opening case
>>
>> if path.suffix in (
>> '.js', '.json'
>> ):
>> proto = Protocol.json
>>
>> It is not my intention to trigger a massive discussion. My stance is
>> that the appropriate visual aspect of the above code should be
>>
>> def load_file(
>> path: Union[str, Path],
>> *,
>> content_type: str = None,
>> encoding: str = 'utf8',
>> proto: Protocol = None,
>> allow_pickle: bool = False) -> Any:
>> path = Path(path)
>> b = path.read_bytes()
>>
>> to keep a visual distinction in indentation between the argument list
>> and the function body, as in the spirit of pep8.
>> Regardless of the choice, I think that pep8 should be updated with the
>> appropriate style for this specific case, and style tools should
>> enforce this choice.
>>
>>
>> --
>> Kind regards,
>>
>> Stefano Borini
>> ___
>> Python-ideas mailing list -- python-ideas@python.org
>> To unsubscribe send an email to python-ideas-le...@python.org
>> https://mail.python.org/mailman3/lists/python-ideas.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-ideas@python.org/message/XKEWGJGXMANMYK37FRSJJ7IU67YUNFHC/
>> Code of Conduct: http://python.org/psf/codeofconduct/
--
Kind regards,
Stefano Borini
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/MSA5KHWWCUOH5I6UJHBBP4A6XZXLQDUF/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Update pep8 for stressing type hinted long parameter in functions
This may be a pet peeve of mine, but with the introduction of type
hints, more and more function definitions have become longer than 80
characters. This used to seldom happen in the past.
The problem, as I see it, is that there seem to be a general tendency
to use this way of indenting, e.g. see (among many):
https://github.com/samuelcolvin/pydantic/blob/c71326d4a6898612597d3c647a4256f168818e30/pydantic/parse.py#L47
def load_file(
path: Union[str, Path],
*,
content_type: str = None,
encoding: str = 'utf8',
proto: Protocol = None,
allow_pickle: bool = False,
) -> Any:
path = Path(path)
b = path.read_bytes()
if content_type is None:
if path.suffix in ('.js', '.json'):
proto = Protocol.json
elif path.suffix == '.pkl':
proto = Protocol.pickle
This violates pep8
# Add 4 spaces (an extra level of indentation) to distinguish
arguments from the rest.
def long_function_name(
var_one, var_two, var_three,
var_four):
print(var_one)
However, no coding styles tools report that. Flake8 does however
report a similar error for if conditions
if path.suffix in (
'.js', '.json'
):
proto = Protocol.json
x.py:20:5: E125 continuation line with same indent as next logical line
But says nothing for this monstrosity, which is the equivalent of the
opening case
if path.suffix in (
'.js', '.json'
):
proto = Protocol.json
It is not my intention to trigger a massive discussion. My stance is
that the appropriate visual aspect of the above code should be
def load_file(
path: Union[str, Path],
*,
content_type: str = None,
encoding: str = 'utf8',
proto: Protocol = None,
allow_pickle: bool = False) -> Any:
path = Path(path)
b = path.read_bytes()
to keep a visual distinction in indentation between the argument list
and the function body, as in the spirit of pep8.
Regardless of the choice, I think that pep8 should be updated with the
appropriate style for this specific case, and style tools should
enforce this choice.
--
Kind regards,
Stefano Borini
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/XKEWGJGXMANMYK37FRSJJ7IU67YUNFHC/
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Open parenthesis in REPL completion
My two cents as well.
I also find the open parenthesis very annoying. For me, it's asymmetry
with PyCharm behavior, and inconsistency with bash.
PyCharm adds the parenthesis, but also adds the end parenthesis, so
the whole use of parentheses is consistent: the user has not to worry
about them.
Bash refuses to guess when it's ambiguous, and stops until you fill
the ambiguous part.
Right now, the REPL implements a mixed situation where it both assumes
your usage, and does not help you all the way through. Although we can
all agree that functions most of the time are invoked, rather than
used as is.
IMHO, either the parenthesis should not be added, or two parentheses
should be added and the cursor placed in the center (I am unsure about
the details of the REPL implementation, but I guess it's possible) at
least to have a consistent experience.
On Thu, 25 Apr 2019 at 14:24, Jonathan Fine wrote:
>
> This is an interesting thread. Here's my two cents worth. (Colloquial US
> English for a low-value opinion.)
>
> I'm in favour of sensible defaults (of course). In this situation, perhaps
> this means defaults that work well for those who would find it difficult to
> select a different default. Put enough way, values that work well for Emacs
> users should not be the default (unless they also work well for beginners).
>
> Sometimes, when I'm using a module for the first time (or when I'm puzzled
> about Python's behaviour and online documentation), I find myself doing
> >>> help(something)
> quite often. And I find myself typing
> >>> help({})
> instead of
> >>> help(dict)
> to avoid the unwanted
> >>> help(dict(
>
> My preference, which might work well for a wide range of use cases, is
> 1. If the initial identifier is help, tab produces the opening paren (.
> 2. If the intial identifier is callable, tab produces the opening paren (.
> 3. After help(, tab does not produce opening paren (.
> 4. Otherwise, tab does produce opening paren (.
> 5. Perhaps, after something like
> >>> help(int
> have tab produce the CLOSING paren ).
>
> As I said, just my two cents worth. Your opinions may vary.
>
> --
> Jonathan
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
--
Kind regards,
Stefano Borini
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Catching the return value of a generator at the end of a for loop
On Wed, 17 Apr 2019 at 00:45, Steven D'Aprano wrote: > I don't know. You tell us -- why do you care about the StopIteration > value in a for-loop? I came across the idea while I was reading various PEPs, so I don't have an actual use case under my hands right now. However, in the past I had a circumstance that might have called for that. Of course it was easy to workaround. I was iterating over plugins as they were loaded, using a generator, and setting up some configuration options. e.g. def load_plugins(): for plugin in pluginloader: if plugin.success: plugin.setup(configuration_vars) In some cases, some of the plugins failed to load (e.g. because there was a syntax error in their content). In my design, the plugin class instance had a flag indicating if it was successful or not (plugin.success). I wanted to keep track of how many plugins failed to load and how many were successful, so I could return that information to the user. This calls for counting at the level of load_plugins(). If pluginloader returned a tuple (num_successful, num_failed) it would save a (agreed trivial) need to count this information in the caller. -- Kind regards, Stefano Borini ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Catching the return value of a generator at the end of a for loop
I don't like it either. Ideally, I would want "returning", but of course a new keyword is not an option for such limited use case. "as" is probably much better, and the behavior of as in other contexts is very similar. On Tue, 16 Apr 2019 at 23:42, Jan Kaliszewski wrote: > > Hello, > > 2019-04-16 Stefano Borini dixit: > > > def g(): > > yield 2 > > yield 3 > > return 6 > [...] > > for x in g() return v: > > print(x) > > > > print(v) # prints 6 > > I like the idea -- occasionally (when dealing with `yield > from`-intensive code...) I wish such a shortcut existed. > > I don't like the proposed keyword. Maybe `as` would be better? > > for x in g() as v: > print(x) > > print(v) > > Cheers, > *j > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ -- Kind regards, Stefano Borini ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Catching the return value of a generator at the end of a for loop
given the following code def g(): yield 2 yield 3 return 6 for x in g(): print(x) The output is obviously 2 3 As far as I know, there is currently no way to capture the StopIteration value when the generator is used in a for loop. Is it true? If not, would a syntax like: for x in g() return v: print(x) print(v) # prints 6 be useful? It would be syntactic sugar for (corner cases omitted) def g(): yield 2 yield 3 return 6 it = iter(g()) while True: try: x = next(it) except StopIteration as exc: v = exc.value break else: print(x) print(v) -- Kind regards, Stefano Borini ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Exception for developer errors?
That's quite a good idea, but then I think it should be more explicit in the documentation that the purpose goes beyond the assert statement failure. I've never seen AssertionError raised manually. On Wed, 10 Apr 2019 at 23:15, Jeroen Demeyer wrote: > > On 2019-04-11 00:09, Stefano Borini wrote: > > I occasionally found situations where I want to raise an exception for > > errors that can only arise because the developer made a mistake, for > > example: > > I use AssertionError for this. An assertion failure means "this is a > bug", so that seems the right choice to me. You don't need to use an > actual assert statement, you can manually raise AssertionError too. > > > Jeroen. > ___ > Python-ideas mailing list > Python-ideas@python.org > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ -- Kind regards, Stefano Borini ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Exception for developer errors?
I occasionally found situations where I want to raise an exception for errors that can only arise because the developer made a mistake, for example: - an abstract method is supposed to be reimplemented and its execution is supposed to leave some internal constraints of an object unchanged, but these are instead violated. - an impossible "else" condition after an if/elif, where the else cannot simply happen unless someone really screwed up the internal state of the object. In general, when these cases happen, I use RuntimeError, but other people may choose otherwise. I've also seen ValueError, plain Exception or a specifically made subclass used in these cases. Whatever the choice is, it generally lacks clarity of communication to whoever receives it. RuntimeError is a rather generic exception according to the documentation, and you can only rely on the message, which relies on writing something appropriate for the situation: ``` exception RuntimeError Raised when an error is detected that doesn’t fall in any of the other categories. The associated value is a string indicating what precisely went wrong. ``` while it would be useful to communicate clearly to whoever is using or modifying the code "listen, it's your mistake, you misunderstood how I work or you ruined my internals, leading me to an impossible state". Also, customers seeing this kind of exception would understand without a doubt that the application is broken because of an internal error. I tried some search on the mailing list but could not find anything at a glance about this topic. Was this already discussed in the past? Thanks -- Kind regards, Stefano Borini ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
