[Python-ideas] Re: Adding a "once" function to functools
On Tue, Apr 28, 2020 at 11:45:49AM -0700, Raymond Hettinger wrote: > It seems like you would get just about everything you want with one line: > > once = lru_cache(maxsize=None) But is it thread-safe? If you have a "once"ed expensive function with side-effects, and a second thread calls it before the first thread's initial call has completed, won't you end up executing the function twice? The documentation doesn't mention anything about thread-safety: https://docs.python.org/3/library/functools.html#functools.lru_cache -- 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/PR6CS6BMJV4YGXG7MER6OU2KWR6OCOVB/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding a "once" function to functools
On Apr 28, 2020, at 12:02, Alex Hall wrote: > > Some libraries implement a 'lazy object' which forwards all operations to a > wrapped object, which gets lazily initialised once: > > https://github.com/ionelmc/python-lazy-object-proxy > https://docs.djangoproject.com/en/3.0/_modules/django/utils/functional/ > > There's also a more general concept of proxying everything to some target. > wrapt provides ObjectProxy which is the simplest case, the idea being that > you override specific operations: > > https://wrapt.readthedocs.io/en/latest/wrappers.html > > Flask and werkzeug provide proxies which forward based on the request being > handled, e.g. which thread or greenlet you're in, which allows magic like the > global request object: > > https://flask.palletsprojects.com/en/1.1.x/api/#flask.request > > All of these have messy looking implementations and hairy edge cases. I > imagine the language could be changed to make this kind of thing easier, more > robust, and more performant. But I'm struggling to formulate what exactly > "this kind of thing is", i.e. what feature the language could use. For the case where you’re trying to do the “singleton pattern” for a complex object whose behavior is all about calling specific methods, a proxy might work, and the only thing Python might need, if anything, is ways to make it possible/easier to write a GenericProxy that just delegates everything in some clean way, but even that isn’t really needed if you’re willing to make the proxy specific to the type you’re singleton-ing. But often what you want to lazily initialize is a simple object—a str, a small integer, a list of str, etc. Guido’s example lazily initialized by calling getcwd(), and the first example given for the Swift feature is usually a fullname string built on demand from firstname and lastname. And if you look for examples of @cachedproperty (which really is exactly what you want for @lazy except that it only works for instance attributes, and you want it for class attributes or globals), the singleton pattern seems to be a notable exception, not the usual case; mostly you lazily initialize either simple objects like a str, a pair of floats, a list of int, etc., or numpy/pandas objects. And you can’t proxy either of those in Python. Especially str. Proxies work by duck-typing as the target, but you can’t duck-type as a str, because most builtin and extension functions that want a str ignore its methods and use the PyUnicode API to get directly at its array of characters. Numbers, lists, numpy arrays, etc. aren’t quite as bad as str, but they still have problems. Also, even when it works, the performance cost of a proxy would often be prohibitive. If you write this: @lazy def fullname(): return firstname + " " + lastname … presumably it’s because you need to eliminate the cost of string concatenation every time you need the fullname. But if it then requires every operation on that fullname to go through a dynamic proxy, you’ve probably added more overhead than you saved. So I don’t think proxies are the answer here. Really, we either need descriptors that can somehow work for globals and class attributes (which is probably not solveable), or some brand new language semantics that aren’t built on what’s already there. The latter sounds like probably way more work than this feature deserves, but maybe the experience of Swift argues otherwise. ___ 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/OGCFXBYXPT7AVJQLSW3HTNBP7SJJ7A5B/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding a "once" function to functools
Some libraries implement a 'lazy object' which forwards all operations to a wrapped object, which gets lazily initialised once: https://github.com/ionelmc/python-lazy-object-proxy https://docs.djangoproject.com/en/3.0/_modules/django/utils/functional/ There's also a more general concept of proxying everything to some target. wrapt provides ObjectProxy which is the simplest case, the idea being that you override specific operations: https://wrapt.readthedocs.io/en/latest/wrappers.html Flask and werkzeug provide proxies which forward based on the request being handled, e.g. which thread or greenlet you're in, which allows magic like the global request object: https://flask.palletsprojects.com/en/1.1.x/api/#flask.request All of these have messy looking implementations and hairy edge cases. I imagine the language could be changed to make this kind of thing easier, more robust, and more performant. But I'm struggling to formulate what exactly "this kind of thing is", i.e. what feature the language could use. On Tue, Apr 28, 2020 at 8:02 PM Andrew Barnert via Python-ideas < python-ideas@python.org> wrote: > On Apr 26, 2020, at 10:41, Guido van Rossum wrote: > > > > > > Since the function has no parameters and is pre-computed, why force all > users to *call* it? The @once decorator could just return the value of > calling the function: > > > > def once(func): > > return func() > > > > @once > > def pwd(): > > return os.getcwd() > > If that’s all @once does, you don’t need it. Surely this is even clearer: > > pwd = os.getcwd() > > The decorator has to add initialization on first demand, or it’s not doing > anything. > > But I think you’re onto something important that everyone else is missing. > To the user of this module, this really should look like a variable, not a > function. The fact that we want to initialize it later shouldn’t change > that. Especially not in Python—other languages bend over backward to make > you write getters around every public attribute even when you don’t need > any computation; Python bends over backward to let you expose public > attributes even when you do need computation. > > And this isn’t unprecedented. Swift added a lazy variable initialization > feature in version 2 even though they already had dispatch_once. And then > they discovered that it eliminated nearly all good uses of dispatch_once > and deprecated it. All you need is lazy-initialized variables. Your > singletons, your possibly-unused expensive tables, your fiddly low-level > things with complicated initialization order dependencies, they’re all lazy > variables. So what’s left for @once functions that need to look like > functions? > > I think once you think about it in these terms, @lazy makes more sense > than @once. The difference between these special attributes and normal ones > is that they’re initialized on first demand rather than at definition time. > The “on demand” is the salient bit, not the “first”. > > The only problem is: how could this be implemented? Most of the time you > want these things on modules. For lazy imports, the __getattr__ solution of > PEP 562 was good enough, but this isn’t nearly as much of an expert > feature. Novices write lazy variables in Swift, and if we have to tell them > they can’t do it in Python without learning the deep magic of how variable > lookup works, that would be a major shame. But I can’t think of an answer > that doesn’t run into all the same problems that PEP 562’s competing > protocols did. > ___ > 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/GHDFHZ46QAIMKRGACESWG6XX4FPPLZIN/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ 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/IENZZGLLPZXE7VEDJKOX3RLDEYRVGVHL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding a "once" function to functools
> On Apr 26, 2020, at 7:03 AM, Tom Forbes wrote:
>
> I would like to suggest adding a simple “once” method to functools. As the
> name suggests, this would be a decorator that would call the decorated
> function, cache the result and return it with subsequent calls.
It seems like you would get just about everything you want with one line:
once = lru_cache(maxsize=None)
which would be used like this:
@once
def welcome():
len('hello')
> Using lru_cache like this works but it’s not as efficient as it could be - in
> every case you’re adding lru_cache overhead despite not requiring it.
You're likely imagining more overhead than there actually is. Used as shown
above, the lru_cache() is astonishingly small and efficient. Access time is
slightly cheaper than writing d[()] where d={(): some_constant}. The
infinite_lru_cache_wrapper() just makes a single dict lookup and returns the
value.¹ The lru_cache_make_key() function just increments the empty args tuple
and returns it.² And because it is a C object, calling it will be faster than
for a Python function that just returns a constant, "lambda: some_constant()".
This is very, very fast.
Raymond
¹ https://github.com/python/cpython/blob/master/Modules/_functoolsmodule.c#L870
² https://github.com/python/cpython/blob/master/Modules/_functoolsmodule.c#L809
___
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/VCWTMH6Z6ADAH5YKRQ6CU4ZIHLLBN4KQ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: extended for-else, extended continue, and a rant about zip()
On Apr 28, 2020, at 09:18, Chris Angelico wrote: > > I suggest forking CPython and implementing the feature. I’d suggest trying MacroPy first. There’s no way to get the desired syntax with macros, but at least at first glance it seems like you should be able to get the desired semantics with something that’s only kind of ugly and clumsy, rather than totally hideous. And if so, that’s usually good enough for playing around with fun ideas to see where they can lead, and a lot less work. Plus, playing with MacroPy is actually fun in itself; playing with the CPython parser is kind of the opposite of fun. :) ___ 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/SPTNT7DXUHVP32ZUZAC6HIYYWNEYDY4K/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding a "once" function to functools
On Apr 26, 2020, at 10:41, Guido van Rossum wrote: > > > Since the function has no parameters and is pre-computed, why force all users > to *call* it? The @once decorator could just return the value of calling the > function: > > def once(func): > return func() > > @once > def pwd(): > return os.getcwd() If that’s all @once does, you don’t need it. Surely this is even clearer: pwd = os.getcwd() The decorator has to add initialization on first demand, or it’s not doing anything. But I think you’re onto something important that everyone else is missing. To the user of this module, this really should look like a variable, not a function. The fact that we want to initialize it later shouldn’t change that. Especially not in Python—other languages bend over backward to make you write getters around every public attribute even when you don’t need any computation; Python bends over backward to let you expose public attributes even when you do need computation. And this isn’t unprecedented. Swift added a lazy variable initialization feature in version 2 even though they already had dispatch_once. And then they discovered that it eliminated nearly all good uses of dispatch_once and deprecated it. All you need is lazy-initialized variables. Your singletons, your possibly-unused expensive tables, your fiddly low-level things with complicated initialization order dependencies, they’re all lazy variables. So what’s left for @once functions that need to look like functions? I think once you think about it in these terms, @lazy makes more sense than @once. The difference between these special attributes and normal ones is that they’re initialized on first demand rather than at definition time. The “on demand” is the salient bit, not the “first”. The only problem is: how could this be implemented? Most of the time you want these things on modules. For lazy imports, the __getattr__ solution of PEP 562 was good enough, but this isn’t nearly as much of an expert feature. Novices write lazy variables in Swift, and if we have to tell them they can’t do it in Python without learning the deep magic of how variable lookup works, that would be a major shame. But I can’t think of an answer that doesn’t run into all the same problems that PEP 562’s competing protocols did. ___ 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/GHDFHZ46QAIMKRGACESWG6XX4FPPLZIN/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: extended for-else, extended continue, and a rant about zip()
On Wed, Apr 29, 2020 at 1:50 AM Soni L. wrote: > > > > On 2020-04-28 12:32 p.m., Edwin Zimmerman wrote: > > On April 28, 2020 9:38 AM Soni L. wrote: > > > On 2020-04-28 7:50 a.m., Edwin Zimmerman wrote: > > > > On 4/27/2020 11:47 PM, Soni L. wrote: > > > > [snip] > > > > > tbh my particular case doesn't make a ton of practical sense. I have > > > > > config files and there may be errors opening or > > deserializing > > > them, and I have a system to manage configs and overrides. which means > > > you can have multiple config files, and you may wanna log > > > errors. you can also use a config manager as a config file in another > > > config manager, which is where the error logging gets a bit > > weirder. > > > I'm currently returning lists of errors, but another option would be to > > > yield the errors instead. but, I'm actually not sure what > > the best > > > approach here is. so yeah. I can't *use* that motivating example, because > > > if I did, everyone would dismiss me as crazy. (which I > > am, > > > but please don't dismiss me based on that :/) > > > > > > > > > Maybe you could start by actually writing the code, and then > > > > demonstrate how your idea would make the code easier to read or > > > understand, or less error prone, or whatever other improvement it would > > > bring. > > > > > > that thing about wrapping things from other generators and returning the > > > number of generators I messed with? > > > > > > yeah. that's what I wanted to do. it doesn't do any of those things, > > > it's just fun. > > > > > > I think I will stop replying to this thread, since we aren't getting > > anywhere. Either I'm a poor communicator or someone else is a > > poor listener. Either way, my attempts to constructively approach this > > thread are failing. > > --Edwin > > > > this code: > > def foo(self): >for x in self.things: > for y in x.foo(): >yield Wrap(y) > else with z: >yield z >return len(things) > > this is what it'd look like. and it'd be fun. the point of it is to be > fun. it's a nuisance to actually use the results but if you're just > printing them out (which is what I'd do) it's fine. > > if you don't want me telling you, maybe don't ask. I suggest forking CPython and implementing the feature. If the entire value of it is so you can write "fun" code, then there's no reason to have it in the core language. 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/FM3USEMSLKGLUQUOVCSCJ5P6DIRHXDFR/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: extended for-else, extended continue, and a rant about zip()
On 2020-04-28 12:32 p.m., Edwin Zimmerman wrote: On April 28, 2020 9:38 AM Soni L. wrote: > On 2020-04-28 7:50 a.m., Edwin Zimmerman wrote: > > On 4/27/2020 11:47 PM, Soni L. wrote: > > [snip] > > > tbh my particular case doesn't make a ton of practical sense. I have config files and there may be errors opening or deserializing > them, and I have a system to manage configs and overrides. which means you can have multiple config files, and you may wanna log > errors. you can also use a config manager as a config file in another config manager, which is where the error logging gets a bit weirder. > I'm currently returning lists of errors, but another option would be to yield the errors instead. but, I'm actually not sure what the best > approach here is. so yeah. I can't *use* that motivating example, because if I did, everyone would dismiss me as crazy. (which I am, > but please don't dismiss me based on that :/) > > > > > Maybe you could start by actually writing the code, and then demonstrate how your idea would make the code easier to read or > understand, or less error prone, or whatever other improvement it would bring. > > that thing about wrapping things from other generators and returning the > number of generators I messed with? > > yeah. that's what I wanted to do. it doesn't do any of those things, > it's just fun. I think I will stop replying to this thread, since we aren't getting anywhere. Either I'm a poor communicator or someone else is a poor listener. Either way, my attempts to constructively approach this thread are failing. --Edwin this code: def foo(self): for x in self.things: for y in x.foo(): yield Wrap(y) else with z: yield z return len(things) this is what it'd look like. and it'd be fun. the point of it is to be fun. it's a nuisance to actually use the results but if you're just printing them out (which is what I'd do) it's fine. if you don't want me telling you, maybe don't ask. ___ 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/7LPHFR7WGB6WNFA77E3MGKSYABR3WTSX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: extended for-else, extended continue, and a rant about zip()
On April 28, 2020 9:38 AM Soni L. wrote: > On 2020-04-28 7:50 a.m., Edwin Zimmerman wrote: > > On 4/27/2020 11:47 PM, Soni L. wrote: > > [snip] > > > tbh my particular case doesn't make a ton of practical sense. I have > > > config files and there may be errors opening or deserializing > them, and I have a system to manage configs and overrides. which means you > can have multiple config files, and you may wanna log > errors. you can also use a config manager as a config file in another config > manager, which is where the error logging gets a bit weirder. > I'm currently returning lists of errors, but another option would be to yield > the errors instead. but, I'm actually not sure what the best > approach here is. so yeah. I can't *use* that motivating example, because if > I did, everyone would dismiss me as crazy. (which I am, > but please don't dismiss me based on that :/) > > > > > Maybe you could start by actually writing the code, and then demonstrate > > how your idea would make the code easier to read or > understand, or less error prone, or whatever other improvement it would bring. > > that thing about wrapping things from other generators and returning the > number of generators I messed with? > > yeah. that's what I wanted to do. it doesn't do any of those things, > it's just fun. I think I will stop replying to this thread, since we aren't getting anywhere. Either I'm a poor communicator or someone else is a poor listener. Either way, my attempts to constructively approach this thread are failing. --Edwin ___ 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/WUMIA4LMIT64Q6PZSWNTRFHMTDCDXXSV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On 28/04/2020 15:46, Brandt Bucher wrote: Thanks for weighing in, everybody. Over the course of the last week, it has become surprisingly clear that this change is controversial enough to require a PEP. With that in mind, I've started drafting one summarizing the discussion that took place here, and arguing for the addition of a boolean flag to the `zip` constructor. Antoine Pitrou has agreed to sponsor, and I've chatted with another core developer who shares my view that such a flag wouldn't violate Python's existing design philosophies. I'll be watching this thread, and should have a draft posted to the list for feedback this week. -1 on the flag. I'd be happy to have a separate zip_strict() (however you spell it), but behaviour switches just smell wrong. -- Rhodri James *-* Kynesim Ltd ___ 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/BZUJUTAVOHJEUZ6QEIRZWZHKCRXE6AAS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
Thanks for weighing in, everybody. Over the course of the last week, it has become surprisingly clear that this change is controversial enough to require a PEP. With that in mind, I've started drafting one summarizing the discussion that took place here, and arguing for the addition of a boolean flag to the `zip` constructor. Antoine Pitrou has agreed to sponsor, and I've chatted with another core developer who shares my view that such a flag wouldn't violate Python's existing design philosophies. I'll be watching this thread, and should have a draft posted to the list for feedback this week. Brandt ___ 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/MLMZQZMQ3GRQYZVOXXNMXHQNTHODD4CQ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: extended for-else, extended continue, and a rant about zip()
On 2020-04-28 7:50 a.m., Edwin Zimmerman wrote: On 4/27/2020 11:47 PM, Soni L. wrote: [snip] > tbh my particular case doesn't make a ton of practical sense. I have config files and there may be errors opening or deserializing them, and I have a system to manage configs and overrides. which means you can have multiple config files, and you may wanna log errors. you can also use a config manager as a config file in another config manager, which is where the error logging gets a bit weirder. I'm currently returning lists of errors, but another option would be to yield the errors instead. but, I'm actually not sure what the best approach here is. so yeah. I can't *use* that motivating example, because if I did, everyone would dismiss me as crazy. (which I am, but please don't dismiss me based on that :/) > Maybe you could start by actually writing the code, and then demonstrate how your idea would make the code easier to read or understand, or less error prone, or whatever other improvement it would bring. that thing about wrapping things from other generators and returning the number of generators I messed with? yeah. that's what I wanted to do. it doesn't do any of those things, it's just fun. ___ 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/PUTKHWMUUVLSMFK66LPM3DHBF4TFFFHM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: zip(x, y, z, strict=True)
On Mon, Apr 27, 2020 at 09:21:41AM -0700, Andrew Barnert wrote: > But this doesn’t do what the OP suggested; it’s a completely different > proposal. They wanted to write this: > > zipped = zip(xs, ys).skip() > > … and you’re offering this: > > zipped = zip.skip(xs, ys) > > That’s a decent proposal—arguably better than the one being > discussed—but it’s definitely not the same one. So he did. I misread his comment, sorry. Perhaps I read it as I would have written it rather than as he wrote it :-( [...] > Your design looks like a pretty good one at least at first glance, and > I think you should propose it seriously. You should be showing why > it’s better than adding methods to zip objects—and also better than > adding more functions to itertools or builtins, or flags to zip, or > doing nothing—not pretending it’s the same as one of those other > proposals and then trying to defend that other proposal by confusing > the problems with it. Last time I got volunteered into writing a PEP I wasn't in favour of, and (initially at least) thought I was writing to have the rejection reason documented, it ended up getting approved :-) -- 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/YFU2XWVZDNBP3EBGEKE7DYT3DVEUPAQO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding a "once" function to functools
Actually the draw examples made me think that possibly the @once, @run_once or whatever decorator should possibly add a reset method, as does the lru_cache cache_clear function. Taking the gunslinger draw example it would be: @once def draw(): """ Get your gun """ # Get your gun ... return gun def shoot(targets): for target in targets: gun_in_hand = draw() gun_in_hand.fire_at(target) This would speed up shooting nicely but you would have tied up a valuable resource but it would be really handy to have: def holster_gun(): """ Finished with gun for now """ draw.reset() One of the issues that newcomers to iterators suffer from is the fact that you need to delete and recreate them if you need to re-use them from the beginning however removing and redefining a function is much more complex. Steve Barnes -Original Message- From: Oleg Broytman Sent: 28 April 2020 10:05 To: python-ideas@python.org Subject: [Python-ideas] Re: Adding a "once" function to functools On Tue, Apr 28, 2020 at 10:19:49AM +0200, Antoine Pitrou wrote: > On Tue, 28 Apr 2020 11:04:15 +1000 > Steven D'Aprano wrote: > > > > Yes, it's annoying when English words can have two or more meanings. > > The first time I can across math.sin, I was very excited, until I > > realised it was just the trigonometric function :-( > > > > This is the gunslinger.draw versus the artist.draw problem. > > It should be solved by the random.draw solution (which calls one or > the other, randomly ;-)). But only once! :-D > Regards > > Antoine. Oleg. -- Oleg Broytmanhttps://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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/H35YNUJTP23BPXE2SLH7JXVFBJ6CWDAJ/ Code of Conduct: http://python.org/psf/codeofconduct/ ___ 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/FKOL6OVGEGFKK76RDMKGZK32JNIBS6DG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding a "once" function to functools
> On 28 Apr 2020, at 02:04, Steven D'Aprano wrote: > > Yes, it's annoying when English words can have two or more meanings. The > first time I can across math.sin, I was very excited, until I realised > it was just the trigonometric function :-( @once def my_func(): ... I read that as "at once define my func". That must mean do it now :-) Barry ___ 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/46UJW524XPSMVKQPYHQGSTAAX7GWCPWP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: extended for-else, extended continue, and a rant about zip()
On 4/27/2020 11:47 PM, Soni L. wrote: [snip] > tbh my particular case doesn't make a ton of practical sense. I have config > files and there may be errors opening or deserializing them, and I have a > system to manage configs and overrides. which means you can have multiple > config files, and you may wanna log errors. you can also use a config manager > as a config file in another config manager, which is where the error logging > gets a bit weirder. I'm currently returning lists of errors, but another > option would be to yield the errors instead. but, I'm actually not sure what > the best approach here is. so yeah. I can't *use* that motivating example, > because if I did, everyone would dismiss me as crazy. (which I am, but please > don't dismiss me based on that :/) > Maybe you could start by actually writing the code, and then demonstrate how your idea would make the code easier to read or understand, or less error prone, or whatever other improvement it would bring. ___ 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/LDC7PIA5B3NOTPF5KJFUZJVNHFC5/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding a "once" function to functools
On Tue, Apr 28, 2020 at 10:19:49AM +0200, Antoine Pitrou wrote: > On Tue, 28 Apr 2020 11:04:15 +1000 > Steven D'Aprano wrote: > > > > Yes, it's annoying when English words can have two or more meanings. The > > first time I can across math.sin, I was very excited, until I realised > > it was just the trigonometric function :-( > > > > This is the gunslinger.draw versus the artist.draw problem. > > It should be solved by the random.draw solution (which calls one > or the other, randomly ;-)). But only once! :-D > Regards > > Antoine. Oleg. -- Oleg Broytmanhttps://phdru.name/p...@phdru.name Programmers don't die, they just GOSUB without RETURN. ___ 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/H35YNUJTP23BPXE2SLH7JXVFBJ6CWDAJ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Adding a "once" function to functools
On Tue, 28 Apr 2020 11:04:15 +1000 Steven D'Aprano wrote: > > Yes, it's annoying when English words can have two or more meanings. The > first time I can across math.sin, I was very excited, until I realised > it was just the trigonometric function :-( > > This is the gunslinger.draw versus the artist.draw problem. It should be solved by the random.draw solution (which calls one or the other, randomly ;-)). Regards Antoine. ___ 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/2EN5FGGFAMZUF5OVNIJGV3WNZEGWWE4S/ Code of Conduct: http://python.org/psf/codeofconduct/
