Mailman 3 July 2023 - Python-ideas

len(Enum) should raise TypeError
by Richard Hajek 14 Aug '23

14 Aug '23

# Feature or enhancement `len(Enum)` has no useful meaning and should therefore raise the appropriate error # Pitch I cannot figure out any scenario, in which len(Enum) should not raise. Enum is a type and as any other types, such as `len(list)` or `len(dict)`, and should not give any meaningful result on len. Thoughts?

9 15

else without except
by Daniel Walker 07 Aug '23

07 Aug '23

As most of you probably know, you can use else with try blocks: try: do_stuff() except SomeExceptionClass: handle_error() else: no_error_occurred() Here, no_error_occurred will only be called if do_stuff() didn't raise an exception. However, the following is invalid syntax: try: do_stuff() else: no_error_occurred() Now you might say that this isn't needed as you can achieve the same result with do_stuff() no_error_occurred() However, what if I want to use finally as well: try: do_stuff() else: no_error_occurred() finally: cleanup() and I need no_error_occurred to be called before cleanup? For my actual use case, I've done try: do_stuff() except Exception: raise else: no_error_occurred() finally: cleanup() This seems very non-Pythonic. Is there a reason why else without except has to be invalid syntax?

6 13

Conditional 1-line expression in python
by Dom Grigonis 05 Aug '23

05 Aug '23

Hi everyone, I am not very keen on long discussions on such matter as I do not think there is much to discuss: there is no technical complexity in it and it doesn’t really change or introduce anything new. It is only a matter of opinion & style/design preferences with respect to logical order and brevity of a statement. So I thought, if anyone can be bothered on such question and instead of writing 3-minute e-mail, would take few seconds to answer 3-question poll. https://q5yitzu62.supersurvey.com <https://q5yitzu62.supersurvey.com/> Would be interesting to see if my preference is an outlier or not really. Kind regards, D. Grigonis

7 21

"Curated" package repo?
by Christopher Barker 25 Jul '23

25 Jul '23

Stating a new thread with a correct title. On 2 Jul 2023, at 10:12, Paul Moore <p.f.moore(a)gmail.com> wrote: Unfortunately, too much of this discussion is framed as “someone should”, > or “it would be good if”. No-one is saying “I will”. Naming groups, like > “the PyPA should” doesn’t help either - groups don’t do things, people do. > Who in the PyPA? Me? Nope, sorry, I don’t have the time or interest - I’d > *use* a curated index, I sure as heck couldn’t *create* one. Well, I started this topic, and I don't *think* I ever wrote "someone should", and I certainly didn't write "PyPa should". But whatever I or anyone else wrote, my intention was to discuss what might be done to address what I think is a real problem/limitation in the discoverability of useful packages for Python. And I think of it not so much as "someone should" but as "it would be nice to have". Of course, any of these ideas would take a lot of work to implement -- and even though there are a lot of folks, on this list and elsewhere, that would like to help, I don't think any substantial open-source project has gotten anywhere without a concerted effort by a very small group (often just 1) of people doing a lot of work to get it to a useful state before a larger group can contribute. So I"m fully aware that nothings going to happen unless *someone* really puts the work in up front. That someone *might* be me, but I'm really good at over-committing myself, and not so great at keeping my nose to the grindstone, so .... And I think this particular problem calls for a solution that would have to be pretty well established before reaching critical mass to actually be useful -- after all, we already have PyPi -- why go anywhere else that is less comprehensive? All that being said, it's still worth having a conversation about what a good solution might look like -- there are a lot of options, and hashing out some of the ideas might inspire someone to rise to the occasion. The :problem", as I see it. - The Python standard library is not, and will never be fully comprehensive -- most projects require *some* third party packages. - There are a LOT of packages available on PyPi -- with a very wide range of usefulness, quality and maintenance -- everything from widely used packages with a huge community (e.g. numpy) to packages that are release 0.0.1, and never seen an update, and may not even work. So the odds that there's a package that does what you need are good, but it can be pretty hard to find them sometimes -- and can be a fair bit of work to sift through to find the good ones -- and many folks don't feel qualified to do so. This can result in two opposite consequences: 1) People using a package that really isn't reliable or maintained (or not supported on all platforms, or ..) and getting stuck with it (I've had that on some of my projects -- I'm pretty careful, but not everyone on my team is) 2) People writing their own code - wasting time, and maybe not getting a very good solution either. I've also had that problem on my projects... To avoid this -- SOME way for folks to find packages that have at least has some level of vetting would be good -- exactly what level of vetting, is a very open question, but I think "even a little" could be very helpful. A few ideas that have come up in the previous thread -- more or less in order of level of effort. 1) A "clearing house" of package reviews, for lack of a better word -- a single web site that would point to various resources on the internet -- blog posts, etc, that would help people select packages. So one might go to the "JSON: section, and find links to some of the comparisons of JSON parsers, to help you choose. The authors of this site could even solicit folks to write reviews, etc that they could then point to. Chris A: this is my interpretation of your decentralized idea -- please do correct me if I got it wrong. 2) A Python package review site. This could be setup and managed with, e.g. a gitHub repo, so that there could be a small number of editors, but anyone could contribute a review via PR. The ultimiate goal would be reviews/recommendations of all the major package categories on PyPi. If well structured and searchable, this could be very useful. - This was proposed by someone on the previous thread -- again, correct me if I'm wrong. 3) A rating system built into PyPi -- This could be a combination of two things: A - Automated analysis -- download stats, dependency stats, release frequency, etc, etc, etc. B - Community ratings -- upvotes. stars, whatever. If done well, that could be very useful -- search on PyPi listed by rating. However -- :done well" ios a huge challenge -- I don't think there's a way to do the automated system right, and community scoring can be abused pretty easily. But maybe folks smarter than me could make it work with one or both of these approaches. 4) A self contained repository of packages that you could point pip to -- it would contain only the packages that had met some sort of "vetting" criteria. In theory, anyone could run it, but a stamp of approval from the PSF would make it far more acceptable to people. This would be a LOT of work to get set up, and still a lot of work to maintain. Personally, I think (4) is the best end result, but probably the most work as well[*], so ??? (1) and (2) have the advantage that they could be useful even without being comprehensive -- tthey's need to have some critical mass to get any traction, but maybe not THAT much. Anyway, I'd love to hear your thoughts on these ideas (or others?) - both technical and social. And of course, if anyone wants to join forces on getting something going. -CHB [*] maybe not, actually -- once the infrastructure was in place, adding a package would require someone requesting that it be added, and someone on a "core team" approving it. That could be a pretty low level of effort, actually. The actual mechanism would be to simply copy it from PyPi once approved -- not that hard to automate. hmmm.... Probably the biggest challenge would be coming up with the criteria for approval -- not an easy question. And it would require substantial critical mass to be at all useful. -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

12 45

Proposal for get_or function in Python dictionaries
by Jothir Adithyan 24 Jul '23

24 Jul '23

Hi everyone, I would like to briefly present my idea regarding the `get` function commonly used with dictionaries. When working with large amounts of JSON data, I often encounter code that doesn't feel very Pythonic to me. Problem Statement: The `get` function allows chaining of method calls, which is quite useful when working with dictionaries. It also has a convenient `default` parameter that returns a default value if the key is not found in the dictionary. This feature makes it safe and easy to use. However, problems arise when the dictionary contains the key we are accessing, but the corresponding value is `None`. In such cases, subsequent `get` calls fail because the `get` method belongs to objects of type `dict` and not `None`. To address this, I propose adding a new parameter to the `get` function or introducing a new function called `get_or` that swiftly handles this issue. This new parameter, called `arbitrary`, would accept an arbitrary value to be returned by subsequent `get` calls in case the retrieved value of the key is `None`. Assumptions: The problem statement is based on a few assumptions: - You prefer chaining `get` statements for cleaner code. - You expect at least some of the `get` methods to return `None`. - You want to avoid the hassle of using `try` and `except` for every `get` chain. If you fall into the category of people who wish for a simpler way to work with dictionaries and handle large amounts of data, I hope you can empathise with this proposal. I have made a simple implementation by modifying the `get` method, which is below this thread. I would appreciate your valuable input on this feature. Before diving into coding, I want to make sure this is not a bad idea waiting to reveal itself in the dark. Thank you for taking the time to read this thread. Your feedback is greatly appreciated. Best regards, Jothir Adithyan **Runnable Version** https://replit.com/@Adithyan71/GetOr **Code Samples.** ``` class PlayDict(dict): def get_or(self, key, arbitrary=None, default=None): if not self.__contains__( key ): # case 1 the key does not exist hence the default value return default elif ( self[key] is None ): # case 2 key does exist but the value is None return the arb value return arbitrary return self[key] # case 3 the key is present and the value is not None import contextlib parent_dict = PlayDict() parent_dict['k1'] = None parent_dict['k2'] = {"child_key": "val"} # Parent dict can contain nested dicts with contextlib.suppress(AttributeError): result = parent_dict.get("k1", {}).get("child_key") # This will raise AttributeError result = parent_dict.get_or("k1", default={}, arbitrary={}).get("child_key") # This will work print(result) ```

14 62

PEP 671 (late-bound arg defaults), next round of discussion!
by Chris Angelico 23 Jul '23

23 Jul '23

I've just updated PEP 671 https://www.python.org/dev/peps/pep-0671/ with some additional information about the reference implementation, and some clarifications elsewhere. *PEP 671: Syntax for late-bound function argument defaults* Questions, for you all: 1) If this feature existed in Python 3.11 exactly as described, would you use it? 2) Independently: Is the syntactic distinction between "=" and "=>" a cognitive burden? (It's absolutely valid to say "yes" and "yes", and feel free to say which of those pulls is the stronger one.) 3) If "yes" to question 1, would you use it for any/all of (a) mutable defaults, (b) referencing things that might have changed, (c) referencing other arguments, (d) something else? 4) If "no" to question 1, is there some other spelling or other small change that WOULD mean you would use it? (Some examples in the PEP.) 5) Do you know how to compile CPython from source, and would you be willing to try this out? Please? :) I'd love to hear, also, from anyone's friends/family who know a bit of Python but haven't been involved in this discussion. If late-bound defaults "just make sense" to people, that would be highly informative. Any and all comments welcomed. I mean, this is python-ideas after all... bikeshedding is what we do best! The reference implementation currently has some test failures, which I'm looking into. I'm probably going to make this my personal default Python interpreter for a while, to see how things go. ChrisA

43 364

Re: Conditional 1-line expression in python (Dom Grigonis)
by Laurent Lyaudet 18 Jul '23

18 Jul '23

Hello all, Please Dom Grigonis add choices : - "No preference" choice to first question - "I don't know" or "I can't tell" to third question And I will answer to your poll and probably other people will feel and do the same. I agree that question 2 makes me prefer C syntax. But C is not the nicest syntax in my point of view. In MySQL SQL, there is IF(condition, if_result, else_result) which I find nice. Moreover, it fits well with black style of formatting: foo_var = IF( this_is_a very_long_condition_expression_which_may_have_nested_parts, this_is_a very_long_if_result_expression_which_may_have_nested_parts, this_is_a very_long_else_result_expression_which_may_have_nested_parts, ) to compare with : foo_var = ( this_is_a very_long_condition_expression_which_may_have_nested_parts, ? this_is_a very_long_if_result_expression_which_may_have_nested_parts, : this_is_a very_long_else_result_expression_which_may_have_nested_parts, ) I can enjoy both, but I prefer the SQL apart from the fact that "IF" keyword would be ambiguous. I also enjoy very much : foo_var = CASE WHEN condition THEN if_result WHEN condition2 THEN elif_result ELSE else_result END from SQL. And CASE is not a reserved keyword and WHEN, THEN, ELSE could have specific meaning inside of case. Truly, I would enjoy the following syntax for Python à la black : foo_var = case( when condition then if_result when condition2 then elif_result else else_result ) or even more concise and still readable : foo_var = case( condition : if_result, condition2 : elif_result, else_result, ) Best regards, Laurent Lyaudet Le lun. 17 juil. 2023 à 22:42, <python-ideas-request(a)python.org> a écrit : > > Message: 2 > Date: Mon, 17 Jul 2023 23:41:25 +0300 > From: Dom Grigonis <dom.grigonis(a)gmail.com> > Subject: [Python-ideas] Conditional 1-line expression in python > To: python-ideas <python-ideas(a)python.org> > Message-ID: <31303E8B-05A4-408B-AF4D-916F805B5966(a)gmail.com> > Content-Type: multipart/alternative; > boundary="Apple-Mail=_41C44739-410D-45EA-89FF-6E2F1AF86836" > > Hi everyone, > > I am not very keen on long discussions on such matter as I do not think there is much to discuss: there is no technical complexity in it and it doesn’t really change or introduce anything new. It is only a matter of opinion & style/design preferences with respect to logical order and brevity of a statement. > > So I thought, if anyone can be bothered on such question and instead of writing 3-minute e-mail, would take few seconds to answer 3-question poll. > > https://q5yitzu62.supersurvey.com <https://q5yitzu62.supersurvey.com/> > > Would be interesting to see if my preference is an outlier or not really. > > > Kind regards, > D. Grigonis > > >

5 15

Double "at" operator for matmul exponentiation
by haael＠interia.pl 05 Jul '23

05 Jul '23

Python has the "star" ("*") operator for multiplication. In the context of collections it is supposed to mean element-wise multiplication. Its associated operator is __mul__. It also has the double star ("**") operator for exponentiation, which is repeated multiplication. Its associated operator is __exp__.In addition to that Python has the "at" ("@") operator for multiplication. In the context of collections it should mean linear product, like matrix times a matrix, or matrix times vector. Its associated method is __matmul__.For completeness we should now have the exponentiation operator meaning repeated application of the "at" operator. Its method could me __matexp__.

6 6

dict method to retrieve a key from a value
by Andre Delfino 04 Jul '23

04 Jul '23

A dict method to retrieve the key of a value from a bijective dict would have come in handy to me in several occasions: >>> names = {'one': 1} >>> names.inverse()[1] 'one' >>> names = {'one': 1, 'uno': 1} >>> names.inverse()[1] ValueError: dict is not bijective My usual use case is when both keys and values have simple types like int/str, like: { 'account-a': 123, 'account-b': 456, } Users may enter the account name, or the ID. The system works with the account ID (translating from the account name if needed), but when it needs to mention the account to the user, it shows the account name instead. I do understand that retrieval wouldn't be O(1).

8 33