floatref
in [Python]
|
Prev: Cross-platform module that creates directory object with allfile attributes
Next: death of newsgroups (Microsoft closing their newsgroups)
From: Steven D'Aprano on 14 Jul 2010 00:31 On Wed, 14 Jul 2010 03:19:36 +0200, Alf P. Steinbach /Usenet wrote: > Gary Herron wrote: >> Python does not have pointers, so if I take your wording"y.var and >> x.var to point to the same value" literally, then the answer is NO >> Python does not do that. > > This is just a terminological issue. "Just"? If people can't agree on terminology, they can't even understand each other, let alone communicate effectively. If I call you a fine fellow with a detailed grasp of programming and a helpful manner, but what I mean by "fine", "detailed" and "helpful" are different from what you mean by them, how can you tell if I've just complimented you or insulted you? Gary did the right thing by pointing out that the simple-sounding term "points to" is anything but simple, it depends on what you mean by pointing and pointers. > Saying "Python does not have > pointers" is highly misleading in response to the OP's statement. It's > easy enough to understand what he means. E.g., in the Java language > specification "pointer" has a suitable meaning. And in a Java language forum, that would arguably be the right meaning to assume. Possibly even in a Jython forum. But this is neither, it's a Python forum, where "Python" is typically understood to be CPython, not Jython and certainly not Java, and "pointer" is typically understood to mean C or Pascal pointers. In an English language forum, the correct meaning to use for "cafeteria" is a "dining hall", and not "fringe benefit" as it would be in a Hungarian forum. Likewise, the correct meaning to use for the word "gift" in an English forum is a present or object which is given, and not "poison" as a German might assume. [...] > You can't represent or usefully think of a C++ member pointer > as a C or Pascal pointer. It isn't useful on its own. So, considering > C++ and Java, the general pointer notion is something that refers, > however obliquely. So an integer like 3 counts as a pointer, as you can use it as an index into a list, array or other sequence. In that sense, yes, Python has pointers, and makes frequent use of them. You can even do pointer arithmetic! I don't think this position is terribly useful. It's possible to be *too* generic. > You chose a specific meaning of "pointer" where the > OP's statement does not make sense, but presumably the OP is explaining > his needs in terms of a more general meaning of "pointer"; assuming > anything else is silly. The Zen of Python includes: In the face of ambiguity, refuse the temptation to guess. Wise words, not just for programming. -- Steven
From: Alf P. Steinbach /Usenet on 14 Jul 2010 00:50 * Steven D'Aprano, on 14.07.2010 06:31: > > Gary did the right thing by pointing out that the simple-sounding term > "points to" is anything but simple, it depends on what you mean by > pointing and pointers. Possibly you have a point here. Cheers, - Alf -- blog at <url: http://alfps.wordpress.com>
From: Steven D'Aprano on 14 Jul 2010 01:05 On Wed, 14 Jul 2010 06:50:58 +0200, Alf P. Steinbach /Usenet wrote: > Possibly you have a point here. Oh yeah? Don't think you can escape a flame war by agreeing with me! *wink* -- Steven
From: Roald de Vries on 14 Jul 2010 03:56 On Jul 14, 2010, at 1:26 AM, Gary Herron wrote: > On 07/13/2010 03:02 PM, Roald de Vries wrote: >> Hi Gary, >> >> On Jul 13, 2010, at 8:54 PM, Gary Herron wrote: >>> On 07/13/2010 10:26 AM, Roald de Vries wrote: >>>> Hi all, >>>> >>>> I have two objects that should both be able to alter a shared >>>> float. >>>> So i need something like a mutable float object, or a float >>>> reference >>>> object. Does anybody know if something like that exists? I know >>>> it's >>>> not hard to build, but I have a feeling that there should be a >>>> standard solution to it. >>>> >>>> Roald >>> >>> Huh? I must be missing something here. Isn't this what you use a >>> variable for: >> >> Maybe I didn't explain well: >> >> >>> shared_var = 1.0 >> >>> x.var = shared_var >> >>> y.var = shared_var >> >>> x.var = 2.0 >> >>> y.var >> 1.0 >> >> I wanted y.var and x.var to point to the same value, so that always >> x.var == y.var. So that the last line becomes: >> >> >>> y.var >> 2.0 >> >> Cheers, Roald > > Please keep responses and further discussions on > list.python-list(a)python.org > instead of using private emails. Sorry. > Python does not have pointers, so if I take your wording"y.var and > x.var to point to the same value" literally, then the answer is NO > Python does not do that. Maybe I should have put it between quotes, but I used the words 'mutable float' and 'float reference' in the original post, and this was only an attempt to clarify better. > However, Python does have references all over the place, so you can > achieve something similar in many ways. I know, I just wondered if there is a *standard* solution. Cheers, Roald
From: Roald de Vries on 14 Jul 2010 04:11
On Jul 14, 2010, at 3:53 AM, Steven D'Aprano wrote: > On Tue, 13 Jul 2010 19:26:34 +0200, Roald de Vries wrote: > >> Hi all, >> >> I have two objects that should both be able to alter a shared >> float. So >> i need something like a mutable float object, or a float reference >> object. Does anybody know if something like that exists? I know >> it's not >> hard to build, but I have a feeling that there should be a standard >> solution to it. > > > One standard solution would be to wrap the float in a class as an > attribute. E.g.: a class FloatWrapper with a get and set method. Advantages: transparent, easy to implement Disadvantages: for 'f = FloatWrapper' you have to use 'f.set(1.0)' instead of 'f = 1.0', which reads less easily (I think), and a mistake like assigning with 'f = 1.0' is easily made. > Another is to put it in a list: > > myvalue = [3.1415] > pi = myvalue > myvalue[0] = 3.0 > assert pi[0] == 3.0 I thought about something like that, but it's a bit misleading, because the value is actually a list. > An even better solution is to avoid the idiom of shared state in the > first place. Whenever people say "I need shared data", the chances are > very good that they don't *need* it at all, but merely *want* it > because > that's the idiom they're used to. I want to simulate a distributed algorithm, in which components can only communicate through shared state. Cheers, Roald |