Re: A question on modification of a list via a function invocation
On Sat, 9 Sep 2017 10:34 am, Gregory Ewing wrote: > Steve D'Aprano wrote: >> The paradox of the axe is one illustration of the difficulty in defining "the >> same" in full generality. > > The axe situation doesn't arise in Python, because "same > object" in Python is a concept that only applies to objects > existing at the same time. Indeed. That's why in an earlier post I mentioned that it wasn't relevant to the question of `is`. I only mentioned it again because Rustom claimed to not understand why I mentioned it. I mentioned it because I was *agreeing with him* about the notion of sameness being hard to define vigorously in FULL GENERALITY. Which is irrelevant to the question of "same object". Either the paradoxes of "sameness" don't apply to Python objects, in which the paradoxes don't matter, or they apply to everything, in which case we're stuck with them and shouldn't let them prevent us using the common sense meaning of "same object" when discussing Python `is`. > There's no way to even ask a question like "does a refer > to the same object that b did a second ago", because > the only way to test object identity is to use the > 'is' operator, which takes two expressions evaluated > at the same time. I wouldn't quite go that far. We could, for example, record the ID, type, and some representation of the object (repr? str?), and compare them to those of the existing object. If any of them differ, then we know they aren't (weren't?) the same object. If all three are the same, we cannot draw any conclusions. "Is this list I have now identical to the tuple I had five minutes ago?" "Obviously not, because lists aren't tuples." But apart from tricks like that, I agree: objects that existed in the past but no longer exist don't have a meaningful identity in Python. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Steve D'Aprano wrote: The paradox of the axe is one illustration of the difficulty in defining "the same" in full generality. The axe situation doesn't arise in Python, because "same object" in Python is a concept that only applies to objects existing at the same time. There's no way to even ask a question like "does a refer to the same object that b did a second ago", because the only way to test object identity is to use the 'is' operator, which takes two expressions evaluated at the same time. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Steve D'Aprano wrote: I don't think that talking about the average integer is meaningful. We're not averaging the integers, we're averaging their numbers of digits, which are natural numbers. To do this rigorously you could write down an expression for the average length of integers up to some finite N, and then take the limit as N -> infinity. I haven't worked through that, but I'd expect the sum to diverge. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On 9/8/17, Gregory Ewing wrote: > Steve D'Aprano wrote: >> A harder question is, what if you take a random number from the Integers? >> How >> many digits will it have in (say) base 10? I don't have a good answer to >> that. >> I think it may be ill-defined. > > I think the answer is that on average it has infinitely many > digits -- despite every actual integer only having finitely > many digits! > > We can prove this by contradiction. Suppose the answer were > some finite number N. There are only finitely many integers > with N or fewer digits, but there are infinitely many with > more than N digits, so including them in the average must > make it bigger than N. So N cannot be finite. Sorry that my english is so poor that I could only draft ideas. :/ I think that it probably depends on distribution. Think something like: def numbers(e=0.999): ''' random numbers from integers ''' while 1: r = random.random() yield int(1/(1-r)**e) and see: https://www.wolframalpha.com/input/?i=area+between+y+%3D+1%2Fx%5E0.999+and+y+%3D+0+between+x+%3D+0+and+1 and unbounded (for e==1) -> https://www.wolframalpha.com/input/?i=area+between+y+%3D+1%2Fx+and+y+%3D+0+between+x+%3D+0+and+1 # if somebody likes to test hipothesis -> def avg(N=1000): return sum(itertools.islice(numbers(), 0,N,1))/N -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Fri, 8 Sep 2017 11:01 pm, Rhodri James wrote: > On 08/09/17 13:45, Stefan Ram wrote: >> Gregory Ewing writes: >> [a random integer will on average have ] >>> infinitely many >>> digits -- despite every actual integer only having finitely >>> many digits! >>This is not possible because every integer has >>a finite number of digits (in base 10). > > Surely an infinitely large integer has an infinite number of digits? There are no infinitely large integers. All integers are finite. We can say that there is no largest integer, that they go on forever -- but no individual integer is infinite. We soon run out of notation to write them. There are numbers so inconceivably huge that ordinary exponential notation isn't big enough, like Graham's Number, and we can invent numbers even bigger: let G = Graham's Number let H = G^^G^^G^^ ... ^^G # tower of a Graham's Number G's, where ^^ is the tetration (double arrow) operator: x^^y = x^x^x^...^x # tower of y x's but even those inconceivably huge numbers are finite. That's the thing about infinity. No matter how huge the number is, it is still falls infinitely short of infinite. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Fri, 8 Sep 2017 01:01 pm, Rustom Mody wrote: > On Friday, September 8, 2017 at 7:39:38 AM UTC+5:30, Steve D'Aprano wrote: >> Rustom, I've already given you the definitive answer to your question about >> how to define `is` without talking about memory. You haven't replied or >> acknowledged it, so here is it again: >> >> `is` compares the two operands for identity. > > Preamble… so far so good > >> If the two operands are the same >> object, `is` returns True, if they are distinct objects, `is` returns False. > > restated > a is b iff a is b I hope you are not seriously claiming this is a circular argument. The first half of your restatement, before the "iff", represents *Python code*, not natural language, and needs to be quoted[1] to make sense. If you don't quote it, you are just stating a tautology: a is b iff a is b, which is true by definition, no matter what meaning we assign to the word "is". But that's not what I'm saying, and you are wrong to accuse me of giving a tautology. I'm referring to the Python expression (which is source code in a programming language which merely looks a bit like English), and explaining it in English terms. The "is" in the first half is not the same as the "is" in the second, which makes the sentence non-circular. This would be more obvious if we were having this discussion in (say) Hindi, Latin, Swahili, or German: `A is B` ob und nur wenn A ist B (Or should that be "ob und nur ob"? Google Translate prefers the first, but I have my doubts.) If Python used a mathematical symbol instead of the word "is" as the operator, it also would obviously be non-circular: `A ≡ B` if and only if A is B The mere happenstance that: (1) Python uses the English word "is" as the operator, rather than some other symbol like `≡` or `===` or `≣` or `.ist.`; and (2) we happen to be writing in English, rather than (say) Japanese or Russian or Esperanto or the Black Speech of Mordor; does not make my argument circular. You have been lead astray by the mere contingent fact that Python uses `is` for the operator, instead of some other symbol. Don't be fooled: the operator `is` is not the same as the English word "is". But you know that, so I'm not sure why you are trying to misrepresent my argument as circular. So let us start repairing your restatement by adding quotation marks. I use `` rather than "" because that's the convention used in Markdown for displaying inline code, and I'm quoting the code: `a is b` if and only if a is b is not circular, but it's not very clear[2]. I intentionally avoided using the English word "is" (not to be confused with the Python operator `is`) in my explanation, because I knew it would confuse people and lead them astray. So let us use a better explanation, one which is less likely to give a misleading impression: `a is b` if and only if the two operands are the same object which is closer to what I actually said and avoids giving the mistaken impression of circular reasoning. Now if you want to argue about the definition of "same", I have already stated my position: the commonsense or intuitive meaning of "the same thing" is sufficient here. If you disagree, then it is up to you to demonstrate a problem with the commonsense meaning in this context. >> This does require that we agree on "same object", which as you point out is >> (in its full generality) a difficult thing to define. > > More than difficult, impossible in the fully abstract philosophical case Fortunately, the fully abstract philosophical case is irrelevant here. [...] > E.g. in the past I've raised >> the paradox of My Grandfather's Axe. > > Dont see the relevance (here) The paradox of the axe is one illustration of the difficulty in defining "the same" in full generality. When objects persist through time and are subject to change, there are questions raised about what it means to say that something is the same when all its component bits have been replaced. So I'm agreeing with you[2] that "the same" in its full generality is difficult to define in a non-paradoxical way. >> But the intuitive, common-sense notion of "same object" is, I think, >> sufficient here. If you want to argue that it is *not* sufficient, I think >> it's up to you to demonstrate a problem with the definition. >> > > Its not that you cant raise philosophical problems if you want > But when concretized to (basic) math, there are no disputes > so the argument becomes obtuseness to no point I'm afraid I have no idea what you think you are saying here. > In the case of python data model every single interminable thread like this > one, obviously started by a noob asking something genuinely and indicating > a real confusion disproves your claim to obvious intuition and common sense The Original Poster wasn't confused by "sameness". The OP was confusing by scoping and mutation. You have to go back to 15 August to find the beginning of the thread, but the OP was hav
Re: A question on modification of a list via a function invocation
On Fri, 8 Sep 2017 08:20 pm, Ben Bacarisse wrote: > Steve D'Aprano writes: > >> On Fri, 8 Sep 2017 12:28 am, Chris Angelico wrote: >> >>> languages without mutable objects don't >>> really care whether they're pass-by-X or pass-by-Y. >> >> Only if you don't care about efficiency. >> >> Believe me, the first time you pass a five gigabyte array to a function using >> pass-by-value, on a machine with only six gigabytes of memory, you'll care. > > I think your general idea to separate language semantics from > implementation details is a good one, but you've dropped it here. A > language with call-by-value semantics need not copy large objects when > passing them to a function. The program must behave *as if* there is a > copy but there need not actually be one. You're right: I didn't think of the case where a language simulates pass-by-value semantics without actually copying. I was thinking only of actual pass-by-value implementations. Why would any compiler for a language with immutable arrays actually copy them when passing them to a function? *shrug* Call it a quality of implementation issue. Lots of compilers have sub-optimal implementations. One counter-example might be to implement copy-on-write, in which case the copying can be delayed until the array is written to. (Although Chris did specify languages with immutable data structures, so that's out.) But the larger point that I'm making is that we're not actually doing computation in some abstract, Platonic space of pure mathematics, we're using real computers that have to shunt actual electrons through wires and semiconductors at high speed to do anything. Computation has real costs. We can try to ignore them, but they exist. And even absent mutation, the way you pass arguments has costs to: - the overhead of passing arguments to functions adds up; even a tiny difference in efficiency can make a big difference to the overall speed of the implementation; - as well as the memory consumption; - the amount of work the CPU does, hence your electricity bill; - to say nothing of the Greenhouse gases, the electronic failure rate, etc; - let's not forget the complexity of the compiler and the possibility of bugs. See: https://en.wikipedia.org/wiki/Man_or_boy_test Unless pass-by-X and pass-by-Y have the same costs, somebody somewhere is going to care about the difference. That was my point. I tried to express it humorously rather than pedantically. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
r...@zedat.fu-berlin.de (Stefan Ram): > Marko Rauhamaa writes: >>I definitely trust that: >>a = b >>assert a is b >>even when b holds an immutable object. > > |Python 3.6.0 ... > |>>> x = 21568 > |>>> x is 21568 > |False I wasn't talking about x or 21568. I was talking about a and b. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Op 08-09-17 om 04:09 schreef Steve D'Aprano: > On Fri, 8 Sep 2017 04:24 am, Rustom Mody wrote: > >> On Thursday, September 7, 2017 at 6:52:04 PM UTC+5:30, Gregory Ewing wrote: >>> Rustom Mody wrote: >>> I said: In that case please restate the definition of 'is' from the manual which invokes the notion of 'memory' without bringing in memory. >>> I don't know whether it's in the manual, but at least for >>> mutable objects, there is a way to define the notion of >>> "same object" that doesn't require talking about "memory": >>> >>> Two names refer to the same object if and only if mutations >>> made through one are visible through the other. >> Seems a sensible comment! > > Except that it is wrong, or at least over-generalised. It is trivially easy to > show false positives: > > py> class K: # defines an object > ... def __init__(self, x): > ... self.x = x > ... def append(self, value): > ... self.x.append(value) > ... > py> a = [] > py> b = K(a) > py> a is b # these are not the same object (they're different types) > False > py> b.append(99) # but modifying b modifies a > py> a > [99] I don't know if this is a False positive. Yes you have shown a mutation to one that also shows up in the other. But it is possible to mutate b in ways that doesn't show up in a. It seems you have interpreted the phrase: "if and only if mutations made through one are visible through the other." as if it said: "if and only if *some* mutations made through one are visible through the other." while it seems more natural to me to understand it as: "if and only if *all* mutations made through one are visible through the other." So since it is possible to mutate b in ways that are not reflected in a, I can't really see this as a false positive. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Fri, 8 Sep 2017 05:54 pm, Gregory Ewing wrote: > Steve D'Aprano wrote: >> py> class K: # defines an object >> ... def __init__(self, x): >> ... self.x = x >> ... def append(self, value): >> ... self.x.append(value) >> ... >> py> a = [] >> py> b = K(a) >> py> a is b # these are not the same object (they're different types) >> False >> py> b.append(99) # but modifying b modifies a >> py> a >> [99] > > You didn't mutate the object bound to b there, > you mutated the one bound to b.x, which is > also bound to a. Of course I do -- I've mutated one of the parts of the whole, therefore the whole is mutated too. Would you argue that if I took a hammer to your computer's motherboard, smashing it to bits, that I haven't damaged your computer? My class K is just a minimal sketch of a class that uses dependency injection and composition, but that's not critical. Any compound object which has publicly visible mutable parts is subject to the same sort of false positive: book = Book() assert book.annotations == [] page = book.pages[15] assert book is not page # the whole is not the same as the part page.annotate( 'Is this the right room for an argument?') # but if you mutate the part assert book.annotations == [15] # the whole mutates too -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On 08/09/17 13:45, Stefan Ram wrote: Gregory Ewing writes: [a random integer will on average have ] infinitely many digits -- despite every actual integer only having finitely many digits! This is not possible because every integer has a finite number of digits (in base 10). Surely an infinitely large integer has an infinite number of digits? -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Fri, Sep 8, 2017 at 10:05 PM, Steve D'Aprano wrote: > On Fri, 8 Sep 2017 05:48 pm, Gregory Ewing wrote: > >> Steve D'Aprano wrote: >>> A harder question is, what if you take a random number from the Integers? >>> How >>> many digits will it have in (say) base 10? I don't have a good answer to >>> that. I think it may be ill-defined. >> >> I think the answer is that on average it has infinitely many >> digits -- despite every actual integer only having finitely >> many digits! > > I don't think that talking about the average integer is meaningful. Assuming > we > are talking about the arithmetic mean, we're dealing with a divergent sum that > depends on the way you do the summation: > > 0 + 1 + -1 + 2 + -2 + 3 + -3 + ... = 0 > > 0 + 1 + 2 + 3 + 4 + ... + (-1 - 2 - 3 - 4 - ...) = ∞ - ∞ which is undefined. > > (Other means have similar problems, they're just harder to write or less > familiar.) Here's a different take on the problem. The first integer (zero) has, let's say, no digits. Then the next 18 (1 through 9 and -1 through -9) have one digit. The next 180 have two digits (getting us to 99 and -99). Etcetera. Multiply each digit count by how many numbers have it, and divide by the grand total: (0 * 1 + 1 * 18 + 2 * 18 * 10 + 3 * 18 * 100 ...) / (1 + 18 + 18*10 + 18*100 ...) As you add terms, the earlier terms become diminishingly significant to the result, and the final term approaches digits/1.1 (in this example, 3 * 1800 / (1800+180+18+1)). Since digits is tending towards +∞, so is the sum. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Fri, 8 Sep 2017 05:48 pm, Gregory Ewing wrote: > Steve D'Aprano wrote: >> A harder question is, what if you take a random number from the Integers? How >> many digits will it have in (say) base 10? I don't have a good answer to >> that. I think it may be ill-defined. > > I think the answer is that on average it has infinitely many > digits -- despite every actual integer only having finitely > many digits! I don't think that talking about the average integer is meaningful. Assuming we are talking about the arithmetic mean, we're dealing with a divergent sum that depends on the way you do the summation: 0 + 1 + -1 + 2 + -2 + 3 + -3 + ... = 0 0 + 1 + 2 + 3 + 4 + ... + (-1 - 2 - 3 - 4 - ...) = ∞ - ∞ which is undefined. (Other means have similar problems, they're just harder to write or less familiar.) There's even a (legitimate!) argument to be made that the sum of all positive integers is -1/12. http://www.slate.com/blogs/bad_astronomy/2014/01/18/follow_up_the_infinite_series_and_the_mind_blowing_result.html More here: https://en.wikipedia.org/wiki/1_%2B_2_%2B_3_%2B_4_%2B_%E2%8B%AF Not to mention the inconvenient fact that we're dividing by infinity: (sum of all integers (whatever it is!))/∞ I don't think there is any way to select a random integer with equal probability, but even if we had one, there's no guarantee that the sample means would converge to the population mean. This is rather like the Cauchy distribution, where the mean is not defined, and the sample means oscillate more and more wildly as you sample more values. So I think that any answer that requires talking about the mean or average is ill-defined. At least unless we include significantly more rigour than I am capable of. If we instead say, "pick a random integer between 0 and N", and then let N increase without limit, we see that the average number of digits also increases without limit. But that's not the same as saying that the average number of digits is infinite! We *can* say that about choosing a random Real, because the irrational numbers outnumber the rationals by so much that any random Real we pick is Almost Always irrational. And irrationals don't have a finite expansion in any integer base. Hence we can argue that we're almost certain to choose an irrational number, and irrationals have infinite digits in their expansion. But we can't say the same thing for integers. As you point out, all integers have a finite number of digits, so we're on shaky ground to say that the average integer has infinite digits. That implies that the average is bigger than all the elements making up the average! Trying to make sense of divergent series is fraught with traps. Many very simple sounding questions involving divergent series don't have an answer at all. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Steve D'Aprano writes: > On Fri, 8 Sep 2017 12:28 am, Chris Angelico wrote: > >> languages without mutable objects don't >> really care whether they're pass-by-X or pass-by-Y. > > Only if you don't care about efficiency. > > Believe me, the first time you pass a five gigabyte array to a function using > pass-by-value, on a machine with only six gigabytes of memory, you'll care. I think your general idea to separate language semantics from implementation details is a good one, but you've dropped it here. A language with call-by-value semantics need not copy large objects when passing them to a function. The program must behave *as if* there is a copy but there need not actually be one. -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Gregory Ewing : > Marko Rauhamaa wrote: >> I definitely trust that: >> >>a = b >>assert a is b >> >> even when b holds an immutable object. > > That's true, but there's rarely a good use case for that > fact that isn't better addressed with an equality comparison > rather than an 'is' test. I use the principle in sentinel objects. I don't care about equality but identity. > As an example, back in the days of string exceptions, > the established idiom was > >MyException = "MyException" > > try: > ... > raise MyException > ... > except MyException: > ... > > Which worked, but it was error-prone. Writing > >except "MyException": > > instead would *probably* work, but wasn't guaranteed. > If the implementation had matched string exceptions > by equality rather than identity, that wouldn't have > been an issue. I would never have thought of doing that. However, strings are as good sentinel objects as any (they are trivially printable). Whatever sentinel object you choose, identity is the name of the game, not equality. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Marko Rauhamaa wrote: I definitely trust that: a = b assert a is b even when b holds an immutable object. That's true, but there's rarely a good use case for that fact that isn't better addressed with an equality comparison rather than an 'is' test. As an example, back in the days of string exceptions, the established idiom was MyException = "MyException" try: ... raise MyException ... except MyException: ... Which worked, but it was error-prone. Writing except "MyException": instead would *probably* work, but wasn't guaranteed. If the implementation had matched string exceptions by equality rather than identity, that wouldn't have been an issue. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Rustom Mody wrote: Models are needed Math is one possible model Machines are another I'm not sure there's any real distinction between "math" and "machines". A Turing machine, for example, is an idealised mathematical model of computation. Maybe the distiction you're trying to get at is "stateless" vs. "stateful" models of computation? With lambda calculus being an example of a stateless model, and a Turing machine a stateful one. However, I suspect that the reason you're having trouble with the concept of "same object" in a mathematical setting is that you're failing to consider the identity of an object to be a piece of information in its own right that needs to be included in the model. If you see something like this from a Python session: >>> a [1, 2] >>> b [1, 2] you *can't tell* just by looking at that whether a and b are bound to the same object. That's an extra piece of information that isn't shown in those textual representations. This is why we have things like the "is" operator and the id() function -- they provide ways of probing that hidden information. If you want to model Python computation purely mathematically, you need to come up with a way to make that extra information explicit. There are many ways that can be done. One way is to draw a graph. Another might be to assign id numbers to objects and represent objects as (id, value) tuples. But the information needs to be there in some form, otherwise you're not modelling Python. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Rustom Mody wrote: I'd like to know what these rules are I can't give you a complete list of them off the top of my head, but some examples of the kind of rules I have in mind are: * After the assigment a = b a and b refer to the same object. * After x = [e1, e2, e3, ...] x refers to a new object that's not the same as any other object. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Steve D'Aprano wrote: py> class K: # defines an object ... def __init__(self, x): ... self.x = x ... def append(self, value): ... self.x.append(value) ... py> a = [] py> b = K(a) py> a is b # these are not the same object (they're different types) False py> b.append(99) # but modifying b modifies a py> a [99] You didn't mutate the object bound to b there, you mutated the one bound to b.x, which is also bound to a. All you've shown is that just because a method is named "append" doesn't mean it mutates the object it's a method of. :-) -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Steve D'Aprano wrote: A harder question is, what if you take a random number from the Integers? How many digits will it have in (say) base 10? I don't have a good answer to that. I think it may be ill-defined. I think the answer is that on average it has infinitely many digits -- despite every actual integer only having finitely many digits! We can prove this by contradiction. Suppose the answer were some finite number N. There are only finitely many integers with N or fewer digits, but there are infinitely many with more than N digits, so including them in the average must make it bigger than N. So N cannot be finite. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Rustom Mody wrote: 2. is — machine representation, too fine to be useful No, it's *not* machine representation. As I pointed out before, it's part of the abstract semantics of Python. And it's not "too fine to be useful". On the contrary, being aware of which objects are the same and which aren't is vital to writing Python programs that behave in the intended way. 3. graph (or topological) equality 3 captures pythonistas intuition of same better than 1 or 2 I don't think so, see below. a = [1,2] b = [a,a] c = [[1,2],[1,2]] p = [1,2] q = [p,p] r = [[1,2],[1,2]] Now the pythonista understands that b and c may be math-= but have different structure Whereas b is graph-equal to q And c is graph-equal to r However there is no available operation to show/see that distinction Because usually it's not particularly important to know whether two separate structures have the same topology. On the other hand, it *is* important to know things such as 'b[0] is b[1]' but 'c[0] is not c[1]', because it makes a difference to what happens if you mutate any of those. The trouble is that graph-isomorphism is NP-complete so the crucial operation cannot be reasonably implemented We're fortunate that it's not actually a crucial operation, then. :-) -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Gregory Ewing : > There is more leeway when it comes to immutable objects; > implementations are free to cache and re-use them, so well-written > code avoids depending on the result of "is" for immutable objects. I definitely trust that: a = b assert a is b even when b holds an immutable object. Assignment, argument passing, return value passing and yield (to name a few) must preserve identity. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Fri, Sep 8, 2017 at 1:01 PM, Rustom Mody wrote: > >> Can you show an actual false positive (two distinct objects for which `is` >> returns True) or false negative (the same object given as both operands for >> `is` nevertheless returns False)? In the absence of any actual bugs in the >> definition, I maintain that it is sufficient. > > You are not paying attention — the example above I gave in which > python arbitrarily hi-handedly, inconsistently manifests different behavior > between integer 1 and tuple (1,2) You started with the assumption that the tuple (1,2) is the same as the tuple (1,2). This is a false assumption; they are equal, but they are not identical. How does your mathematical model cope with this? >>> x = 1 >>> y = 1.0 >>> x == y True >>> x is y False There is no way that a compliant Python implementation can give any other results for these expressions. These values are equal but not identical. It's the same with the integers and tuples in your example, except that there, Python is permitted to optimize by using the same object. Stop thinking about mathematics and assuming that (a) it is the perfect way to explain software, and (b) we all have the same basis you do. Start thinking about programming languages from a different basis... you might actually learn something. Or just read what Steve and I have been saying. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Friday, September 8, 2017 at 7:39:38 AM UTC+5:30, Steve D'Aprano wrote: > On Fri, 8 Sep 2017 04:24 am, Rustom Mody wrote: > > > On Thursday, September 7, 2017 at 6:52:04 PM UTC+5:30, Gregory Ewing wrote: > >> Rustom Mody wrote: > >> > >> > I said: In that case please restate the definition of 'is' from the > >> > manual > >> > which invokes the notion of 'memory' without bringing in memory. > >> > >> I don't know whether it's in the manual, but at least for > >> mutable objects, there is a way to define the notion of > >> "same object" that doesn't require talking about "memory": > >> > >> Two names refer to the same object if and only if mutations > >> made through one are visible through the other. > > > > Seems a sensible comment! > > > Except that it is wrong, or at least over-generalised. It is trivially easy to > show false positives: > > py> class K: # defines an object > ... def __init__(self, x): > ... self.x = x > ... def append(self, value): > ... self.x.append(value) > ... > py> a = [] > py> b = K(a) > py> a is b # these are not the same object (they're different types) > False > py> b.append(99) # but modifying b modifies a > py> a > [99] > > > Rustom, I've already given you the definitive answer to your question about > how > to define `is` without talking about memory. You haven't replied or > acknowledged it, so here is it again: > > `is` compares the two operands for identity. Preamble… so far so good > If the two operands are the same > object, `is` returns True, if they are distinct objects, `is` returns False. restated a is b iff a is b A more than usually egregious demo of the circularity of defining isness/sameness Models are needed Math is one possible model Machines are another Paper and pen — which Chris keeps referring to — is another Remove all models and you have frank hopeless circularity > > > This does require that we agree on "same object", which as you point out is > (in > its full generality) a difficult thing to define. More than difficult, impossible in the fully abstract philosophical case When concretized to specific models not necessarily the fundamental circularity then pushed out to the model 1 + 2 = 3 Are these '3's on your and my screen same? Same font? Same time? E.g. in the past I've raised > the paradox of My Grandfather's Axe. Dont see the relevance (here) > > But the intuitive, common-sense notion of "same object" is, I think, > sufficient > here. If you want to argue that it is *not* sufficient, I think it's up to you > to demonstrate a problem with the definition. > Its not that you cant raise philosophical problems if you want But when concretized to (basic) math, there are no disputes so the argument becomes obtuseness to no point In the case of python data model every single interminable thread like this one, obviously started by a noob asking something genuinely and indicating a real confusion disproves your claim to obvious intuition and common sense Just to reiterate: Someone asked a question Its not clear what (s)he understood from what we have going on and on about for 100s of posts > Can you show an actual false positive (two distinct objects for which `is` > returns True) or false negative (the same object given as both operands for > `is` nevertheless returns False)? In the absence of any actual bugs in the > definition, I maintain that it is sufficient. You are not paying attention — the example above I gave in which python arbitrarily hi-handedly, inconsistently manifests different behavior between integer 1 and tuple (1,2) I am now dropping off this thread [more important things to do] with this observation: There are these strange wondrous things in the world called 'mothers' They take bawling shiing peeing pieces of fleshy exasperation called 'babies' And convert them into intelligent human beings Dunno how they do it… More easily: if I, knowing English, read a German-English dictionary its ok, a well-founded action — learning unknown-German via known-English But reading a 'normal' English-English dictionary like Webster, Oxford etc is borderline infinite recursion… And occasionally fails — ambiguities, grey areas Still it mostly works… with enough good faith However bootstrapping the whole process from absolute zero — the mothers' task — is frankly beyond my ken Bare (pure-philosophical, model-less) identity/sameness is analogous So… what you think is obvious and trivially intuitive — the bald fact of semantics and comprehension — is to me quite miraculous -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Fri, 8 Sep 2017 04:24 am, Rustom Mody wrote: > On Thursday, September 7, 2017 at 6:52:04 PM UTC+5:30, Gregory Ewing wrote: >> Rustom Mody wrote: >> >> > I said: In that case please restate the definition of 'is' from the manual >> > which invokes the notion of 'memory' without bringing in memory. >> >> I don't know whether it's in the manual, but at least for >> mutable objects, there is a way to define the notion of >> "same object" that doesn't require talking about "memory": >> >> Two names refer to the same object if and only if mutations >> made through one are visible through the other. > > Seems a sensible comment! Except that it is wrong, or at least over-generalised. It is trivially easy to show false positives: py> class K: # defines an object ... def __init__(self, x): ... self.x = x ... def append(self, value): ... self.x.append(value) ... py> a = [] py> b = K(a) py> a is b # these are not the same object (they're different types) False py> b.append(99) # but modifying b modifies a py> a [99] Rustom, I've already given you the definitive answer to your question about how to define `is` without talking about memory. You haven't replied or acknowledged it, so here is it again: `is` compares the two operands for identity. If the two operands are the same object, `is` returns True, if they are distinct objects, `is` returns False. This does require that we agree on "same object", which as you point out is (in its full generality) a difficult thing to define. E.g. in the past I've raised the paradox of My Grandfather's Axe. But the intuitive, common-sense notion of "same object" is, I think, sufficient here. If you want to argue that it is *not* sufficient, I think it's up to you to demonstrate a problem with the definition. Can you show an actual false positive (two distinct objects for which `is` returns True) or false negative (the same object given as both operands for `is` nevertheless returns False)? In the absence of any actual bugs in the definition, I maintain that it is sufficient. And if there are still philosophical problems with the concept of "the same object", they either don't apply to Python objects, or they apply equally to all objects in the universe and there's nothing we can do about it. Either way, the problem of defining the Python `is` operator without referring to memory is solved. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Fri, 8 Sep 2017 05:15 am, Stefan Ram wrote: > It computing newsgroups, for example, people > ask about how to compute the number of digits > of a number, when, actually, only numerals > (representations of numbers in a particular > numeral system) have digits. Um, yes? That's implicit in the question -- and generally the numeral system in question is implied to be 10. Context is important. But for what it's worth, if you take a random number from the Reals, then the answer will be "infinite digits" for Almost All[1] numbers, no matter what number base you are using. A harder question is, what if you take a random number from the Integers? How many digits will it have in (say) base 10? I don't have a good answer to that. I think it may be ill-defined. [1] https://en.wikipedia.org/wiki/Almost_all -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Thursday, September 7, 2017 at 6:52:04 PM UTC+5:30, Gregory Ewing wrote: > Rustom Mody wrote: > > > I said: In that case please restate the definition of 'is' from the manual > > which > > invokes the notion of 'memory' without bringing in memory. > > I don't know whether it's in the manual, but at least for > mutable objects, there is a way to define the notion of > "same object" that doesn't require talking about "memory": > > Two names refer to the same object if and only if mutations > made through one are visible through the other. Seems a sensible comment! [Aside from the fact that 'visible' is likely ill or circularly defined — my other comment to Stefan. But lets just ignore that for now and assume that 'visible' has no grey/dispute areas] > > Python has definite rules concerning when mutable objects > will be the same or not, and every correct implementation > must conform to them. In that sense it's a fundamental > concept that doesn't depend on implementation. I'd like to know what these rules are > > There is more leeway when it comes to immutable objects; > implementations are free to cache and re-use them, so > well-written code avoids depending on the result of > "is" for immutable objects. Which sounds like saying that 'isness' of immutables is ill/un-defined Not that I object if this is said My objection is to the claim that the isness of python's is and the isness of 'conceptually-same' are the same. I believe that your definition of same and the one I earlier gave are similar (same?? Not sure) Repeating here for ease: (with some clarifications) We say equivalence relation R is coarser than S is xSy ⇒ xRy So x is y ⇒ x == y but not (necessarily) vice versa However there are not 2 but 3 equivalence relations: 1. == — mathematical, too coarse to understand nuances of python semantics 2. is — machine representation, too fine to be useful 3. graph (or topological) equality which experienced pythonistas have internalized in understanding when two data structures are same or different [Roughly Anton's diagrams that are beyond my drawing capability!] And yet pythonistas need 3 to understand python data structures ie 3 captures pythonistas intuition of same better than 1 or 2 >>> a = [1,2] >>> b = [a,a] >>> c = [[1,2],[1,2]] >>> b == c True >>> b is c False >>> p = [1,2] >>> q = [p,p] >>> r = [[1,2],[1,2]] >>> q == r True >>> q is r False >>> b == q True >>> b == r True >>> b is q False >>> b is r False Now the pythonista understands that b and c may be math-= but have different structure Whereas b is graph-equal to q And c is graph-equal to r However there is no available operation to show/see that distinction The trouble is that graph-isomorphism is NP-complete so the crucial operation cannot be reasonably implemented To make it more clear ≡ is graph-equal, ie 2. The pythonista understands that b ≢ c ## ≡ is finer than == Whereas b ≡ r ie ≡ is coarser than is And b and r are python-equivalent without any memory relation in the sense that no sequence of valid operations applied to b and to r will tell them apart — sometimes called 'trace-equivalence' -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On 06/09/17 14:02, Stefan Ram wrote: > Chris Angelico writes: >> The 'is' operator tests if two things are the same thing. > >»Roughly speaking, to say of two things that they are >identical is nonsense, and to say of one thing that it >is identical with itself is to say nothing at all.« > > Ludwig Wittgenstein, Tractatus Logico-Philosophicus (5.5303) Someone who is philosophically literate in technical forum: a rare treat! Nice!! Wittgenstein is a favorite of mine and I often reserve one lecture for his: “Limits of my language are the limits of my world” Then amplified by Roman Jacobson’s “Languages differ not in what we can say but what we must say” And finally with Whorf's evidence that words can set buildings on fire https://web.stanford.edu/dept/SUL/library/extra4/sloan/mousesite/Secondary/Whorfframe2.html [Today it would be send countries to war] However Wittgenstein's quote above on identity is too terse to properly grasp the real difficulty https://plato.stanford.edu/entries/identity/ shows at some (verbose!) length that identity is and can only be a hopelessly circular definition. A problem which has little to do with python, programming languages, or CS in general; it is a fundamental universal problem -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Fri, 8 Sep 2017 02:24 am, Chris Angelico wrote: > On Fri, Sep 8, 2017 at 1:30 AM, Steve D'Aprano > wrote: >> On Fri, 8 Sep 2017 12:28 am, Chris Angelico wrote: >> >>> languages without mutable objects don't >>> really care whether they're pass-by-X or pass-by-Y. >> >> Only if you don't care about efficiency. >> >> Believe me, the first time you pass a five gigabyte array to a function using >> pass-by-value, on a machine with only six gigabytes of memory, you'll care. [...] > Right - but sharing (in whatever form) is a pure optimization, with no > visible semantics. Apart from the disk activity light on your PC, as it starts thrashing :-) -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Fri, Sep 8, 2017 at 1:30 AM, Steve D'Aprano wrote: > On Fri, 8 Sep 2017 12:28 am, Chris Angelico wrote: > >> languages without mutable objects don't >> really care whether they're pass-by-X or pass-by-Y. > > Only if you don't care about efficiency. > > Believe me, the first time you pass a five gigabyte array to a function using > pass-by-value, on a machine with only six gigabytes of memory, you'll care. > > Preventing that sort of thing is probably why arrays aren't first-class values > in C, and you cannot pass an array as argument, only a pointer to an array. > But > Pascal will happily assume you know what you're doing if you declare an array > parameter without "var", and copy the whole array. Right - but sharing (in whatever form) is a pure optimization, with no visible semantics. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Fri, 8 Sep 2017 12:28 am, Chris Angelico wrote: > languages without mutable objects don't > really care whether they're pass-by-X or pass-by-Y. Only if you don't care about efficiency. Believe me, the first time you pass a five gigabyte array to a function using pass-by-value, on a machine with only six gigabytes of memory, you'll care. Preventing that sort of thing is probably why arrays aren't first-class values in C, and you cannot pass an array as argument, only a pointer to an array. But Pascal will happily assume you know what you're doing if you declare an array parameter without "var", and copy the whole array. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Thu, Sep 7, 2017 at 11:21 PM, Gregory Ewing wrote: > Rustom Mody wrote: > >> I said: In that case please restate the definition of 'is' from the manual >> which invokes the notion of 'memory' without bringing in memory. > > > I don't know whether it's in the manual, but at least for > mutable objects, there is a way to define the notion of > "same object" that doesn't require talking about "memory": > > Two names refer to the same object if and only if mutations > made through one are visible through the other. > > Python has definite rules concerning when mutable objects > will be the same or not, and every correct implementation > must conform to them. In that sense it's a fundamental > concept that doesn't depend on implementation. Yep. I'd call this a litmus test rather than a definition, but it's absolutely true - and it's why languages without mutable objects don't really care whether they're pass-by-X or pass-by-Y. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Steve D'Aprano wrote: I think that these two increment procedures will be (more or less?) equivalent: procedure increment(var n: integer); begin n := n + 1 end; procedure increment2(p: intpointer); begin p^ := p^ + 1 end; They are, with the proviso that, in standard Pascal, increment2 can only be applied to a heap-allocated instance of intpointer, whereas increment can be applied to any variable of type integer. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Rustom Mody wrote: I said: In that case please restate the definition of 'is' from the manual which invokes the notion of 'memory' without bringing in memory. I don't know whether it's in the manual, but at least for mutable objects, there is a way to define the notion of "same object" that doesn't require talking about "memory": Two names refer to the same object if and only if mutations made through one are visible through the other. Python has definite rules concerning when mutable objects will be the same or not, and every correct implementation must conform to them. In that sense it's a fundamental concept that doesn't depend on implementation. There is more leeway when it comes to immutable objects; implementations are free to cache and re-use them, so well-written code avoids depending on the result of "is" for immutable objects. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Chris Angelico : > *facepalm* > > I got nothing to say to you. Then why say anything? Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Op 07-09-17 om 03:27 schreef Steve D'Aprano:
>
>> Yes it is. Pascal VAR parameters are exactly like Python a assignment.
> Proof by assertion?
>
> "It is true, because I say it is true!"
I didn't just assert, I also explained. That you choose to
ignore the explanation doesn't make it a proof by assertion.
Calling a function/procedure with a VAR parameter in Pascal,
makes the parameter an alias of the argument. Just like
a python assignment makes an alias.
This can be shown by the fact that if one mutates the enity
through one alias, the effect can be seen through the other
alias.
Now the counter argument is that if you assign to the parameter
in the function, this change doesn't effect the argument with
which the function was called in Python. But this ignores the
fact that the assignment in python doesn't mutate the entity
it refers to or is bound to or whatever you want to call it.
Instead it makes the parameter now refer/bound to something else.
Expecting that one should be able to write a swap function
should the parameters in python be like VAR parameters in
Pascal is ignoring how assignment semantics in python differ
from the assignment semantics in Pascal.
This can be shown by writing a swap function for lists because
we can simulate a mutating assignment with lists.
def swap(lp1, lp2):
tmp = list(lp1)
lp1[:] = lp2
lp2[:] = tmp
ls1 = [1, 3, 5, 7]
ls2 = [0, 2, 4, 6]
print(id(ls1), ls1)
print(id(ls2), ls2)
print("")
swap(ls1, ls2)
print(id(ls1), ls1)
print(id(ls2), ls2)
Which on my computer produces:
140178186781768 [1, 3, 5, 7]
140178186794632 [0, 2, 4, 6]
140178186781768 [0, 2, 4, 6]
140178186794632 [1, 3, 5, 7]
--
Antoon Pardon.
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Thu, 7 Sep 2017 12:11 am, Antoon Pardon wrote: [...] > No it would not translate to the above diagram. It would translate to my > diagram. All variables in pascal refer to some object (in memory), they don't > refer to other variables. If you have a pointer variable, you have a variable > that refers to an object that itself refers to an other object. This later > object can be one that is refered to directly by another variable, like code > as above. I'm afraid that I have no idea what you are talking about -- your explanation is unclear to me. [...] > Yes it is. Pascal VAR parameters are exactly like Python a assignment. Proof by assertion? "It is true, because I say it is true!" -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wed, 6 Sep 2017 11:02 pm, Stefan Ram wrote: > Chris Angelico writes: >>The 'is' operator tests if two things are the same thing. > > »Roughly speaking, to say of two things that they are > identical is nonsense, and to say of one thing that it > is identical with itself is to say nothing at all.« > > Ludwig Wittgenstein, Tractatus Logico-Philosophicus (5.5303) "Roughly speaking". But to be more precise, it is meaningful. "Was that you yourself I saw yesterday walking down the street, or your doppelgänger?" Or to put it another way... Was the person I saw yesterday identical (in the identity sense) to the person I am speaking to now? We don't really use "is identical" (in the identity sense) to compare "two distinct things" versus "one thing" -- we use it to compare two *operands* and don't know which situation applies until after we get the answer. If we already knew they were identical, we wouldn't need to ask. The same applies to when we are making statements rather than asking questions (making assertions about identity rather than questioning it). The point of making the assertion is to pass on information that would otherwise by ambiguous: "There is that same (identity) cat again (not merely one that looks like it)." -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wed, 6 Sep 2017 10:11 pm, Rustom Mody wrote:
> On Wednesday, September 6, 2017 at 5:08:20 PM UTC+5:30, Steve D'Aprano wrote:
>> On Wed, 6 Sep 2017 07:13 pm, Rustom Mody wrote:
>>
>>
>> > Can you explain what "id" and "is" without talking of memory?
>>
>> Yes.
>>
>> id() returns an abstract ID number which is guaranteed to be an integer, and
>> guaranteed to be distinct for all objects which exist at the same time. When
>> an object ceases to exist, its ID number may be re-used.
>>
>> `is` compares the two operands for identity. If the two operands are the same
>> object, `is` returns True, if they are distinct objects, `is` returns False.
>
a = (1,2)
b = (1,2)
a is b
> False
x = 1
y = 1
x is y
> True
>
> a seems to be as 'same' to b as x is to y
> Python seems to think otherwise
>
> Evidently your ‘same’ is not the same as mine??
You are (intentionally, I think) being obtuse. I am confident that you know very
well that "the same" as a general English term has many meanings, including:
- same in identity ("the same man I saw yesterday");
- closely similar ("the curtains are the same colour as the carpets");
- equal ("I gave the children the same number of lollies each");
- unchanged ("his attitude is the same as ever");
- of like kind ("you are exactly the same as your mother");
while "the same object" has specifically the first meaning.
How do you know that two objects are the same object? It isn't because they are
equal, or that they look vaguely the same. "Equal" is not equivalent to "the
same object":
py> a, b = [], [] # they sure look the same...
py> a == b
True
py> a.append(None) # insert None into a
py> None in b # but they aren't the same object
False
The only way to find out if two objects are the same object is to ask Python --
and Python is under no obligation to comply with your naïve intuitions about
objects. As you are well aware, because we've told you many times, Python often
caches objects so that they are reused rather than being recreated from scratch
when needed -- and it is free to do so in implementation and version dependent
ways.
>> > In fact we have got so used to the term 'memory' that it actually seems
>> > strange when someone like Dijkstra grumbles at the anthropomorphism and
>> > asks why its not called 'store'.
>>
>> And if it were called "store" (grocery store? shoe store? clothes store?)
>> Dijkstra would have grumbled at the metaphor and asked why it wasn't
>> called "memory".
>
> Memory is an old (middle-English) word.
> Until say 1945 it could be used in sentences like the following
> “I have memories of walking in the woods with my dad”
> “Where are the eggs?” “Oops! Totally slipped my memory… Sorry"
> “The Dalai Lama has memories of his past lives”
I don't understand why you say "until 1945". You can still use memory in those
ways even today.
> Are you using ‘memory’ in this kind of way?
Yes.
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 1:12:22 PM UTC+1, Rustom Mody wrote: > On Wednesday, September 6, 2017 at 5:08:20 PM UTC+5:30, Steve D'Aprano wrote: > > On Wed, 6 Sep 2017 07:13 pm, Rustom Mody wrote: > > > > > > > Can you explain what "id" and "is" without talking of memory? > > > > Yes. > > > > id() returns an abstract ID number which is guaranteed to be an integer, and > > guaranteed to be distinct for all objects which exist at the same time. > > When an > > object ceases to exist, its ID number may be re-used. > > > > `is` compares the two operands for identity. If the two operands are the > > same > > object, `is` returns True, if they are distinct objects, `is` returns False. > > >>> a = (1,2) > >>> b = (1,2) > >>> a is b > False > >>> x = 1 > >>> y = 1 > >>> x is y > True > > a seems to be as 'same' to b as x is to y > Python seems to think otherwise > > Evidently your ‘same’ is not the same as mine?? > This shows your complete ignorance of Python. One would often suggest putting the shovel down, but it is far too late for that. Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On 06-09-17 15:14, Stefan Ram wrote: > Steve D'Aprano writes: >> or any of the other things we can do in a language with references-as-values, >> like C or Pascal. > > I have always taken the stance that one has to use the words > as the language specification of the language one talks > about does. > But that makes it difficult to point to similar semantics in two languages, when those languages use different wording to express those semantics. -- Antoon Pardon. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Op 06-09-17 om 14:58 schreef Steve D'Aprano:
> On Wed, 6 Sep 2017 05:12 pm, Antoon Pardon wrote:
>
> [...]
>>> I'm not saying that we should never use this model. Its a good model. But we
>>> should be clear that it is a model of the implementation, and it describes
>>> entities which are not part of the Python language. We cannot do this:
>>>
>>>
>>> +-+
>>> | |
>>> | 5 |
>>> | |
>>> +-+
>>> ^
>>> |
>>>
>>> ^
>>> |
>>>
>>>
>>>
>>> or any of the other things we can do in a language with
>>> references-as-values,
>>> like C or Pascal.
>> I don't agree that the above is an accurate picture of C or Pascal.
> I'm surprised. You can do this in Pascal:
>
> type
> intpointer = ^integer;
> var
> x: intpointer;
> y: ^intpointer;
> begin
> new(x); {reserve memory in the heap for an integer, and point x at it}
> x^ := 5;
> y := @x; {y points to the pointer x}
> end.
>
> which would translate to the diagram above. If you don't like the fact that
> I'm
> using the "address of" operator @ which is non-standard Pascal, I can write
> this instead:
No it would not translate to the above diagram. It would translate to my
diagram.
All variables in pascal refer to some object (in memory), they don't refer to
other variables. If you have a pointer variable, you have a variable that refers
to an object that itself refers to an other object. This later object can be
one that is refered to directly by another variable, like code as above.
>
>
> type
> intpointer = ^integer;
> var
> y: ^intpointer;
> begin
> new(y); {reserve memory in the heap for an intpointer, and point y at it}
> new(y^); {reserve memory in the heap for an integer, and point y^ at it}
> y^^ := 5;
> end.
>
> I would be shocked if C were less powerful in this regard than Pascal.
That would be result in the following diagram.
+-+ +-+ +-+
| | | | | |
| *--+>| *--+->| 5 |
| | | | | |
+-+ +-+ +-+
^
|
>> And in case of a VAR parameter in Pascal like
>>
>> procedure f(VAR x);
>> f(y)
>>
>> one could use the following, which is the same
>> as after an assignment in python.
>>
>>
>> +-+
>> | |
>> | 7 |
>> ---> | |
>>/ +-+
>> /
>> / ^
>> /|
>>
> No no no! Pascal VAR parameters are not the same as Python assignment! You
> cannot write a Pascal swap procedure in Python!
Yes it is. Pascal VAR parameters are exactly like Python a assignment. The
fact that you can't write a swap procedure in Python is because the
semantics of the Python assignment differs from the semantics of the Pascal
assignment. Not because the VAR parameter semantics in Pascal differ from
the parameter or assignment semantics in Python.
The semantics of the VAR parameter in Pascal and the sematics of Python
assignment are both creating a new alias for the same object or however you
want to phrase it.
--
Antoon Pardon
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On 06/09/17 14:02, Stefan Ram wrote: Chris Angelico writes: The 'is' operator tests if two things are the same thing. »Roughly speaking, to say of two things that they are identical is nonsense, and to say of one thing that it is identical with itself is to say nothing at all.« Ludwig Wittgenstein, Tractatus Logico-Philosophicus (5.5303) Irrelevant. We are talking about identity, not identicallity (to coin a word). Or in plainer English, asking if two things are the same thing is not the same as asking if two things are identical. -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wed, Sep 6, 2017 at 11:02 PM, Stefan Ram wrote: > Chris Angelico writes: >>The 'is' operator tests if two things are the same thing. > > »Roughly speaking, to say of two things that they are > identical is nonsense, and to say of one thing that it > is identical with itself is to say nothing at all.« > > Ludwig Wittgenstein, Tractatus Logico-Philosophicus (5.5303) Yes, and the expression "x is x" is indeed saying nothing at all. But it's perfectly reasonable, in English, to make statements like: "Talldad is my father." "This is my box." (It's not purrfect, but it's mine. [1]) "The President of the US is FD Roosevelt." Each one corresponds to a Python statement of identity: print(talldad is self.father) print(self is chii.box) print(usa.president is fdr) In the case of Talldad, one side is absolute and the other side is relative. (Yes, my father is my relative. Whodathunk?) For a given 'self', the statement will always be consistent. In the case of the president of the US, it's an attribute that gets reassigned periodically, so the statement may be true one day and false another. But it's still fully reasonable to have an absolute identifier for a specific person, and to ask if that refers to the same individual as some relative or time-dependent identifier/alias. ChrisA [1] https://www.redbubble.com/people/devicatoutlet/works/27806715-this-is-my-box -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wed, 6 Sep 2017 05:12 pm, Antoon Pardon wrote:
[...]
>> I'm not saying that we should never use this model. Its a good model. But we
>> should be clear that it is a model of the implementation, and it describes
>> entities which are not part of the Python language. We cannot do this:
>>
>>
>> +-+
>> | |
>> | 5 |
>> | |
>> +-+
>> ^
>> |
>>
>> ^
>> |
>>
>>
>>
>> or any of the other things we can do in a language with references-as-values,
>> like C or Pascal.
>
> I don't agree that the above is an accurate picture of C or Pascal.
I'm surprised. You can do this in Pascal:
type
intpointer = ^integer;
var
x: intpointer;
y: ^intpointer;
begin
new(x); {reserve memory in the heap for an integer, and point x at it}
x^ := 5;
y := @x; {y points to the pointer x}
end.
which would translate to the diagram above. If you don't like the fact that I'm
using the "address of" operator @ which is non-standard Pascal, I can write
this instead:
type
intpointer = ^integer;
var
y: ^intpointer;
begin
new(y); {reserve memory in the heap for an intpointer, and point y at it}
new(y^); {reserve memory in the heap for an integer, and point y^ at it}
y^^ := 5;
end.
I would be shocked if C were less powerful in this regard than Pascal.
> It is more
> like the following:
>
> +-+ +-+
> | | | |
> | 5 |<+--* |
> | | | |
> +-+ +-+
> ^ ^
> | |
>
That would be equivalent to a different piece of code:
type
intpointer = ^integer;
var
x: intpointer;
y: ^intpointer;
begin
new(x); {reserve memory in the heap for an integer, and point x at it}
x^ := 5;
new(y); {reserve memory in the heap for an intpointer, and point y at it}
y^ := x; {assignment copies; y^ now points to the same thing as x}
end.
These two are not the same thing.
> And in case of a VAR parameter in Pascal like
>
> procedure f(VAR x);
> f(y)
>
> one could use the following, which is the same
> as after an assignment in python.
>
>
> +-+
> | |
> | 7 |
> ---> | |
>/ +-+
> /
> / ^
> /|
>
No no no! Pascal VAR parameters are not the same as Python assignment! You
cannot write a Pascal swap procedure in Python!
Pascal VAR parameters are, in a sense, syntactic sugar for pointer manipulation.
(I'm not sure just how far we can take this analogy, but I think its pretty
far.) That's probably why C didn't bother with VAR parameters: anything you can
do with a VAR parameter, you can do with explicit pointers.
I think that these two increment procedures will be (more or less?) equivalent:
type
intpointer = ^integer;
procedure increment(var n: integer);
begin
n := n + 1
end;
procedure increment2(p: intpointer);
begin
p^ := p^ + 1
end;
var
a: integer;
b: integer;
begin
a := 99;
increment(a);
writeln(a); {will print 100}
b := 99;
increment2(@b);
writeln(b); {will print 100}
end.
If there's a difference, its a subtle one which I haven't found in a short
amount of testing.
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wed, Sep 6, 2017 at 10:44 PM, Rustom Mody wrote: > On Wednesday, September 6, 2017 at 5:48:48 PM UTC+5:30, Chris Angelico wrote: >> On Wed, Sep 6, 2017 at 10:11 PM, Rustom Mody wrote: >> a = (1,2) >> b = (1,2) >> a is b >> > False >> x = 1 >> y = 1 >> x is y >> > True >> > >> > a seems to be as 'same' to b as x is to y >> > Python seems to think otherwise >> > >> > Evidently your ‘same’ is not the same as mine?? >> >> *facepalm* >> >> I got nothing to say to you. Have you been on this list all this time >> and still don't understand that Python sometimes optimizes immutables? > > Losing 'memory' of context Chris? > Let me erm… remind: > > I said 'is' refers to "same in machine representation" > > Greg disagreed: « "is" in Python has an abstract definition that > doesn't depend on machine representation.» > > I said: In that case please restate the definition of 'is' from the manual > which > invokes the notion of 'memory' without bringing in memory. > > Steven gave his explanation by dropping 'memory' and gave a definition > > Which I showed does not match expected common sense > > Sure you can bring in the notion (now!) of optimization if you like > But you cant have it both ways > - 'is' is a fundamental conceptual notion of sameness > - 'is' is a machine/implementation specific notion of sameness which changes > depending on machine/implementation specific decisions Okay. Lemme spell it out for you real easy. The 'is' operator tests if two things are the same thing. Okay? With me so far? Good. No mention of memory. Next, we have an optimization: Sometimes, Python uses the same object more than once. You can't distinguish one integer 1 from another other than by their ids, so Python is free to use the same integer object for both uses of 1. Clear? Still no mention of memory anywhere. And it doesn't violate any conceptual notion of sameness. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 5:48:48 PM UTC+5:30, Chris Angelico wrote: > On Wed, Sep 6, 2017 at 10:11 PM, Rustom Mody wrote: > > On Wednesday, September 6, 2017 at 5:08:20 PM UTC+5:30, Steve D'Aprano > > wrote: > >> On Wed, 6 Sep 2017 07:13 pm, Rustom Mody wrote: > >> > >> > >> > Can you explain what "id" and "is" without talking of memory? > >> > >> Yes. > >> > >> id() returns an abstract ID number which is guaranteed to be an integer, > >> and > >> guaranteed to be distinct for all objects which exist at the same time. > >> When an > >> object ceases to exist, its ID number may be re-used. > >> > >> `is` compares the two operands for identity. If the two operands are the > >> same > >> object, `is` returns True, if they are distinct objects, `is` returns > >> False. > > > a = (1,2) > b = (1,2) > a is b > > False > x = 1 > y = 1 > x is y > > True > > > > a seems to be as 'same' to b as x is to y > > Python seems to think otherwise > > > > Evidently your ‘same’ is not the same as mine?? > > *facepalm* > > I got nothing to say to you. Have you been on this list all this time > and still don't understand that Python sometimes optimizes immutables? Losing 'memory' of context Chris? Let me erm… remind: I said 'is' refers to "same in machine representation" Greg disagreed: « "is" in Python has an abstract definition that doesn't depend on machine representation.» I said: In that case please restate the definition of 'is' from the manual which invokes the notion of 'memory' without bringing in memory. Steven gave his explanation by dropping 'memory' and gave a definition Which I showed does not match expected common sense Sure you can bring in the notion (now!) of optimization if you like But you cant have it both ways - 'is' is a fundamental conceptual notion of sameness - 'is' is a machine/implementation specific notion of sameness which changes depending on machine/implementation specific decisions Of course you can have a third hand… Its usually called sophistry The trouble with sophistrizing is that you get caught in your own net: You (and Steven) claim that references (and aliases such as pointers) can be expunged from the language semantics. If you do that the term 'memory' remains standalone without any semantics. And when you make a bogus expulsion of that as well, extant behavior becomes unexplainable… Except with a… (which I share) *facepalm* -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 4:03:40 PM UTC+5:30, ROGER GRAYDON CHRISTMAN
wrote:
> On 5 Sep 2017 14:28:44, (Dennis Lee Bier) wrote:
> > On 5 Sep 2017 17:57:18 GMT,
> >> But what does "a C++ reference" refer to?
> >>
>
> > Per Stroustrup (The C++ Programming Language 4th Ed, page 189)
>
> > """
> > * ...> * A reference always refers to the object to which it was
> > initialized.
> > * ...
>
> > A reference is an alternative name for an object, an alias. ...
> > """
>
> > {Hmmm, and I see that the syntax can be used outside of parameter
> > declaration -- which is the only place I'd seen it previously... either
> > this is a change from earlier standards, or my classes just didn't feel the
> > need to expose a non-parameter reference -- since, based upon the above
> > book, you can not declare a bare reference "variable"; it MUST be
> > initialized with a real object.}
>
> I think I can say something about this, having been a teacherof the classes
> you refer to. I intentionally avoided reference variables.
> IMO, the 'good' use for declaring a new reference variable (i.e. not
> parameter)would be when (1) the object to which you refer to is
> time-consuming to access(2) you plan to refer to this object more then once,
> and don't want to repeatthat time-consuming process, and (3) you really want
> a reference, and not a copy.
> The first two years of programming courses really do not have a purposethat
> meets all three, so can "didn't feel the need" is probably applicable.
> I intentionally avoided them because reference variables simply compoundthe
> problem of aliasing, so unless you really limit your reference variableto a
> very tight sandbox, you could be causing more headache than you save.
> I do admit to occasionally defining a method that returned a reference,such
> as one that overloads the [] operator. But even so, I would generallybe
> reluctant to giving an outside client a direct access to my
> database'sinternal structures. (Thank you Python for separating __getitem__
> and __setitem__)
> Python doesn't eliminate aliasing, of course, since most assignment
> operationscreate aliases. But at least it's nice to know that aliasing
> immutable valuesis harmless. Hence my unit on building recursive data
> structures entirelyout of tuples.
The realization that immutability is a significant virtue is now beginning
to percolate mainstream programming
Ive seen it in recent C# books as a definite recommendation… Something like
- Use value types
- Use getters but no setters
And you have a good design
Python makes this hard by giving less status to immutable types than mutable
ones
- set comprehensions exist not frozenset comprehensions
- Likewise tuples and lists
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
https://www.youtube.com/watch?v=pNe1wWeaHOU&list=PLYI8318YYdkCsZ7dsYV01n6TZhXA6Wf9i&index=1 Thank you, -Alex Goretoy http://launchpad.net/~a1g On Wed, Sep 6, 2017 at 7:18 PM, Chris Angelico wrote: > On Wed, Sep 6, 2017 at 10:11 PM, Rustom Mody wrote: >> On Wednesday, September 6, 2017 at 5:08:20 PM UTC+5:30, Steve D'Aprano wrote: >>> On Wed, 6 Sep 2017 07:13 pm, Rustom Mody wrote: >>> >>> >>> > Can you explain what "id" and "is" without talking of memory? >>> >>> Yes. >>> >>> id() returns an abstract ID number which is guaranteed to be an integer, and >>> guaranteed to be distinct for all objects which exist at the same time. >>> When an >>> object ceases to exist, its ID number may be re-used. >>> >>> `is` compares the two operands for identity. If the two operands are the >>> same >>> object, `is` returns True, if they are distinct objects, `is` returns False. >> > a = (1,2) > b = (1,2) > a is b >> False > x = 1 > y = 1 > x is y >> True >> >> a seems to be as 'same' to b as x is to y >> Python seems to think otherwise >> >> Evidently your ‘same’ is not the same as mine?? > > *facepalm* > > I got nothing to say to you. Have you been on this list all this time > and still don't understand that Python sometimes optimizes immutables? > > ChrisA > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wed, Sep 6, 2017 at 10:11 PM, Rustom Mody wrote: > On Wednesday, September 6, 2017 at 5:08:20 PM UTC+5:30, Steve D'Aprano wrote: >> On Wed, 6 Sep 2017 07:13 pm, Rustom Mody wrote: >> >> >> > Can you explain what "id" and "is" without talking of memory? >> >> Yes. >> >> id() returns an abstract ID number which is guaranteed to be an integer, and >> guaranteed to be distinct for all objects which exist at the same time. When >> an >> object ceases to exist, its ID number may be re-used. >> >> `is` compares the two operands for identity. If the two operands are the same >> object, `is` returns True, if they are distinct objects, `is` returns False. > a = (1,2) b = (1,2) a is b > False x = 1 y = 1 x is y > True > > a seems to be as 'same' to b as x is to y > Python seems to think otherwise > > Evidently your ‘same’ is not the same as mine?? *facepalm* I got nothing to say to you. Have you been on this list all this time and still don't understand that Python sometimes optimizes immutables? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 5:08:20 PM UTC+5:30, Steve D'Aprano wrote: > On Wed, 6 Sep 2017 07:13 pm, Rustom Mody wrote: > > > > Can you explain what "id" and "is" without talking of memory? > > Yes. > > id() returns an abstract ID number which is guaranteed to be an integer, and > guaranteed to be distinct for all objects which exist at the same time. When > an > object ceases to exist, its ID number may be re-used. > > `is` compares the two operands for identity. If the two operands are the same > object, `is` returns True, if they are distinct objects, `is` returns False. >>> a = (1,2) >>> b = (1,2) >>> a is b False >>> x = 1 >>> y = 1 >>> x is y True a seems to be as 'same' to b as x is to y Python seems to think otherwise Evidently your ‘same’ is not the same as mine?? > > > In fact we have got so used to the term 'memory' that it actually seems > > strange when someone like Dijkstra grumbles at the anthropomorphism and asks > > why its not called 'store'. > > And if it were called "store" (grocery store? shoe store? clothes store?) > Dijkstra would have grumbled at the metaphor and asked why it wasn't > called "memory". Memory is an old (middle-English) word. Until say 1945 it could be used in sentences like the following “I have memories of walking in the woods with my dad” “Where are the eggs?” “Oops! Totally slipped my memory… Sorry" “The Dalai Lama has memories of his past lives” Are you using ‘memory’ in this kind of way? -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wed, 6 Sep 2017 07:13 pm, Rustom Mody wrote: > Can you explain what "id" and "is" without talking of memory? Yes. id() returns an abstract ID number which is guaranteed to be an integer, and guaranteed to be distinct for all objects which exist at the same time. When an object ceases to exist, its ID number may be re-used. `is` compares the two operands for identity. If the two operands are the same object, `is` returns True, if they are distinct objects, `is` returns False. > In fact we have got so used to the term 'memory' that it actually seems > strange when someone like Dijkstra grumbles at the anthropomorphism and asks > why its not called 'store'. And if it were called "store" (grocery store? shoe store? clothes store?) Dijkstra would have grumbled at the metaphor and asked why it wasn't called "memory". -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Steven D'Aprano wrote: Not in standard Pascal, but most actual Pascal compilers let you perform pointer arithmetic. Well, sort of. In the ones I've seen, it's more like being able to cast a pointer to an integer, do arithmetic on that and then cast it back. The results are about as implementation-dependent as that suggests. C, on the other hand, allows arithmetic operations on pointers directly and defines their semantics (up to a point, you can fall off into undefined territory fairly easily). -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Steven D'Aprano wrote: But many (perhaps even most) people have no problem dealing with location as a metaphor, where being in two places (metaphorically) is no problem at all: - I am in love, in trouble and in denial all at once. Sometimes the word "in" implies physical location, sometimes it doesn't. Being a member of more than one list is a familiar enough concept, for example, although one would probably say "on a list" rather than "in a list". However, "on a list" doesn't really conjure up an image of physical location. We wouldn't picture ourselves standing on a piece of paper; rather, we would imagine our name or other piece of identifying information being written on the paper. Dare I say... we would think of a *reference* to us being on the list? :-) Even when the location is not a state of being but an actual physical place, we can be in multiple places at once: - I am in my home, in Melbourne, and in Australia all at once. That's only non-weird because there is a nesting relationship between those locations. It doesn't extend to more general topologies. For example, if your home is in Melbourne, then being in your home and Australia but *not* in Melbourne would be an interesting trick. Being in two places at once is a common trope in both fantasy and science fiction (often involving time travel). And they're interesting plot devices precisely because they defy our physical intuition so much. If you're trying to deconfuse someone about Python semantics, tying their brain up in knots doesn't seem like a very productive approach! -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On 05/09/17 23:29, Grant Edwards wrote: On 2017-09-05, Marko Rauhamaa wrote: Pointer arithmetics is not an essential part of C. One could argue that it was a mistake to include it in the language. One may argue that it was a mistake, but I remember at least one implementation where pointer arithmetic was hugely more efficient than indexing into arrays. Incrementing a pointer through an array was way, way faster than indexing through the array by incrementing an array subscript. But, that was 25 years ago on an 8-bit CPU where where integer multiplies were expensive. The last time I compare the two methods with a recent GCC on a 32-bit CPU, it generated pretty much the same code either way... That's the optimiser at work, turning what you wrote into the best fit to the processor architecture. On an ARM, for example, that would likely still be incrementing a pointer through an array. -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On 5 Sep 2017 14:28:44, wlfr...@ix.netcom.com (Dennis Lee Bier) wrote:
> On 5 Sep 2017 17:57:18 GMT, https://webmail.psu.edu/webmail/retrieve.cgi?mailbox=inbox&start_num=14200&limit=50&sort=0&display=4×tamp=20170906045729&mid=mailman%2e%2e1504662834%2e2732%2epython%2dlist%40python%2eorg#";>r...@zedat.fu-berlin.de
(Stefan Ram)
> declaimed the following:
>> But what does "a C++ reference" refer to?
>>
> Per Stroustrup (The C++ Programming Language 4th Ed, page 189)
> """
> * ...> * A reference always refers to the object to which it was initialized.
> * ...
> A reference is an alternative name for an object, an alias. ...
> """
> {Hmmm, and I see that the syntax can be used outside of parameter
> declaration -- which is the only place I'd seen it previously... either
> this is a change from earlier standards, or my classes just didn't feel the
> need to expose a non-parameter reference -- since, based upon the above
> book, you can not declare a bare reference "variable"; it MUST be
> initialized with a real object.}
I think I can say something about this, having been a teacherof the classes you
refer to. I intentionally avoided reference variables.
IMO, the 'good' use for declaring a new reference variable (i.e. not
parameter)would be when (1) the object to which you refer to is time-consuming
to access(2) you plan to refer to this object more then once, and don't want to
repeatthat time-consuming process, and (3) you really want a reference, and not
a copy.
The first two years of programming courses really do not have a purposethat
meets all three, so can "didn't feel the need" is probably applicable.
I intentionally avoided them because reference variables simply compoundthe
problem of aliasing, so unless you really limit your reference variableto a
very tight sandbox, you could be causing more headache than you save.
I do admit to occasionally defining a method that returned a reference,such as
one that overloads the [] operator. But even so, I would generallybe
reluctant to giving an outside client a direct access to my database'sinternal
structures. (Thank you Python for separating __getitem__ and __setitem__)
Python doesn't eliminate aliasing, of course, since most assignment
operationscreate aliases. But at least it's nice to know that aliasing
immutable valuesis harmless. Hence my unit on building recursive data
structures entirelyout of tuples.
Roger ChristmanPennsylvania Sate University
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wed, Sep 6, 2017 at 7:13 PM, Rustom Mody wrote: > On Wednesday, September 6, 2017 at 12:51:25 PM UTC+5:30, Gregory Ewing wrote: >> Rustom Mody wrote: >> > 2. is — machine representation, too fine to be useful >> >> Disagree - "is" in Python has an abstract definition that >> doesn't depend on machine representation. >> >> -- >> Greg > > There is this (AFAIAC sophistry) in the docs describing the data model > https://docs.python.org/3/reference/datamodel.html > > | Every object has an identity, a type and a value. An object’s identity never > | changes once it has been created; you may think of it as the object’s > address > | in memory. The ‘is’ operator compares the identity of two objects; the id() > | function returns an integer representing its identity. > > | CPython implementation detail: For CPython, id(x) is the memory address > where > | x is stored. > > Can you explain what "id" and "is" without talking of memory? Yes, easily. Just delete the "CPython implementation detail" section and the "you may think of it" part from that quote and let the rest stand alone. None of the rest of that document depends on memory addresses. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wed, Sep 6, 2017 at 7:01 PM, Gregory Ewing wrote: > Chris Angelico wrote: >> >> You can't do this with Python, since pointer arithmetic fundamentally >> doesn't exist. > > > Pointer arithmetic doesn't exist in Pascal either, yet > Pascal most definitely has pointers as a distinct data > type. > > Insisting that only pointer arithmetic counts as > "manipulating" pointers seems a strange way of defining > the word. Understood. I'm withdrawing the assertion that pointer arithmetic is essential, weakening the demand to the ability to: 1) Take the address of an object (yielding a pointer) 2) Move the pointer around as its own thing, eg pass it as a function parameter 3) Dereference the pointer, to read or write the original object But you have to be able to prove that #2 is actually looking at the pointer as its own entity. This has to be distinct from passing around the object itself in some way. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 12:51:25 PM UTC+5:30, Gregory Ewing wrote: > Rustom Mody wrote: > > 2. is — machine representation, too fine to be useful > > Disagree - "is" in Python has an abstract definition that > doesn't depend on machine representation. > > -- > Greg There is this (AFAIAC sophistry) in the docs describing the data model https://docs.python.org/3/reference/datamodel.html | Every object has an identity, a type and a value. An object’s identity never | changes once it has been created; you may think of it as the object’s address | in memory. The ‘is’ operator compares the identity of two objects; the id() | function returns an integer representing its identity. | CPython implementation detail: For CPython, id(x) is the memory address where | x is stored. Can you explain what "id" and "is" without talking of memory? In fact we have got so used to the term 'memory' that it actually seems strange when someone like Dijkstra grumbles at the anthropomorphism and asks why its not called 'store'. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Chris Angelico wrote: You can't do this with Python, since pointer arithmetic fundamentally doesn't exist. Pointer arithmetic doesn't exist in Pascal either, yet Pascal most definitely has pointers as a distinct data type. Insisting that only pointer arithmetic counts as "manipulating" pointers seems a strange way of defining the word. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Steve D'Aprano wrote:
No, they aren't first-class.
Maybe not fully, but you can do a lot more with them
than you can in Pascal or Modula-2.
- Containers of references are not allowed.
You can't have arrays of references, but struct and class
members can be references, so you can certainly build data
structures that contain them.
(A quick experiment suggests that you can even have arrays
of structs that contain references, so I'm not sure why
they're not allowed in arrays directly.)
- Once a reference to an object is created, it cannot be changed to
reference another object ("to be reseated").
Actually there is a way to do that, but you have to be
sneaky about it.
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Rustom Mody wrote: 2. is — machine representation, too fine to be useful Disagree - "is" in Python has an abstract definition that doesn't depend on machine representation. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Op 04-09-17 om 17:43 schreef Steve D'Aprano: > On Tue, 5 Sep 2017 01:17 am, Rustom Mody wrote: > >> Anton gave a picture explaining why/how references are needed and to be >> understood > Antoon gave a picture demonstrating one model of Python's semantics. > > It's a nice model that has a lot going for it, in particular that it matches > the > most obvious implementation. But it doesn't describe *Python* semantics, it > describes an overlap between Python the language and the implementation of the > Python interpreter. > > In particular, consider the picture of a name binding to a value: > > > +-+ > | | > | 5 | > | | > +-+ > ^ > | > > > > This picture has three entities, but only two of them exist in Python: > > - the object 5; > > - the name "x" (names are not values in Python at runtime, but they > are entities which exist in Python source code at compile time). > > The third entity is the reference linking the name to the object (the arrow). > This isn't a runtime value in Python, nor is it a compile time entity that > exists in source code. It is pure implementation, and as such, exists outside > of the Python domain. > > I'm not saying that we should never use this model. Its a good model. But we > should be clear that it is a model of the implementation, and it describes > entities which are not part of the Python language. We cannot do this: > > > +-+ > | | > | 5 | > | | > +-+ > ^ > | > > ^ > | > > > > or any of the other things we can do in a language with references-as-values, > like C or Pascal. I don't agree that the above is an accurate picture of C or Pascal. It is more like the following: +-+ +-+ | | | | | 5 |<+--* | | | | | +-+ +-+ ^ ^ | | And in case of a VAR parameter in Pascal like procedure f(VAR x); f(y) one could use the following, which is the same as after an assignment in python. +-+ | | | 7 | ---> | | / +-+ / / ^ /| -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wed, 06 Sep 2017 01:04:17 +0300, Marko Rauhamaa wrote: > Chris Angelico : > >> That shows that the Java '==' operator is like the Python 'is' >> operator, and checks for object identity. You haven't manipulated >> pointers at all. In contrast, here's a C program that actually >> MANIPULATES pointers: >> >> [...] >> >> You can't do this with Python, since pointer arithmetic fundamentally >> doesn't exist. You can in C. Can you in Java? A necessary (but not sufficient) condition to be able to do pointer arithmetic is to actually have pointers as a data type. Pointers are not a data type in either Python or Java, so of course you can't do pointer arithmetic on them. If you don't have a pointer, you can't do arithmetic on it. Pointer arithmetic itself is not the issue. Java could have been like standard Pascal, and allow pointers as a first class data type (you can assign them to variables, pass them to functions, return them, have pointers to pointers, etc) without allowing pointer arithmetic. But they didn't -- Java the language doesn't include pointers as a value at all. > You can't do it in Pascal, either, but Pascal definitely has pointers. Not in standard Pascal, but most actual Pascal compilers let you perform pointer arithmetic. -- Steven D'Aprano “You are deluded if you think software engineers who can't write operating systems or applications without security holes, can write virtualization layers without security holes.” —Theo de Raadt -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Tue, 05 Sep 2017 21:17:30 -0700, Rustom Mody wrote: > Sure you can say with Steven that this can be 'explained' by saying an > object can be in two places at one time. > Others would then say 'Humpty-dumpty!' since you have removed the most > basic intuition of objects and you are in effect saying that a python > object means what you ordain it means without further ado/explanation I have previously agreed that the "multiple places at once" metaphor is not to everyone's liking. But many (perhaps even most) people have no problem dealing with location as a metaphor, where being in two places (metaphorically) is no problem at all: - I am in love, in trouble and in denial all at once. Even when the location is not a state of being but an actual physical place, we can be in multiple places at once: - I am in my home, in Melbourne, and in Australia all at once. Being in two places at once is a common trope in both fantasy and science fiction (often involving time travel). These are not niche genres: they are *extremely* popular. One of the Harry Potter movies involved Harry, Ron and Hermoine travelling backwards in time a few minutes to watch themselves. It's a moderately common trope in stories like Doctor Who, where the Doctor frequently interacts with his past (or future) self. I recently saw an episode of Dark Matter that used the trope. Robert Heinlein, one of the greats of SF, wrote a number of classic time travel stories involving people being in multiple places at once. (In one of them, the protagonist has a sex change and becomes *both* his own grandfather and grandmother.) An object being inside itself is rarer, but its been done at least twice that I know of in Doctor Who. Don't underestimate people's ability to stretch the location metaphor beyond actual physical location. We do it all the time for virtual locations like IRC channels: - I'm in #python, #ruby and #javascript all at once. But if the metaphor isn't for you, I'm not saying you have to use it. -- Steven D'Aprano “You are deluded if you think software engineers who can't write operating systems or applications without security holes, can write virtualization layers without security holes.” —Theo de Raadt -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wed, 06 Sep 2017 03:42:31 +, Stefan Ram wrote:
> Well, this /is/ from the PRL:
>
> »An object's identity never changes once it has been created;
> you may think of it as the object's address in memory.«.
> ¯¯
> - The Python Language Reference, Release 3.6.0;
> 3.1 Objects, values and types
>
> It's not called "reference", it's called "identity". But it might
> agree with your idea of a pointer of an implementation.
> And you /can/ print it.
>
print( id( 'abc' ))
> 4163144
I just tried that in my handy Python interpreter:
steve@runes:~$ jython
Jython 2.5.3 (, Jun 21 2017, 18:05:17)
[OpenJDK 64-Bit Server VM (Oracle Corporation)] on java1.7.0_151
Type "help", "copyright", "credits" or "license" for more information.
>>> print id("abcd")
2
>>> print id("abcd")
3
>>> print id(None)
4
Do they look like pointers or references to you? They don't to me. I'm
not aware of any machine where pointers can point to odd numbers
(although there probably are some) and I'm certainly not aware of any
where consecutive pointers differ by 1.
I think the manual is badly worded. It is true that we *can* think of IDs
as the address of objects in memory, we *shouldn't* because that's
misleading and tempts the reader to draw the wrong conclusion.
IDs in Python are arbitrary integers. They have no meaning except to be
distinct for any two objects existing at the same time.
--
Steven D'Aprano
“You are deluded if you think software engineers who can't write
operating systems or applications without security holes, can write
virtualization layers without security holes.” —Theo de Raadt
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Rustom Mody : > On Wednesday, September 6, 2017 at 3:34:41 AM UTC+5:30, Marko Rauhamaa wrote: >> Pointer arithmetics is not an essential part of C. One could argue that >> it was a mistake to include it in the language. > > This is subjective of course… but still I wonder where you are coming from… > > You of course know that writing Unix was the genesis and raison d'être > for C right? > > And what is an OS but a thin layer of abstraction on top of bare ISP? > ie is not a Linux-OS just an x86 hw + some new ‘instructions’ called > system-calls? BASIC doesn't have any pointers at all, but it has PEEK and POKE. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 9:55:10 AM UTC+5:30, Chris Angelico wrote: > On Wed, Sep 6, 2017 at 2:17 PM, Rustom Mody wrote: > > Well ⅓ the point of pointers may be printing them out — which even in a > > language > > with 1st class pointers like C is rarely done/needed > > But still the useless part. You don't actually *achieve* anything by > printing out the pointer. > > > Another ⅓ is dereferencing, pointer-arithmetic etc... the various > > manifestations > > of 1st-class pointers > > This is the part that matters. > > > And the third ⅓ is to provide explanations to people asking authentic > > questions > > [like the OP of this thread] > > Only questions that actually relate to one of the previous parts. [dangling pointer ?¿?¿ ] > > > Sure you can say with Steven that this can be 'explained' by saying an > > object > > can be in two places at one time. > > Others would then say 'Humpty-dumpty!' since you have removed the most basic > > intuition of objects and you are in effect saying that a python object > > means what you ordain it means without further ado/explanation > > > > Since you believe a reference-less dictionary can be a model for such > > explanations, > > why not provide that? > > A piece of paper works just fine. However, it's hard to use that > method of explanation in an email. I am ready to bet that if ASCII is insufficient then you are drawing pictures You can call them whatever you like - pointers, references - data structure diagrams - graphs vertices, edges - I think I'll call them Antoon-art in honor of Antoon Pardon who has the patience to draw them I believe it was Marko Rauhamaa who have another half dozen metaphors: - doggies and pussies er.. sorry leashes Whatever you use, you will have to reify in your explanation the idea of pointer/graph-edge/etc even and especially because, the language disallows such a reification -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wed, Sep 6, 2017 at 2:17 PM, Rustom Mody wrote: > Well ⅓ the point of pointers may be printing them out — which even in a > language > with 1st class pointers like C is rarely done/needed But still the useless part. You don't actually *achieve* anything by printing out the pointer. > Another ⅓ is dereferencing, pointer-arithmetic etc... the various > manifestations > of 1st-class pointers This is the part that matters. > And the third ⅓ is to provide explanations to people asking authentic > questions > [like the OP of this thread] Only questions that actually relate to one of the previous parts. > Sure you can say with Steven that this can be 'explained' by saying an object > can be in two places at one time. > Others would then say 'Humpty-dumpty!' since you have removed the most basic > intuition of objects and you are in effect saying that a python object > means what you ordain it means without further ado/explanation > > Since you believe a reference-less dictionary can be a model for such > explanations, > why not provide that? A piece of paper works just fine. However, it's hard to use that method of explanation in an email. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 9:22:15 AM UTC+5:30, Chris Angelico wrote: > On Wed, Sep 6, 2017 at 1:42 PM, Stefan Ram wrote: > > Steve D'Aprano writes: > >>So in what sense are references part of the Python language? > > > > It would be possible to describe Python using a concept > > called "reference", it's just that the The Python Language > > Reference, Release 3.6.0 (PRL) does /not/ do this. > > And programming language experts usually use the terms that > > the language specification uses with the meaning that the > > language specification is giving them. And this is why I say > > that JavaScript and Python do not have references. > > (Except "attribute references".) > > > >>Inside the interpreter, you (probably?) could print out the value of the > >>pointer, or manipulate it in some fashion. > > > > Well, this /is/ from the PRL: > > > > »An object's identity never changes once it has been created; > > you may think of it as the object's address in memory.«. > > ¯¯ > > - The Python Language Reference, Release 3.6.0; > > 3.1 Objects, values and types > > > > It's not called "reference", it's called "identity". But it > > might agree with your idea of a pointer of an implementation. > > And you /can/ print it. > > > print( id( 'abc' )) > > 4163144 > > Printing out an address is only half the point (pun intended) of a > pointer - and the useless half. Given a pointer, you need to be able > to dereference it. How can you, given the id of a Python object, > access the object itself? The nearest I've ever seen is a function > that searches every object it can find, looking for one with the same > id. Well ⅓ the point of pointers may be printing them out — which even in a language with 1st class pointers like C is rarely done/needed Another ⅓ is dereferencing, pointer-arithmetic etc... the various manifestations of 1st-class pointers And the third ⅓ is to provide explanations to people asking authentic questions [like the OP of this thread] Sure you can say with Steven that this can be 'explained' by saying an object can be in two places at one time. Others would then say 'Humpty-dumpty!' since you have removed the most basic intuition of objects and you are in effect saying that a python object means what you ordain it means without further ado/explanation Since you believe a reference-less dictionary can be a model for such explanations, why not provide that? -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wed, Sep 6, 2017 at 1:42 PM, Stefan Ram wrote: > Steve D'Aprano writes: >>So in what sense are references part of the Python language? > > It would be possible to describe Python using a concept > called "reference", it's just that the The Python Language > Reference, Release 3.6.0 (PRL) does /not/ do this. > And programming language experts usually use the terms that > the language specification uses with the meaning that the > language specification is giving them. And this is why I say > that JavaScript and Python do not have references. > (Except "attribute references".) > >>Inside the interpreter, you (probably?) could print out the value of the >>pointer, or manipulate it in some fashion. > > Well, this /is/ from the PRL: > > »An object's identity never changes once it has been created; > you may think of it as the object's address in memory.«. > ¯¯ > - The Python Language Reference, Release 3.6.0; > 3.1 Objects, values and types > > It's not called "reference", it's called "identity". But it > might agree with your idea of a pointer of an implementation. > And you /can/ print it. > print( id( 'abc' )) > 4163144 Printing out an address is only half the point (pun intended) of a pointer - and the useless half. Given a pointer, you need to be able to dereference it. How can you, given the id of a Python object, access the object itself? The nearest I've ever seen is a function that searches every object it can find, looking for one with the same id. I *might* be able to accept the argument that pointer arithmetic isn't important (though I'm still of the opinion that without arithmetic, they're just references/name bindings), but if you want to say that the id() of a Python object is its pointer, you MUST demonstrate this more basic feature. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Tue, 5 Sep 2017 11:11 pm, Gregory Ewing wrote: > Steve D'Aprano wrote: >> The third entity is the reference linking the name to the object (the arrow). >> This isn't a runtime value in Python, nor is it a compile time entity that >> exists in source code. It is pure implementation, and as such, exists outside >> of the Python domain. > > The fact that there is a connection between the name and the > object is very much part of Python's abstract semantics. > > There are different ways to implement that connection, but > *any* implementation of Python has to include *some* > representation of it. Any *what* of Python? Oh, that's right, you said any *implementation* of Python. Isn't that what I said? That references are a property of the implementation, not of the language. You are inadvertently agreeing with me. - You can't bind a reference to a name in Python. Names are always bound to objects. - You can't have a list or set of references, only lists or sets of objects. - You can't form a reference to a reference. - You can't use references to implement pass-by-reference semantics. - You can't view or inspect references in Python (maybe in ctypes, or in a debugger, but those aren't part of the Python language, they are implementation-specific interfaces to the interpreter). So in what sense are references part of the Python language? My answer is that they are not. They're a part of the implementation, which makes them different from values (ints, floats, strings, lists, and other objects, whether built-in or not). It makes them different from other conceptual entities in Python like for-loops, comprehensions, try...except blocks etc, which aren't values but they are properties of the program (at least of the source code, if not the byte code). > There are also different words that can be used to describe > it. You can say that names are bound to objects, or that > names refer to objects, or that names hold references to > objects. As they used to say in Sesame Street, "One of these things is not like the others..." The first two describe a *relationship* between two entities, the name and the object: being bound to, referring to, are verbs which indicate a relationship. The third introduces a third entity. There's now two relationships: - names hold (are bound to, point to) references; - references refer to (are bound to, point to) objects. That's an example of reification, "making real", taking an abstract concept or relationship or verb and treating it as a thing. We often do that in poetic language: we talk of death or hunger stalking the streets. In this case, its a bit more complicated because *in a sense* you are right. Inside the interpreter, there really is a data structure which we might call a reference: in CPython its a pointer. So you are not entirely being poetic here. Inside the interpreter, you (probably?) could print out the value of the pointer, or manipulate it in some fashion. But at the level of Python code, you are reifying a relationship into a thing. In Python code, names are bound to objects, and the implementation of that binding is not part of the language itself. References aren't things, any more than fatherhood or treason are things (they are states of being that describe a certain relationships). That's because Python describes a virtual machine which is abstracted further away from the machine than C. Part of that abstraction is to remove pointers (references) from the set of values available to Python code to manipulate. > These are all equally good ways of talking about > the exact same abstract concept. No they aren't equally good, not if they lead to confusion and terminology abuse. Earlier I linked to a Stackoverflow question about Java, asking how to find the address of variables. It must be easy, right, because Java variables hold pointers to some address. (Actually, no they don't.) In Python, we still have people asking from time to time how to dereference pointers (references), or how to pass an int by reference, or a list by value (making a copy). It must be possible, because Python is pass-by-value for some values and pass-by-reference for others, right? (No.) I'm not opposed to the "reference" concept in general. I just want people to be more clear about what level of abstraction you are talking about when you use it. I don't want people to say that Python (the language) has references or pointers, because it doesn't. I don't have any objection to people saying that the interpreter has references or pointers, and that's how name binding works behind the scenes, or under the hood. And I categorically *hate* explanations of Python's argument parsing that require people to simultaneously believe that the value of x following x=1 is: 1 (the meaning of "value" they actually use in practice), and: some invisible, unknown, unknowable, implementation-dependent reference to the actual value (the meaning they insist
Re: A question on modification of a list via a function invocation
On Wednesday, September 6, 2017 at 3:34:41 AM UTC+5:30, Marko Rauhamaa wrote: > Chris Angelico : > > > That shows that the Java '==' operator is like the Python 'is' > > operator, and checks for object identity. You haven't manipulated > > pointers at all. In contrast, here's a C program that actually > > MANIPULATES pointers: > > > > [...] > > > > You can't do this with Python, since pointer arithmetic fundamentally > > doesn't exist. You can in C. Can you in Java? > > You can't do it in Pascal, either, but Pascal definitely has pointers. > > Pointer arithmetics is not an essential part of C. One could argue that > it was a mistake to include it in the language. This is subjective of course… but still I wonder where you are coming from… You of course know that writing Unix was the genesis and raison d'être for C right? And what is an OS but a thin layer of abstraction on top of bare ISP? ie is not a Linux-OS just an x86 hw + some new ‘instructions’ called system-calls? Which is to say IMHO being able to punch holes into the hi-level-language abstraction seems to be a sine qua non for being suitable as a language for writing OSes. Do you think its reasonable/feasible to do that without easy access to all the machine resources eg memory, IO, interrupts etc accessible in the OS-writing language? [BTW I think Microsoft has done a better job than classic C of repeating this with C# — C# is almost as high-level as python, lisp etc and as low (or lower) than C; ie it is effectively two languages, called ‘safe’ and ‘unsafe’ parts ] -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On 2017-09-05, Marko Rauhamaa wrote: > Pointer arithmetics is not an essential part of C. One could argue that > it was a mistake to include it in the language. One may argue that it was a mistake, but I remember at least one implementation where pointer arithmetic was hugely more efficient than indexing into arrays. Incrementing a pointer through an array was way, way faster than indexing through the array by incrementing an array subscript. But, that was 25 years ago on an 8-bit CPU where where integer multiplies were expensive. The last time I compare the two methods with a recent GCC on a 32-bit CPU, it generated pretty much the same code either way... -- Grant Edwards grant.b.edwardsYow! Someone in DAYTON, at Ohio is selling USED gmail.comCARPETS to a SERBO-CROATIAN -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Chris Angelico : > That shows that the Java '==' operator is like the Python 'is' > operator, and checks for object identity. You haven't manipulated > pointers at all. In contrast, here's a C program that actually > MANIPULATES pointers: > > [...] > > You can't do this with Python, since pointer arithmetic fundamentally > doesn't exist. You can in C. Can you in Java? You can't do it in Pascal, either, but Pascal definitely has pointers. Pointer arithmetics is not an essential part of C. One could argue that it was a mistake to include it in the language. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wed, Sep 6, 2017 at 6:42 AM, Stefan Ram wrote: > Chris Angelico writes: >>here's a C program that actually MANIPULATES pointers: > ... >>x += 2; > ... >>You can in C. Can you in Java? > > »dog = null« in Java would correspond to »x = 0« in C. > > It seems, to you, an assignment of »x + 2« to »x« is > "manipulation", while an assignment of »0« to »x« is not. > > Well, if you define the term "manipulation" to get the > results you intend, no one can prove you wrong, but your > words might be harder to understand when they do not use > the English meanings of words (like "manipulate") but your > ad-hoc meanings. > dog = null in Java corresponds to x = None in Python. It's a null reference, but that's still a specific "thing". A fully compliant Python implementation could use a NULL pointer to represent the None object, as long as it correspondingly interprets such a pointer as representing None. In all of your Java examples, you're causing a name to refer to either an object or null, and everything you do can be explained in terms of name bindings Python-style. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wed, Sep 6, 2017 at 5:48 AM, Stefan Ram wrote:
> Depends on the meaning of "meaningful". In Java, one can
> inspect and manipulate pointers like in this program for
> example:
> [chomp code]
That shows that the Java '==' operator is like the Python 'is'
operator, and checks for object identity. You haven't manipulated
pointers at all. In contrast, here's a C program that actually
MANIPULATES pointers:
#include
void do_stuff(int *x)
{
printf("x (%p) points to %d\n", x, *x);
x += 2;
printf("Now x (%p) points to %d\n", x, *x);
}
int main()
{
int x[3] = {28, 42, 79};
do_stuff(x); /* or do_stuff(&x[0]); */
return 0;
}
You can't do this with Python, since pointer arithmetic fundamentally
doesn't exist. You can in C. Can you in Java?
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On 2017-09-05 20:08, Steve D'Aprano wrote:
On Tue, 5 Sep 2017 11:47 pm, Gregory Ewing wrote:
Steve D'Aprano wrote:
[quoting Scott Stanchfield]
Figure 7: (Java) Defining a Dog pointer
Dog d;
When you write that definition, you are defining a pointer to a Dog
object, not a Dog object itself.
[end quote]
Here Scott mixes up what the compiler does (creates a pointer to a Dog
object, and what the programmer's Java code does (creates a Dog).
Um, no. The declaration 'Dog d' on its own does NOT create a Dog,
in any way, shape or form. It only declares something that can
*refer* to a Dog created elsewhere, which is what Scott is
quite correctly saying.
That's not what he said. I quoted him: he quite clearly states that d defines a
pointer to a Dog object. He doesn't say that you're declaring an empty slot
that is waiting to be filled with a pointer to a dog. He says it defines a
pointer.
So which Dog object does this pointer point to? Answer: there isn't one. There
may not even be any Dog object existing in the entire program up to this point.
Even allowing that there were a Dog to be pointed to, how do we inspect or
manipulate that pointer? Answer: you can't, because pointers are not meaningful
values in Java.
There's no(?) Java code you can write that allows this:
Dog d;
java.lang.System.out.println( address of variable d );
java.lang.System.out.println( address of the Dog d points to );
Maybe compiler-specific debugging tools? I don't know enough Java to
*categorically* rule it out, but if it exists at all, it would be unsafe to
rely on the addresses you get.
d is initialised to null. You can check for null:
if (d == null)
java.lang.System.out.println("There's no dog.");
else
d.bark();
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wed, Sep 6, 2017 at 5:28 AM, Dennis Lee Bieber wrote:
> On 5 Sep 2017 17:57:18 GMT, r...@zedat.fu-berlin.de (Stefan Ram) declaimed
> the following:
>
>> But what does "a C++ reference" refer to?
>>
>
> Per Stroustrup (The C++ Programming Language 4th Ed, page 189)
>
> """
> * ...
> * A reference always refers to the object to which it was initialized.
> * ...
>
> A reference is an alternative name for an object, an alias. ...
> """
>
> {Hmmm, and I see that the syntax can be used outside of parameter
> declaration -- which is the only place I'd seen it previously... either
> this is a change from earlier standards, or my classes just didn't feel the
> need to expose a non-parameter reference -- since, based upon the above
> book, you can not declare a bare reference "variable"; it MUST be
> initialized with a real object.}
Outside of parameters, there's very little practical reason for
aliases. Their primary value is that an internal name can be an alias
for an external object, which is achieved with reference parameters.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Tue, 5 Sep 2017 11:47 pm, Gregory Ewing wrote: > Steve D'Aprano wrote: >> [quoting Scott Stanchfield] >> Figure 7: (Java) Defining a Dog pointer >> Dog d; >> >> When you write that definition, you are defining a pointer to a Dog >> object, not a Dog object itself. >> [end quote] >> >> Here Scott mixes up what the compiler does (creates a pointer to a Dog >> object, and what the programmer's Java code does (creates a Dog). > > Um, no. The declaration 'Dog d' on its own does NOT create a Dog, > in any way, shape or form. It only declares something that can > *refer* to a Dog created elsewhere, which is what Scott is > quite correctly saying. That's not what he said. I quoted him: he quite clearly states that d defines a pointer to a Dog object. He doesn't say that you're declaring an empty slot that is waiting to be filled with a pointer to a dog. He says it defines a pointer. So which Dog object does this pointer point to? Answer: there isn't one. There may not even be any Dog object existing in the entire program up to this point. Even allowing that there were a Dog to be pointed to, how do we inspect or manipulate that pointer? Answer: you can't, because pointers are not meaningful values in Java. There's no(?) Java code you can write that allows this: Dog d; java.lang.System.out.println( address of variable d ); java.lang.System.out.println( address of the Dog d points to ); Maybe compiler-specific debugging tools? I don't know enough Java to *categorically* rule it out, but if it exists at all, it would be unsafe to rely on the addresses you get. You're right that I made a mistake. I'm not a Java expert like Scott Stanchfield, and I was led astray by his misleading explanation, and failed to notice that d didn't have a value. (What's his excuse for not noticing?) As Stefan already pointed out, the code Scott gives does not define a value, but is just a declaration of a variable name. At that point, d has no value at all, and you get a compile time error if you try to access d. There is no Dog, and no pointer to a Dog. There's just a name (or variable if you prefer). So what's the value of d? It doesn't have one. Scott's explanation is misleading: `Dog d;` does not define *any value at all*, let alone a pointer. I daresay that Scott could attempt to justify his wording. I imagine it might go something like this: Of course d is a pointer to a value. The Java compiler keeps a table mapping variable names to memory addresses, and the name 'd' is mapped to some address in the table. That address must hold some value, even if it is uninitialised memory filled with arbitrary bytes. That address is a (possibly null, possibly invalid) pointer to a Dog object. -- Me, channelling what I think Scott *might* say. Notice how this mixes *three* different abstractions? There's the top-level Java abstraction, where we declare d as a Dog. There's the compiler abstraction, where we talk about mapping variable names to memory addresses, and pointers to Dog objects. And there's an even lower abstraction, where we talk about memory filled with arbitrary bytes. And so long as we keep track of which abstraction we're in, this is fine. It doesn't even have to be explicit: once people gain enough experience, they can effortlessly and implicitly swap between abstractions and not even notice. That's sometimes a good thing, but its a bad thing when we lose track of the abstraction level and confuse others (like me!), or even ourselves, and lead to "Not Even Wrong" questions like this: https://stackoverflow.com/questions/1961146/memory-address-of-variables-in-java (Likewise for people thinking that id() in Python returns a memory address, and ask how to dereference that address.) Not all explanations are equally useful, even if they are correct for some definition of "correct". In Python, the equivalent to Scott's code `Dog d;` would be something like this: # --- %< --- class Dog: pass global x assert isinstance(x, Dog) # --- %< --- except that we get a runtime NameError instead of a compile-time error. Would you like to say that this code "defines a pointer to a Dog"? I should hope not. How is it different from Scott's example of `Dog d;`? >> I expect this is because, as a "compiler guy", Scott probably doesn't really >> believe that objects are values. > > Please stop insulting Scott's intelligence, and that of other > "compiler guys", by suggesting that they don't understand things > as well as you do. Why shouldn't I suggest that Scott got something wrong? What makes him, and other "compiler guys", so special that they are infallible and can't make mistakes? Argument by authority is at best the weakest form of argument, if it isn't an outright fallacy. https://en.wikipedia.org/wiki/Argument_from_authority I'm not questioning his intelligence. I'm questioning his *perspective*, and his failure to distinguish between different lev
Re: A question on modification of a list via a function invocation
On 9/5/17 1:28 PM, Chris Angelico wrote: > On Wed, Sep 6, 2017 at 3:15 AM, Ned Batchelder wrote: >> On 9/5/17 1:02 PM, Steve D'Aprano wrote: >>> On Tue, 5 Sep 2017 11:37 pm, Gregory Ewing wrote: >>> Dennis Lee Bieber wrote: > Pascal, probably Modula-2, Visual BASIC are closer to the C++ reference > semantics, in that the definition of a function declares how the > argument(s) are passed. Well, sort of. In Pascal and Modula, and also VB I think, parameters are the only things that can be declared as having reference semantics, whereas references in C++ are first-class things that can be stored in any variable. >>> No, they aren't first-class. >> Did you mis-read Gregory's claim? He said, "references *in C++* are >> first-class things". You seem to be talking below about Python things. >> > And everything Steve said was about C++ references, which are a form > of alias. Not a 'thing'. I see, I misunderstood. Sorry for the distraction. > > ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Tuesday, September 5, 2017 at 10:45:45 PM UTC+5:30, Ned Batchelder wrote: > On 9/5/17 1:02 PM, Steve D'Aprano wrote: > > On Tue, 5 Sep 2017 11:37 pm, Gregory Ewing wrote: > > > >> Dennis Lee Bieber wrote: > >>> Pascal, probably Modula-2, Visual BASIC are closer to the C++ reference > >>> semantics, in that the definition of a function declares how the > >>> argument(s) are passed. > >> Well, sort of. In Pascal and Modula, and also VB I think, > >> parameters are the only things that can be declared as having > >> reference semantics, whereas references in C++ are first-class > >> things that can be stored in any variable. > > No, they aren't first-class. > > Did you mis-read Gregory's claim? He said, "references *in C++* are > first-class things". You seem to be talking below about Python things. I think its mostly true of C++ And Steven did say: (I don't know enough about C++ to distinguish between the last two opinions, but I'm strongly leaning towards "not values at all".) So he seems to be talking of C++ (as analogous to python??) But I dont see that any of it is relevant Whether references are - first-class (Algol-68, pointers-in-C) or are simply - second class (C++) - invisible (python, lisp, ruby, javascript) has little to do with what we are talking The question is whether we need the *idea* of references (modulo humpty-dumpty-fication) to talk *about* the language; ie it needs to be there in the human/informal ontology, even if the docs play word-games and try to avoid trigger-words in honour of PC. In my view its almost the defining quality of imperative languages that the semantics of the language is not properly/fully comprehensive without (something like) references. [Replace "imperative language" with "assignment and mutation" if you like] -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Wed, Sep 6, 2017 at 3:15 AM, Ned Batchelder wrote: > On 9/5/17 1:02 PM, Steve D'Aprano wrote: >> On Tue, 5 Sep 2017 11:37 pm, Gregory Ewing wrote: >> >>> Dennis Lee Bieber wrote: Pascal, probably Modula-2, Visual BASIC are closer to the C++ reference semantics, in that the definition of a function declares how the argument(s) are passed. >>> Well, sort of. In Pascal and Modula, and also VB I think, >>> parameters are the only things that can be declared as having >>> reference semantics, whereas references in C++ are first-class >>> things that can be stored in any variable. >> No, they aren't first-class. > > Did you mis-read Gregory's claim? He said, "references *in C++* are > first-class things". You seem to be talking below about Python things. > And everything Steve said was about C++ references, which are a form of alias. Not a 'thing'. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Tue, 5 Sep 2017 11:08 pm, Stefan Ram wrote: > Steve D'Aprano writes: >>[quote] >>The mistake they make is in the definition of >>Figure 7: (Java) Defining a Dog pointer >>Dog d; >>itself. When you write that definition, you are defining a pointer to a Dog >>object, not a Dog object itself. >>[end quote] >>Here Scott mixes up what the compiler does (creates a pointer to a Dog object, >>and what the programmer's Java code does (creates a Dog). > > I have not the whole context in mind, and so I might get > something wrong here, but if > > Dog d; > > is supposed to be interpreted as Java, then it neither > creates a pointer to a Dog object nor it creates a Dog. > > Instead, it declares an unitialized variable d. Thank you Stefan, your correction is noted. I'm not a Java expert like Scott, and I failed to notice the distinction between: Dog d; and Dog d = new Dog(); so I failed to realise that of course d has no value at all in Scott's example. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On 9/5/17 1:02 PM, Steve D'Aprano wrote:
> On Tue, 5 Sep 2017 11:37 pm, Gregory Ewing wrote:
>
>> Dennis Lee Bieber wrote:
>>> Pascal, probably Modula-2, Visual BASIC are closer to the C++ reference
>>> semantics, in that the definition of a function declares how the
>>> argument(s) are passed.
>> Well, sort of. In Pascal and Modula, and also VB I think,
>> parameters are the only things that can be declared as having
>> reference semantics, whereas references in C++ are first-class
>> things that can be stored in any variable.
> No, they aren't first-class.
Did you mis-read Gregory's claim? He said, "references *in C++* are
first-class things". You seem to be talking below about Python things.
>
> - It is not possible to refer to a reference after it is defined; any
> occurrence of its name refers directly to the object it references.
>
> - Since you cannot refer directly to a reference, but only the object
> it points to, you cannot have a reference to a reference.
>
> - Containers of references are not allowed.
>
> - Once a reference to an object is created, it cannot be changed to
> reference another object ("to be reseated").
>
> The last is only a limitation if you think of references as mutable pointers
> in
> the C sense. But if you think of them as objects in the Python sense, that
> makes them merely immutable.
>
> But the inability to refer to the reference itself, the lack of references to
> references, and the inability to have a container of references, makes them
> second-class values -- or possibly not values at all.
>
> (I don't know enough about C++ to distinguish between the last two opinions,
> but
> I'm strongly leaning towards "not values at all".)
>
>
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Tue, 5 Sep 2017 11:37 pm, Gregory Ewing wrote:
> Dennis Lee Bieber wrote:
>> Pascal, probably Modula-2, Visual BASIC are closer to the C++ reference
>> semantics, in that the definition of a function declares how the
>> argument(s) are passed.
>
> Well, sort of. In Pascal and Modula, and also VB I think,
> parameters are the only things that can be declared as having
> reference semantics, whereas references in C++ are first-class
> things that can be stored in any variable.
No, they aren't first-class.
- It is not possible to refer to a reference after it is defined; any
occurrence of its name refers directly to the object it references.
- Since you cannot refer directly to a reference, but only the object
it points to, you cannot have a reference to a reference.
- Containers of references are not allowed.
- Once a reference to an object is created, it cannot be changed to
reference another object ("to be reseated").
The last is only a limitation if you think of references as mutable pointers in
the C sense. But if you think of them as objects in the Python sense, that
makes them merely immutable.
But the inability to refer to the reference itself, the lack of references to
references, and the inability to have a container of references, makes them
second-class values -- or possibly not values at all.
(I don't know enough about C++ to distinguish between the last two opinions, but
I'm strongly leaning towards "not values at all".)
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Tuesday, September 5, 2017 at 7:12:48 PM UTC+5:30, Rustom Mody wrote: > On Tuesday, September 5, 2017 at 6:42:07 PM UTC+5:30, Gregory Ewing wrote: > > Steve D'Aprano wrote: > > > The third entity is the reference linking the name to the object (the > > > arrow). > > > This isn't a runtime value in Python, nor is it a compile time entity that > > > exists in source code. It is pure implementation, and as such, exists > > > outside > > > of the Python domain. > > > > The fact that there is a connection between the name and the > > object is very much part of Python's abstract semantics. > > > > There are different ways to implement that connection, but > > *any* implementation of Python has to include *some* > > representation of it. > > > > There are also different words that can be used to describe > > it. You can say that names are bound to objects, or that > > names refer to objects, or that names hold references to > > objects. These are all equally good ways of talking about > > the exact same abstract concept. > > > > To me this argument about whether Python has references > > or not is like an American person saying that cars have > > hoods, and a British person saying he's wrong, hoods > > are an implementation detail and cars actually have > > bonnets instead. > > Also called playing humpty-dumpty > > I believe there is a germ of value behind all this empty polemics > There are 3 equivalence relations: > 1. == — mathematical, too coarse to understand nuances of python semantics > 2. is — machine representation, too fine to be useful > 3. graph (or topological) equality which experienced pythonistas have > internalized > in understanding when two data structures are same or different > [Roughly Anton's diagrams that are beyond my drawing capability!] > > > And yet pythonistas need that to understand python data structures > > >>> a = [1,2] > >>> b = [a,a] > >>> c = [[1,2],[1,2]] > >>> b == c > True > >>> b is c > False > >>> p = [1,2] > >>> q = [p,p] > >>> r = [[1,2],[1,2]] > >>> q == r > True > >>> q is r > False > >>> b == q > True > >>> b == r > True > >>> b is q > False > >>> b is r > False To make it more clear Suppose ≡ is graph-equal. The pythonista understands that b ≢ c ## ≡ is finer than == Whereas b ≡ r ie ≡ is coarser than is Its another matter that the name 'is' makes these discussions much harder in python than in equivalent languages like java, lisp, javascript etc by making the mostly unnecessary and irrelevant "is machine-rep same" sound the same(!) as "is conceptually same" -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Tue, Sep 5, 2017 at 11:11 PM, Gregory Ewing wrote: > Steve D'Aprano wrote: >> >> The third entity is the reference linking the name to the object (the >> arrow). >> This isn't a runtime value in Python, nor is it a compile time entity that >> exists in source code. It is pure implementation, and as such, exists >> outside >> of the Python domain. > > > The fact that there is a connection between the name and the > object is very much part of Python's abstract semantics. > > There are different ways to implement that connection, but > *any* implementation of Python has to include *some* > representation of it. Sure. But let's suppose you're building a Python implementation on top of a language that has a perfectly good implementation of dict already built for you. Literally every other namespace can be represented with a dictionary, and the name:value association is that reference. Is the reference *itself* a runtime value? No; you can't pick it up and move it around - all you'll do is dereference it and get the value itself. (Or you'll work with the name, as a string. That can sometimes serve as a pseudo-reference.) Is it a compile time entity? Not directly (assignment statements imply them, but they aren't themselves the references). So Steve's comment is still correct. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Steve D'Aprano wrote: [quoting Scott Stanchfield] Figure 7: (Java) Defining a Dog pointer Dog d; When you write that definition, you are defining a pointer to a Dog object, not a Dog object itself. [end quote] Here Scott mixes up what the compiler does (creates a pointer to a Dog object, and what the programmer's Java code does (creates a Dog). Um, no. The declaration 'Dog d' on its own does NOT create a Dog, in any way, shape or form. It only declares something that can *refer* to a Dog created elsewhere, which is what Scott is quite correctly saying. I expect this is because, as a "compiler guy", Scott probably doesn't really believe that objects are values. Please stop insulting Scott's intelligence, and that of other "compiler guys", by suggesting that they don't understand things as well as you do. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Tuesday, September 5, 2017 at 6:42:07 PM UTC+5:30, Gregory Ewing wrote: > Steve D'Aprano wrote: > > The third entity is the reference linking the name to the object (the > > arrow). > > This isn't a runtime value in Python, nor is it a compile time entity that > > exists in source code. It is pure implementation, and as such, exists > > outside > > of the Python domain. > > The fact that there is a connection between the name and the > object is very much part of Python's abstract semantics. > > There are different ways to implement that connection, but > *any* implementation of Python has to include *some* > representation of it. > > There are also different words that can be used to describe > it. You can say that names are bound to objects, or that > names refer to objects, or that names hold references to > objects. These are all equally good ways of talking about > the exact same abstract concept. > > To me this argument about whether Python has references > or not is like an American person saying that cars have > hoods, and a British person saying he's wrong, hoods > are an implementation detail and cars actually have > bonnets instead. Also called playing humpty-dumpty I believe there is a germ of value behind all this empty polemics There are 3 equivalence relations: 1. == — mathematical, too coarse to understand nuances of python semantics 2. is — machine representation, too fine to be useful 3. graph (or topological) equality which experienced pythonistas have internalized in understanding when two data structures are same or different [Roughly Anton's diagrams that are beyond my drawing capability!] And yet pythonistas need that to understand python data structures >>> a = [1,2] >>> b = [a,a] >>> c = [[1,2],[1,2]] >>> b == c True >>> b is c False >>> p = [1,2] >>> q = [p,p] >>> r = [[1,2],[1,2]] >>> q == r True >>> q is r False >>> b == q True >>> b == r True >>> b is q False >>> b is r False Now the pythonista understands that b and c may be math-= but have different structure Whereas b is graph-equal to q And c is graph-equal to r However there is no available operation to show/see that distinction The trouble is that graph-isomorphism is NP-complete so the crucial operation cannot be reasonably implemented Let the endless threads continue 😈 -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Dennis Lee Bieber wrote:
Pascal, probably Modula-2, Visual BASIC are closer to the C++ reference
semantics, in that the definition of a function declares how the
argument(s) are passed.
Well, sort of. In Pascal and Modula, and also VB I think,
parameters are the only things that can be declared as having
reference semantics, whereas references in C++ are first-class
things that can be stored in any variable.
I don't have Java textbooks locally (in storage 15 miles away) but from
what I recall, it too has the complication of splitting between "simple
types" and "reference types" ("boxed" I believe is the term used in books).
The default passing mechanism would be similar to the description of C#
("boxed" types being implicit copies of references allowing mutation
in-place, but assignment to the parameter itself has no effect on the
caller). I suspect it too has some means to explicitly produce a
by-reference parameter.
No, Java doesn't have by-reference parameters, which can be
annoying at times when combined with the fact that it doesn't
have anything like Python's easy tuple returning and unpacking.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Steve D'Aprano wrote: On Tue, 5 Sep 2017 02:51 am, Stefan Ram wrote: > I am assuming that there are two argument passing mechanismss in the languages mentioned by me (C, C++, VBA, C#, Java, JavaScript, and Python): - pass by aliassing (reference) - pass "as if by assignment" That assumption is wrong. How is it wrong? What parameter passing mechanism in any of those languages is not either by aliasing or by assignment? -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Steve D'Aprano wrote: The third entity is the reference linking the name to the object (the arrow). This isn't a runtime value in Python, nor is it a compile time entity that exists in source code. It is pure implementation, and as such, exists outside of the Python domain. The fact that there is a connection between the name and the object is very much part of Python's abstract semantics. There are different ways to implement that connection, but *any* implementation of Python has to include *some* representation of it. There are also different words that can be used to describe it. You can say that names are bound to objects, or that names refer to objects, or that names hold references to objects. These are all equally good ways of talking about the exact same abstract concept. To me this argument about whether Python has references or not is like an American person saying that cars have hoods, and a British person saying he's wrong, hoods are an implementation detail and cars actually have bonnets instead. -- Greg -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
Dennis,
That's an excellent summary of a number of programming languages' calling
conventions, thank you.
Unfortunately you have the X-No-Archive header set, so it will be lost to
prosperity. To prevent that, I'm taking the liberty of quoting you in full
below (and top posting).
A couple of comments:
> I don't have Java textbooks locally (in storage 15 miles away) but from
> what I recall, it too has the complication of splitting between "simple
> types" and "reference types" ("boxed" I believe is the term used in books).
You remember correctly.
Java supports machine primitive values like ints and floats, and always treats
them as by-value. You can also "box" them in an object, in which case Java has
precisely the same semantics as Python, Ruby and many others, pass by object
sharing. But the Java community insists on calling it pass by value.
Occasionally, when they remember or when pressed, they will admit that what is
being passed by value is not the object (the value), but an invisible,
unknowable, implementation-dependent reference to the actual value.
> The default passing mechanism would be similar to the description of C#
> ("boxed" types being implicit copies of references allowing mutation
> in-place, but assignment to the parameter itself has no effect on the
> caller).
Indeed.
> I suspect it too has some means to explicitly produce a
> by-reference parameter.
I've never come across a by-reference mechanism is Java. Scott Stanchfield gives
the litmus test for pass-by-reference semantics: can you write a "swap"
procedure in the language? He gives examples of a swap() procedure in
pseudocode, Pascal and C++, and specifically says "you cannot do this in Java".
http://javadude.com/articles/passbyvalue.htm
But of course you can simulate (poorly) by-reference output parameters in Java,
or Python, using mutation, just as you can simulate (poorly) by-reference
output parameters in C with pointers and mutation of the memory location
pointed to.
Scott describes himself as "a compiler guy at heart", and that leads him to
confuse abstraction levels. He is absolutely correct that the Java compiler
always passes by value. But that's not the Java language, that is the
implementation of the Java language. Here is Scott's category error:
[quote]
The mistake they make is in the definition of
Figure 7: (Java) Defining a Dog pointer
Dog d;
itself. When you write that definition, you are defining a pointer to a Dog
object, not a Dog object itself.
[end quote]
Here Scott mixes up what the compiler does (creates a pointer to a Dog object,
and what the programmer's Java code does (creates a Dog).
I expect this is because, as a "compiler guy", Scott probably doesn't really
believe that objects are values. Values are small machine primitives, like a
64-bit float, not big, complicated, compound structures of methods and
attributes like objects.
On category errors: https://en.wikipedia.org/wiki/Category_mistake
On Tue, 5 Sep 2017 05:12 am, Dennis Lee Bieber wrote:
> On 4 Sep 2017 16:51:45 GMT, r...@zedat.fu-berlin.de (Stefan Ram) declaimed
> the following:
>
>>
>> I am assuming that there are two argument passing mechanismss
>> in the languages mentioned by me (C, C++, VBA, C#, Java,
>> JavaScript, and Python):
>
> Original (and maybe still) C only has one native passing convention:
> pass by value. Arguments go in, but they do not come out.
>
> C relied upon the /programmer/ to explicitly obtain the address of a
> memory location (by using & upon the argument) with the obtained address
> now being passed by value. C also relied upon the programmer to explicitly
> dereference the parameter in order to access the desired value.
>
> int afunc(int x, int * y)
> {
> int z;
> z = x + y;/* whoops, forgot to dereference y */
> return (- *y);/* this time remembered */
> }
>
> ...
> int a;
> int b;
>
> z = afunc(a, b); /* whoops, forgot to obtain address of b */
> z2 = afunc(a, &b);/* correct usage */
>
> C++ has added a reference declaration in the definition of functions,
> thereby making the obtaining/dereferencing automatic.
>
> int bfunc(int x, int & y)
> {
> int z;
> z = x + y;/* automatic derefence */
> return -y;
> }
>
> z = bfunc(a, b); /* automatic address */
>
>
> Classic FORTRAN is always pass-by-reference(location) -- though DEC VMS
> FORTRAN had compile-time "functions" which could override that: %ref,
> %descr, %val (and I think there was a %loc which would return the address
> of the argument -- it wasn't used for parameter passing itself).
>
> Pascal, probably Modula-2, Visual BASIC are closer to the C++ reference
> semantics, in that the definition of a function declares how the
> argument(s) are passed.
>
> Pascal and Modula-2 default is by-value, unless the parameter is
> declared with "var "
>
> VB-6 defaulted to by-reference and relied upon the use of "ByVal " in
> the declaration to cause a by-value pass. VB.N
Re: A question on modification of a list via a function invocation
On Tue, Sep 5, 2017 at 1:36 AM, Dennis Lee Bieber wrote:
> On Tue, 05 Sep 2017 00:20:25 +1000, Steve D'Aprano
> declaimed the following:
>
>>(Of course this is silly. As all physicists know, there are no people, animals
>>or cars in the world, there are only quarks and electrons.)
>
> Quarks and Leptons and Bosons (Oh, my!)
>
>
> {I tend to forget the bosons}
Once we get quantum computing as a regular and normal thing, we'll
have to redefine duck typing.
If it quarks like a duck...
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On 04-09-17 16:30, Steve D'Aprano wrote: > On Tue, 5 Sep 2017 12:09 am, Antoon Pardon wrote: > >> Op 04-09-17 om 15:26 schreef Steve D'Aprano: >>> On Mon, 4 Sep 2017 08:52 pm, Antoon Pardon wrote: >>> Op 04-09-17 om 12:22 schreef Stefan Ram: > Rustom Mody writes: >>> Stefan Ram wrote: JavaScript and Python do not have references as values >>> Yes, they do. The difference is that they don't have any > ... >> Its because reference (or pointer or ?) is central to python's semantics > If they are so central, then it should be easy to show > quotes from The Python Language Reference to support that > claim. The section about assignment talks about reference counts. >>> Does that mean that IronPython and Jython aren't implementations of Python? >>> They have no reference counts. >> >> I am not a lawyer > > But you are a Python programmer. > > You should be aware that reference counts are a property of the CPython > implementation, not a language feature. Jython and IronPython, at the very > least, are valid, conforming implementations of Python the language which have > no reference counts. Therefore reference counts cannot be central to Python's > semantics, since there are Python interpreters that don't use them. It is not my responsibility that reference counts are mentioned in the language referece. In how far mentioning reference counts in the language reference makes IronPython or Jython not python is IMO food for lawyers. I also didn't claim reference counts are essential to python's semantics. -- Antoon Pardon -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Tue, 5 Sep 2017 02:51 am, Stefan Ram wrote: > Steve D'Aprano writes: >>Sorry Stefan, that is the same trap that many others fall into. You are >>assuming that there are exactly two evaluation conventions: >>- pass by reference >>- pass by value >>and so if a language doesn't do one, it must do the other. > > I am assuming that there are two argument passing mechanismss > in the languages mentioned by me (C, C++, VBA, C#, Java, > JavaScript, and Python): > > - pass by aliassing (reference) > - pass "as if by assignment" That assumption is wrong. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Monday, September 4, 2017 at 9:13:43 PM UTC+5:30, Steve D'Aprano wrote: > On Tue, 5 Sep 2017 01:17 am, Rustom Mody wrote: > > > Anton gave a picture explaining why/how references are needed and to be > > understood > > Antoon gave a picture demonstrating one model of Python's semantics. > > It's a nice model that has a lot going for it, in particular that it matches > the > most obvious implementation. But it doesn't describe *Python* semantics, it > describes an overlap between Python the language and the implementation of the > Python interpreter. > > In particular, consider the picture of a name binding to a value: > > > +-+ > | | > | 5 | > | | > +-+ > ^ > | > > > > This picture has three entities, but only two of them exist in Python: > > - the object 5; > > - the name "x" (names are not values in Python at runtime, but they > are entities which exist in Python source code at compile time). > > The third entity is the reference linking the name to the object (the arrow). > This isn't a runtime value in Python, nor is it a compile time entity that > exists in source code. It is pure implementation, and as such, exists outside > of the Python domain. A common fallacy: https://en.wikipedia.org/wiki/Begging_the_question Python does not have references/pointers/whatever ∴ Python does not have references (or whatever you want to (not) call it) -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Monday, September 4, 2017 at 3:20:22 AM UTC+1, Chris Angelico wrote: > On Mon, Sep 4, 2017 at 12:05 PM, Steve D'Aprano wrote: > > On Mon, 4 Sep 2017 04:15 am, Stephan Houben wrote: > > > >> Needless to say, according to the definition in Plotkin's paper, Python > >> is "call-by-value". > > > > According to Plotkin's definition, when you pass a value like a 100MB > > string: > > > > "This is a long string of text..." # continues on for millions more > > characters > > > > does the interpreter make a copy of the 100MB string? > > > > If not, then it isn't pass (call) by value. > > This is another proof that you can't divide everything into "pass by > value" vs "pass by reference", unless you mess around with "passing a > reference by value" or other shenanigans. In C, a string is not an > entity; it's simply an array of characters. Arrays are never passed by > value; yet everything in C is passed by value. So you pass a > pointer... by value. > > What would you define LISP's semantics as? Pass by value? Pass by > reference? Pass by name? Pass by immutability? Pass the salt? > > ChrisA I can't say that I'm too bothered about all this what with "Practicality beats purity" and all that. Still for the definitive guides to Python I always go back to http://effbot.org/zone/call-by-object.htm and https://jeffknupp.com/blog/2012/11/13/is-python-callbyvalue-or-callbyreference-neither/ Kindest regards. Mark Lawrence. -- https://mail.python.org/mailman/listinfo/python-list
Re: A question on modification of a list via a function invocation
On Tue, 5 Sep 2017 01:17 am, Rustom Mody wrote: > Anton gave a picture explaining why/how references are needed and to be > understood Antoon gave a picture demonstrating one model of Python's semantics. It's a nice model that has a lot going for it, in particular that it matches the most obvious implementation. But it doesn't describe *Python* semantics, it describes an overlap between Python the language and the implementation of the Python interpreter. In particular, consider the picture of a name binding to a value: +-+ | | | 5 | | | +-+ ^ | This picture has three entities, but only two of them exist in Python: - the object 5; - the name "x" (names are not values in Python at runtime, but they are entities which exist in Python source code at compile time). The third entity is the reference linking the name to the object (the arrow). This isn't a runtime value in Python, nor is it a compile time entity that exists in source code. It is pure implementation, and as such, exists outside of the Python domain. I'm not saying that we should never use this model. Its a good model. But we should be clear that it is a model of the implementation, and it describes entities which are not part of the Python language. We cannot do this: +-+ | | | 5 | | | +-+ ^ | ^ | or any of the other things we can do in a language with references-as-values, like C or Pascal. [...] > Roger Christman compressed my foo and bar into one baz > > def baz(x,y): >x += y > > Which leaks or doesnt leak x-modifications depending on its type Yes, I see that -- but I don't see the point of it. What conclusion do you draw from that? -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
