Mailman 3 April 2022 - Python-ideas

Re: mro and super don't feel so pythonic
by Matsuoka Takuo April 13, 2022

April 13, 2022

On Wed, 13 Apr 2022 at 15:02, Ganesh B <ganeshsurfs(a)gmail.com> wrote: > > I hope nicer on the code text please. Sure. Sorry about that. malmiteria's "lib" code is ``` class HighGobelin: def scream(self): print("raAaaaAar") class CorruptedGobelin(HighGobelin): def scream(self): print("my corrupted soul makes me wanna scream") super().scream() class ProudGobelin(HighGobelin): def scream(self): print("I ... can't ... contain my scream!") super().scream() ``` Best regards, Takuo Matsuoka > > On Wed, Apr 13, 2022 at 9:21 AM Matsuoka Takuo <motogeomtop(a)gmail.com> wrote: >> >> On Wed, 13 Apr 2022 at 04:28, malmiteria <martin.milon(a)ensc.fr> wrote: >> > >> > Idk, what do you think? >> >> I would need to see more examples to determine the limit of the >> current strategy for method resolution and super. For the example at >> hand, I can be happy with the following code as a lib user (using your >> lib code). >> >> ``` >> class Proud_base(HighGobelin): >> scream = HighGobelin.scream >> >> class ProudGobelin_floating(ProudGobelin, Proud_base): >> pass >> >> class HalfBreed(ProudGobelin_floating, CorrupteGobelin): >> def scream(self): >> if random.choices([True, False]): >> super(HalfBreed, self).scream() >> else: >> super(Proud_base, self).scream() >> ``` >> >> Best regards, >> Takuo >> _______________________________________________ >> Python-ideas mailing list -- python-ideas(a)python.org >> To unsubscribe send an email to python-ideas-leave(a)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/K63MS… >> Code of Conduct: http://python.org/psf/codeofconduct/

1 0

Native support for units [was: custom literals]
by Ethan Furman April 12, 2022

April 12, 2022

On 4/3/22 11:52, Brian McCall wrote: > If you had asked me twenty years ago if I thought units should be a native part of any > programming language, I would have said absolutely - because in my youthful ignorance > I had no idea what it would take to make such a thing work. Five years later, I would > have said "not worth it". Now I'm back where I started. The lack of native language > support for SI units is a problem for an entire segment of programmers. Programming > languages took a big step forward in deciding that EVERYTHING is a pointer/reference, > and EVERYTHING is an object. They need to take another step forward to say that EVERY > number has a unit, including "unitless". Not having this language feature is becoming > (or already is) a problem. The question is, is it Python's problem? On 4/3/22 14:20, Ricky Teachey wrote: > The libraries out there- pint is probably the biggest one- have filled those gap as much as they can, but there are so > many shortfalls... > > The old engineering disciplines- mine (civil engineering), structural, electrical, etc- are the next frontier in the > "software eats the world" revolution, and they desperately need a language with native units support. I was just on an > interview call yesterday for a senior engineer role at a large multinational earth works engineering firm and we spent > 15 minutes talking about software and what we see coming down the road when it comes to the need for our discipline to > grow in its software creation capabilities. > > Python SHOULD be that language we do this with. It is awesome in every other way. But if it isn't DEAD SIMPLE to use > units in python, it won't happen. Well, if we're spit-balling ideas, what about: 63_lbs or 77_km/hr ? Variables cannot start with a number, so there'd be no ambiguity there; we started allowing underbars for separating digits a few versions ago, so there is some precedent. We could use the asterisk, although I find the underbar easeir to read. Mechanically, are `lbs`, `km`, `hr`, etc., something that is imported, or are they tags attached to the numbers? If attached to the numbers, memory size would increase and performance might decrease -- but, how often do we have a number that is truly without a unit? How old are you? 35 years How much do you weigh? 300 kg What temperature do you cook bread at? 350 F -- ~Ethan~

20 123

Custom literals, a la C++
by Will Bradley April 12, 2022

April 12, 2022

C++ has custom literal syntax <https://en.cppreference.com/w/cpp/language/user_literal>. I couldn't find a PEP on the subject— has this been considered and rejected, or is there a reason it's unpopular?

14 54

Giving Decimal a global context was a mistake?
by Mark Dickinson April 8, 2022

April 8, 2022

Broken off from the "Custom literals, a la C++" thread: Greg Ewing wrote: >Personally I think giving Decimal a global context was a mistake, [...] > so arguing that "it's no worse than Decimal" isn't going to do much > to convince me. :-) I'd be curious to know what alternatives you see. When a user writes `x + y` with both `x` and `y` instances of `decimal.Decimal`, the decimal module needs to know what precision to compute the result to (as well as what rounding mode to use, etc.). Absent a thread-local context or task-local context, where would that precision information come from?

9 26

An unambiguous way of initializing an empty set and dictionary
by joao.p.f.batista.97＠gmail.com April 6, 2022

April 6, 2022

Currently: l = [] # new empty list t = () # new empty tuple s = set() # new empty set (no clean and consistent way of initializing regarding the others) <<< d = {} # new empty dictionary Possible solution: s = {} # new empty set d = {:} # new empty dictionary (the ":" is a reference to key-value pairs) Current workaround at least for consistency: l = list() # new empty list t = tuple() # new empty tuple s = set() # new empty set d = dict() # new empty dictionary However, it doesn't feel right to not be able to initialize an empty set as cleanly and consistently as lists, tuples and dictionaries in both forms.

8 12

Allow os.getenv to optionally convert result to boolean
by Adrian Torres Justo April 6, 2022

April 6, 2022

We've used a lot of boolean environment variables in a recent project I've been working on, this led us to create a wrapper to os.getenv that essentially converts the result to a boolean using distutils.util.strtobool if an optional kwarg to our wrapper is set to True. Would it be far-fetched to have os.getenv incorporate this functionality? We already have the building blocks (strtobool and getenv), and the signature change would be minimal and backwards-compatible: def getenv(key, default=None, to_bool=False): ... The implementation would be trivial too. Let me know what you think, thanks! Adrian

5 9

Re: Native support for units [was: custom literals]
by Chris Angelico April 6, 2022

April 6, 2022

On Tue, 5 Apr 2022 at 03:58, Marco Sulla <Marco.Sulla.Python(a)gmail.com> wrote: > > On Mon, 4 Apr 2022 at 07:47, Chris Angelico <rosuav(a)gmail.com> wrote: > > > > Not a particle physicist, so I don't know what the usage actually is, > > but wouldn't mass actually be eV/c²? If that's frequently written as > > simply "eV", then that's another example of common non-SI usage that > > really should be supportable, but only within its context. > > Brian probably referred to a geometrized unit system, where the speed > of light c is set to one. This is very common in particle physics, it > simplifies the formulas. Also other quantities are usually set to 1, > as the charge of the electron etc. Not sure what you mean by "geometrized", but that would be the same concept as referring to "natural units", wouldn't it? In any case: the speed of light might be 1, but it's still 1 distance divided by 1 time. > That said, it's clear that a unit system is much more complicated > than, for example, a timezone support. A task that many languages > delegate to third party libraries, because it's a huge task, it's > specialized and... it's boring. Timezone support is a pretty big nightmare too :) ChrisA

4 11

Less is more? Smaller code and data to fit more into the CPU cache?
by Jonathan Fine April 5, 2022

April 5, 2022

Hi As you may have seen, AMD has recently announced CPUs that have much larger L3 caches. Does anyone know of any work that's been done to research or make critical Python code and data smaller so that more of it fits in the CPU cache? I'm particularly interested in measured benefits. This search https://www.google.com/search?q=python+performance+CPU+cache+size provides two relevant links https://www.oreilly.com/library/view/high-performance-python/9781449361747/… https://www.dlr.de/sc/Portaldata/15/Resources/dokumente/pyhpc2016/slides/Py… but not much else I found relevant. AnandTech writes about the chips with triple the L3 cache: https://www.anandtech.com/show/17323/amd-releases-milan-x-cpus-with-3d-vcac… "As with other chips that incorporate larger caches, the greatest benefits are going to be found in workloads that spill out of contemporary-sized caches, but will neatly fit into the larger cache." And also: https://www.anandtech.com/show/17313/ryzen-7-5800x3d-launches-april-20th-pl… " As detailed by the company back at CES 2022 and reiterated in today’s announcement, AMD has found that the chip is 15% faster at gaming than their Ryzen 9 5900X." I already know that using Non Uniform Memory Access (NUMA) raises the difficult problem of cache coherence. https://en.wikipedia.org/wiki/Non-uniform_memory_access https://en.wikipedia.org/wiki/Cache_coherence -- Jonathan

5 6

Syntax proposal of for..in..if in regular for loops
by Svein Seldal April 4, 2022

April 4, 2022

I'm sorry for reposting, but this message got stuck in moderation approval for 5 days so I figured I should try again. I'd like to propose extending the for statement to include conditionals akin to comprehensions in order to simplify for loop statements: `for .. in .. if ..:` E.g. for x in y if x in c: some_op(x) which is functionally equivalent as for x in y: if x not in c: continue some_op(x) The `for .. in .. if` syntax is a well-known construct from list comprehension syntax [1]. Other alternative ways to do this with list comprehension is: for x in (a for a in y if c): or it = (a for a in y if c) for x in it: Without having examined all use cases, I believe the same syntax should be applied this syntax as for asynchronous comprehensions. [1] PEP 202 - List Comprehensions [2] PEP 530 - Asynchronous Comprehensions Best regards, Svein Seldal

20 65

Config file template motivation for PEP 463 or an update to format string spec
by brian.patrick.mccall＠gmail.com April 2, 2022

April 2, 2022

One way that I like to create templates for config files is to write the config file in a way that can be used with `str.format` if I read in the entire config file as a string before re-saving it or sending it somewhere.* The config file contains a half dozen or dozen variables. Another several dozen variables are pretty much permanent. This approach works for me in the sense that batch submits over several combinations of variables is just a few lines of code, and when I revisit a job after quite some time, the curly braces in the config file template remind me what settings (might) require my attention. The problem lies in what to do about defaults. Including a formatted variable in the template file requires that the variable be included in my call to `format` otherwise I'll get a `KeyError`. For my part, I can work around this by including a companion '.py' file that includes a `dict` of default values. What I pine for is the ability to discard this extra '.py' file, and its WYSINWYG heresy by enabling a way to enable defaults in the processing of formatted strings. One such way would be to modify the format string spec. I am not sure how this might be done, so I cannot make a smart proposal on that one. Another way, although it might not be the most popular, is to allow for inline exception handling of the sort proposed in PEP 463. To me, the following does not look so bad: Config file: ``` ... BAUD: {baud except 9600} ... ``` Template updating code snippets: ``` with open('config.yaml', 'r') as f: txt = f.read() options = {'baud': 19200} new_txt1 = txt.format(options) # BAUD: 19200 is now in new_txt1 options = {} new_txt2 = txt.format(options) # BAUD: 9600 is now in new_txt2 ``` Curious to know anyone's thoughts on the subject, particularly anyone else who is in the habit of hastily writing config files. Apologies if bringing up a rejected PEP on my first thread causes any irritation, but I swear I would not have done it if string formatting weren't so useful. I thank you for my cookie and now I would like some milk. * - I'm aware that there can be security risks in this approach, but I am working in a walled off system (not public) where it is unlikely that I or anyone else can do much damage even if we wanted to.

5 4