Re: I'm wrong or Will we fix the ducks limp?

Marko Rauhamaa writes: > Paul Rudin wrote: >> Talk of pointers is potentially confusing, because it carries baggage >> from other languages which doesn't necessary map precisely onto the >> python execution model. > > Unfortunately, virtually every word is overloaded and full of > preconceived

Re: I'm wrong or Will we fix the ducks limp?

Paul Rudin : > Marko Rauhamaa writes: >> The spec (https://docs.python.org/3/reference/datamodel.html>) >> uses the terms *identity* and *reference*, which are one-to-one. > > identity isn't the same thing as a name, identity is an inherent > property

Re: I'm wrong or Will we fix the ducks limp?

On Thu, Jun 9, 2016, at 03:30, Antoon Pardon wrote: > Then you think wrong. Python has no pointers, that is an implementation > detail. Nonsense. A binary number referring to a memory address is an implementation detail. A pointer/reference/arrow-thingy-on-a-diagram is the thing it is an

Re: I'm wrong or Will we fix the ducks limp?

Paul Rudin writes: > Marko Rauhamaa writes: >> So your "names" are *variables*. > > Informally yes, but "variable" has no meaning in the language reference. > ... err sorry, actually not correct - but irrelevant to the point under discussion. --

Re: I'm wrong or Will we fix the ducks limp?

Marko Rauhamaa writes: > Paul Rudin : > >> Marko Rauhamaa writes: >>> The object is only an intermediate result; what is returned is a >>> pointer (to an object), without an exception. That's not a matter of >>> implementation. It's

Re: I'm wrong or Will we fix the ducks limp?

Paul Rudin : > Marko Rauhamaa writes: >> The object is only an intermediate result; what is returned is a >> pointer (to an object), without an exception. That's not a matter of >> implementation. It's an essential part of Python's data model. > > Well

Re: I'm wrong or Will we fix the ducks limp?

Marko Rauhamaa writes: > Paul Rudin : > >> Marko Rauhamaa writes: >>> What is different is that in Python, every expression evaluates to a >>> pointer. Thus, you can only assign pointers to variables. >> >> I don't think that's really

Re: I'm wrong or Will we fix the ducks limp?

Antoon Pardon : > Op 09-06-16 om 11:19 schreef Marko Rauhamaa: >> The difference is not in the variables but in the expressions. In >> Python, >> >> 1 >> >> evaluates to a pointer; in C, it evaluates to an int. Furthermore, in >> Python, >> >> A >> >>

Re: I'm wrong or Will we fix the ducks limp?

Paul Rudin : > Marko Rauhamaa writes: >> What is different is that in Python, every expression evaluates to a >> pointer. Thus, you can only assign pointers to variables. > > I don't think that's really right - every expression evaluates to an > object.

Re: I'm wrong or Will we fix the ducks limp?

Op 09-06-16 om 14:17 schreef BartC: > On 09/06/2016 12:19, Antoon Pardon wrote: >> Op 09-06-16 om 12:53 schreef BartC: >>> On 09/06/2016 10:46, Antoon Pardon wrote: Op 09-06-16 om 09:36 schreef Steven D'Aprano: >>> > Your example demonstrates object mutation, not assignment.

Re: I'm wrong or Will we fix the ducks limp?

Op 09-06-16 om 14:25 schreef BartC: > On 09/06/2016 12:08, Antoon Pardon wrote: >> Op 09-06-16 om 12:48 schreef BartC: >>> >>> What does it matter? >>> >>> If swap() can be implemented via such a function, then it means that >>> the language has such capability, which can be useful in different

Re: I'm wrong or Will we fix the ducks limp?

Op 09-06-16 om 13:46 schreef Julien Salort: > Antoon Pardon wrote: > >> A.x = 1; >> A.y = 2; >> >> B = A; >> >> B.x = 3; >> B.y = 4; >> >> >> In C the variable A will still be x:1, y:2. >> In Python the variable A will be x:3, y:4. > But it would, if you

Re: I'm wrong or Will we fix the ducks limp?

On 09/06/2016 12:08, Antoon Pardon wrote: Op 09-06-16 om 12:48 schreef BartC: What does it matter? If swap() can be implemented via such a function, then it means that the language has such capability, which can be useful in different scenarios. If it can't, then the language hasn't. Python

Re: I'm wrong or Will we fix the ducks limp?

On 09/06/2016 12:19, Antoon Pardon wrote: Op 09-06-16 om 12:53 schreef BartC: On 09/06/2016 10:46, Antoon Pardon wrote: Op 09-06-16 om 09:36 schreef Steven D'Aprano: Your example demonstrates object mutation, not assignment. Generally assignment and mutation don't contradict each other.

Re: I'm wrong or Will we fix the ducks limp?

Antoon Pardon wrote: > A.x = 1; > A.y = 2; > > B = A; > > B.x = 3; > B.y = 4; > > > In C the variable A will still be x:1, y:2. > In Python the variable A will be x:3, y:4. But it would, if you had written instead: A->x = 1; A->y = 2; B = A; B->x

Re: I'm wrong or Will we fix the ducks limp?

Op 09-06-16 om 12:53 schreef BartC: > On 09/06/2016 10:46, Antoon Pardon wrote: >> Op 09-06-16 om 09:36 schreef Steven D'Aprano: > >>> Your example demonstrates object mutation, not assignment. >> >> Generally assignment and mutation don't contradict each other. >> So IMO the cause is the same, a

Re: I'm wrong or Will we fix the ducks limp?

Op 09-06-16 om 12:48 schreef BartC: > > What does it matter? > > If swap() can be implemented via such a function, then it means that > the language has such capability, which can be useful in different > scenarios. > > If it can't, then the language hasn't. > > Python doesn't have it so it can't

Re: I'm wrong or Will we fix the ducks limp?

BartC writes: > On 09/06/2016 10:46, Antoon Pardon wrote: >> Op 09-06-16 om 09:36 schreef Steven D'Aprano: > >>> Your example demonstrates object mutation, not assignment. >> >> Generally assignment and mutation don't contradict each other. >> So IMO the cause is the same, a mutation. In some

Re: I'm wrong or Will we fix the ducks limp?

On 09/06/2016 10:46, Antoon Pardon wrote: Op 09-06-16 om 09:36 schreef Steven D'Aprano: Your example demonstrates object mutation, not assignment. Generally assignment and mutation don't contradict each other. So IMO the cause is the same, a mutation. In some languages you can mutate your

Re: I'm wrong or Will we fix the ducks limp?

On 09/06/2016 10:55, Antoon Pardon wrote: Op 09-06-16 om 11:10 schreef BartC: On 09/06/2016 08:50, Antoon Pardon wrote: Op 08-06-16 om 19:29 schreef BartC: I don't see why we should determine what a /proper/ reference can do, based on what it does in one specific language. Because there

Re: I'm wrong or Will we fix the ducks limp?

On 09/06/2016 11:03, Marko Rauhamaa wrote: Antoon Pardon : Your challenge, shows that you don't fully understand what reference variables are. The behaviour you see in Pascal, doesn't depend (alone) on the parameter being a reference parameter. It also depends on

Re: I'm wrong or Will we fix the ducks limp?

Op 09-06-16 om 11:19 schreef Marko Rauhamaa: > >> In a rather straight forward environment with classes/structs that >> have an x and y attribute, the following lines behave differently >> in C and Python. >> >> A.x = 1; >> A.y = 2; >> >> B = A; >> >> B.x = 3; >> B.y = 4; >> >> In C the

Re: I'm wrong or Will we fix the ducks limp?

Marko Rauhamaa writes: > Antoon Pardon : > >> You can do something like that in simula, but only because >> simula has two kinds of assignments. One kind that is >> simular to python and one that is similar to C. >> The one that is similar that

Re: I'm wrong or Will we fix the ducks limp?

Antoon Pardon : > Your challenge, shows that you don't fully understand what reference > variables are. The behaviour you see in Pascal, doesn't depend (alone) > on the parameter being a reference parameter. It also depends on the > fact that the assignment in pascal

Re: I'm wrong or Will we fix the ducks limp?

Op 09-06-16 om 11:10 schreef BartC: > On 09/06/2016 08:50, Antoon Pardon wrote: >> Op 08-06-16 om 19:29 schreef BartC: >>> I don't see why we should determine what a /proper/ reference can do, based on what it does in one specific language. >>> >>> Because there are some things that such

Re: I'm wrong or Will we fix the ducks limp?

Op 09-06-16 om 09:36 schreef Steven D'Aprano: > On Wednesday 08 June 2016 19:41, Antoon Pardon wrote: > >>> What you seem to be describing is similar to reference parameter semantics >>> from Pascal. Assignment doesn't work that way in C, or Python. >> I disagree. In python the assignment does

Re: I'm wrong or Will we fix the ducks limp?

Antoon Pardon : > Op 08-06-16 om 18:37 schreef Marko Rauhamaa: >> I see Python as doing the exact same thing with variables as C. >> >> What is different is that in Python, every expression evaluates to a >> pointer. Thus, you can only assign pointers to variables. >

Re: I'm wrong or Will we fix the ducks limp?

On 09/06/2016 08:50, Antoon Pardon wrote: Op 08-06-16 om 19:29 schreef BartC: I don't see why we should determine what a /proper/ reference can do, based on what it does in one specific language. Because there are some things that such references can do that Python can't do with its object

Re: I'm wrong or Will we fix the ducks limp?

Op 08-06-16 om 19:29 schreef BartC: > I don't see why we should determine what a /proper/ reference >> can do, based on what it does in one specific language. > > Because there are some things that such references can do that Python > can't do with its object reference model, not without some

Re: I'm wrong or Will we fix the ducks limp?

On Wednesday 08 June 2016 19:41, Antoon Pardon wrote: >> What you seem to be describing is similar to reference parameter semantics >> from Pascal. Assignment doesn't work that way in C, or Python. > > I disagree. In python the assignment does work similar to the reference > parameter semantics

Re: I'm wrong or Will we fix the ducks limp?

Op 08-06-16 om 18:37 schreef Marko Rauhamaa: > Antoon Pardon : > >> You can do something like that in simula, but only because >> simula has two kinds of assignments. One kind that is >> simular to python and one that is similar to C. >> The one that is similar that

Re: I'm wrong or Will we fix the ducks limp?

On Thursday, June 9, 2016 at 4:37:58 AM UTC+12, Marko Rauhamaa wrote: > I see Python as doing the exact same thing with variables as C. > > What is different is that in Python, every expression evaluates to a > pointer. Thus, you can only assign pointers to variables. Yup. I think some people

Re: I'm wrong or Will we fix the ducks limp?

On 08/06/2016 15:18, Antoon Pardon wrote: Op 08-06-16 om 14:34 schreef BartC: So you have partial updates and full updates. A proper reference will be able to do both via the reference. Python can only do a partial update and the reason is that the reference points to the object, not the

Re: I'm wrong or Will we fix the ducks limp?

Antoon Pardon : > You can do something like that in simula, but only because > simula has two kinds of assignments. One kind that is > simular to python and one that is similar to C. > The one that is similar that python is the reference assignment. I see Python as

Re: I'm wrong or Will we fix the ducks limp?

Op 08-06-16 om 14:34 schreef BartC: > > So you have partial updates and full updates. A proper reference will > be able to do both via the reference. Python can only do a partial > update and the reason is that the reference points to the object, not > the variable; there is no way to change the

Re: I'm wrong or Will we fix the ducks limp?

On 08/06/2016 12:01, Antoon Pardon wrote: Op 08-06-16 om 12:33 schreef BartC: But a 'proper' reference allows a complete replacement of what it refers to. That would mean being able to do: B = "Cat" print A # "Cat" No tricks involving in-place updates such as assigning to list

Re: I'm wrong or Will we fix the ducks limp?

On Wednesday, June 8, 2016 at 4:32:33 PM UTC+5:30, Antoon Pardon wrote: > It means that if you mutate the object through one variable, > you can see the result of that mutation through the other variable. But if the > assignment doesn't mutate, you can't have such effect through assignment. >

Re: I'm wrong or Will we fix the ducks limp?

Op 08-06-16 om 12:33 schreef BartC: > On 08/06/2016 10:41, Antoon Pardon wrote: >> Op 08-06-16 om 10:47 schreef Steven D'Aprano: >>> On Wednesday 08 June 2016 17:53, Antoon Pardon wrote: >>> Python could go the simula route, which has two kinds of assignment. One with the python

Re: I'm wrong or Will we fix the ducks limp?

On 08/06/2016 10:41, Antoon Pardon wrote: Op 08-06-16 om 10:47 schreef Steven D'Aprano: On Wednesday 08 June 2016 17:53, Antoon Pardon wrote: Python could go the simula route, which has two kinds of assignment. One with the python semantics and one with C semantics. Let as use := for the C

Re: I'm wrong or Will we fix the ducks limp?

Op 08-06-16 om 10:47 schreef Steven D'Aprano: > On Wednesday 08 June 2016 17:53, Antoon Pardon wrote: > >> Python could go the simula route, which has two kinds of >> assignment. One with the python semantics and one with C >> semantics. >> >> Let as use := for the C sematics assignment and <- for

Re: I'm wrong or Will we fix the ducks limp?

On Wednesday 08 June 2016 17:53, Antoon Pardon wrote: > Python could go the simula route, which has two kinds of > assignment. One with the python semantics and one with C > semantics. > > Let as use := for the C sematics assignment and <- for the > python sematics assignment. We could then do

Re: I'm wrong or Will we fix the ducks limp?

Op 07-06-16 om 18:03 schreef Steven D'Aprano: > On Tue, 7 Jun 2016 10:32 pm, Antoon Pardon wrote: > >> That people often use the shortcut "x is 999" doesn't make the statement >> wrong that variables are essentially references in Python. > No, I'm sorry, you're wrong, variables are essentially

Re: I'm wrong or Will we fix the ducks limp?

Op 07-06-16 om 17:33 schreef Random832: > On Tue, Jun 7, 2016, at 08:32, Antoon Pardon wrote: >>> Here's a thought experiment for you. Suppose in Python 3.6, Guido announces >>> that Python will support a form of high-level pointer (not the scary, >>> dangerous >>> low-level pointer of C)

Re: I'm wrong or Will we fix the ducks limp?

Random832 wrote: Er, how would that make them not first class? They wouldn't be as transparent as references in C++, which you just assign to like any other variable. That works because C++ makes a distinction between initialisation and assignment. It's not so easy to separate those in

Re: I'm wrong or Will we fix the ducks limp?

On Tue, 7 Jun 2016 10:32 pm, Antoon Pardon wrote: > That people often use the shortcut "x is 999" doesn't make the statement > wrong that variables are essentially references in Python. No, I'm sorry, you're wrong, variables are essentially arrays of bits in Python. -- Steven --

Re: I'm wrong or Will we fix the ducks limp?

On Tue, Jun 7, 2016, at 08:32, Antoon Pardon wrote: > > Here's a thought experiment for you. Suppose in Python 3.6, Guido announces > > that Python will support a form of high-level pointer (not the scary, > > dangerous > > low-level pointer of C) called "reference". There will be a dereference

Re: I'm wrong or Will we fix the ducks limp?

On Tue, Jun 7, 2016, at 03:03, Gregory Ewing wrote: > a = 42 > b = 17 > c = > c = > > does 'c' now hold a reference to the variable 'b', or > does it still hold a reference to 'a' and 'a' now > holds a reference to 'b'? It'd have to be spelled *c = , or c.value = or c.setvalue(), or something

Re: I'm wrong or Will we fix the ducks limp?

Op 07-06-16 om 12:18 schreef Steven D'Aprano: > We're talking about mental models. Sure, you could come up > with some kind of Tardis-like mental model where objects > exist in more than one location at once. But why would > you bother going to such mental contortions? > Because (self-recursive

Re: I'm wrong or Will we fix the ducks limp?

On 07/06/2016 08:56, Marko Rauhamaa wrote: Gregory Ewing : Marko Rauhamaa wrote: Seriously, though, it is notable that the high-level programming languages pretty unanimously refuse to make variables first-class objects. I wonder why. That's an interesting

Re: I'm wrong or Will we fix the ducks limp?

On Tuesday 07 June 2016 15:42, Gregory Ewing wrote: > Steven D'Aprano wrote: >> Even if you were right that objects must exist at >> a single well-defined location, that is strictly irrelevant. That's >> implementation, not interface. > > We're talking about mental models. Sure, you could come

Re: I'm wrong or Will we fix the ducks limp?

Marko Rauhamaa writes: > Gregory Ewing : > >> Marko Rauhamaa wrote: >>> Seriously, though, it is notable that the high-level programming >>> languages pretty unanimously refuse to make variables first-class >>> objects. I wonder why. >> >> That's an

Re: I'm wrong or Will we fix the ducks limp?

Gregory Ewing : > Marko Rauhamaa wrote: >> Seriously, though, it is notable that the high-level programming >> languages pretty unanimously refuse to make variables first-class >> objects. I wonder why. > > That's an interesting question. One reason might be > that in

Re: I'm wrong or Will we fix the ducks limp?

Marko Rauhamaa wrote: > [concerning leashed puppies] Note: no boxes! However, there are strings attached. Now you can truly *bind* objects to variables. If you wanted to really bind them good and proper, you'd use duct tape (or "duck tape" as some people call it -- arguably more appropriate in

Re: I'm wrong or Will we fix the ducks limp?

On Tue, Jun 7, 2016 at 4:33 PM, Gregory Ewing wrote: > Steven D'Aprano wrote: >> >> I think I'm on >> fairly solid ground to say that a language that is just like C except that >> it allocates variables in a hash table at runtime, using runtime lookups >> for variable

Re: I'm wrong or Will we fix the ducks limp?

Steven D'Aprano wrote: I think I'm on fairly solid ground to say that a language that is just like C except that it allocates variables in a hash table at runtime, using runtime lookups for variable access, would not satisfy the C89 or C99 standards. I wouldn't be so sure about that. Modern C

Re: I'm wrong or Will we fix the ducks limp?

Steven D'Aprano wrote: I never said that the string "x" is the same thing as the variable x. Maybe you didn't, but some people insist we shouldn't use the term "variable" when talking about python, but use "name" instead. I was pointing out that those two words don't have the same

Re: I'm wrong or Will we fix the ducks limp?

Steven D'Aprano wrote: Even if you were right that objects must exist at a single well-defined location, that is strictly irrelevant. That's implementation, not interface. We're talking about mental models. Sure, you could come up with some kind of Tardis-like mental model where objects exist

Re: I'm wrong or Will we fix the ducks limp?

On 06/06/2016 17:19, Steven D'Aprano wrote: (2) The "variables are like boxes" metaphor applies to static languages like C and Pascal, where the compiler has knowledge of what variables will exist. Such languages allocate space for the variables at compile time, usually using fixed memory

Re: I'm wrong or Will we fix the ducks limp?

Random832 : > The box metaphor as I understand it involves a lot of boxes, which may > contain arrows (call them pointers, references, or whatever) emerging > from them pointing to other boxes, which are all free-floating with no > implication that any of them are fixed

Re: I'm wrong or Will we fix the ducks limp?

On Mon, Jun 6, 2016, at 14:59, Steven D'Aprano wrote: > "Variables as boxes" is a long-standing, well-known metaphor for the C > and > Pascal variable model, one where the value is copied into the box > (metaphorically), or to be more precise, where variables have fixed > locations and on

Re: I'm wrong or Will we fix the ducks limp?

On Tue, 7 Jun 2016 02:57 am, Random832 wrote: > On Mon, Jun 6, 2016, at 12:19, Steven D'Aprano wrote: >> (2) The "variables are like boxes" metaphor applies to static languages >> like >> C and Pascal, where the compiler has knowledge of what variables will >> exist. Such languages allocate space

Re: I'm wrong or Will we fix the ducks limp?

On Mon, Jun 6, 2016, at 12:19, Steven D'Aprano wrote: > (2) The "variables are like boxes" metaphor applies to static languages > like > C and Pascal, where the compiler has knowledge of what variables will > exist. Such languages allocate space for the variables at compile time, > usually using

Re: I'm wrong or Will we fix the ducks limp?

On Mon, 6 Jun 2016 04:37 pm, Gregory Ewing wrote: > Steven D'Aprano wrote: >> The *name* "x" is an entity which is bound to (i.e. a reference to) the >> object 99, in some specific namespace, at some specific time. The name >> itself is an English word consisting of a single letter, "x". > >

Re: I'm wrong or Will we fix the ducks limp?

On Mon, 6 Jun 2016 02:08 pm, Random832 wrote: > On Sun, Jun 5, 2016, at 23:52, Steven D'Aprano wrote: >> Certainly not. x = y = 999 is required to bind the same object to x and >> y. > > My statement was that if two variables can be bound to the same object, > then variables *cannot* contain

Re: I'm wrong or Will we fix the ducks limp?

On Friday, June 3, 2016 at 3:20:42 PM UTC+1, Sayth Renshaw wrote: > pyqFiles = [] > for filename in sorted(file_list): > pyqFiles = pyqFiles.append(pq(filename=my_dir + filename)) This won't end well. The return value from [].append(...) is None. >>> [].append(0) is None True

Re: I'm wrong or Will we fix the ducks limp?

On 05/06/2016 07:37, Steven D'Aprano wrote: On Sun, 5 Jun 2016 01:17 pm, Lawrence D’Oliveiro wrote: On Saturday, June 4, 2016 at 3:55:12 AM UTC+12, Matt Wheeler wrote: It's best to think of them as names, rather than variables, as names in python don't behave quite how you'll expect variables

Re: I'm wrong or Will we fix the ducks limp?

On Mon, Jun 6, 2016 at 2:08 PM, Random832 wrote: > My statement was that if two variables can be bound to the same object, > then variables *cannot* contain objects. The object has to exist > somewhere, and this requirement means that the variables cannot be where > the

Re: I'm wrong or Will we fix the ducks limp?

Antoon Pardon : > A reference is not pointer. When you use a reference parameter in > Pascal, it behave like an ordinary parameter within the procedure > block, you don't have to treat it like a pointer. The word "reference" as used in the Python standards

Re: I'm wrong or Will we fix the ducks limp?

Op 06-06-16 om 05:52 schreef Steven D'Aprano: > On Mon, 6 Jun 2016 03:42 am, Random832 wrote: > >> On Sun, Jun 5, 2016, at 02:37, Steven D'Aprano wrote: >>> No they don't. You are confusing the implementation with the programming >>> model. >>> >>> Following the assignment: >>> >>> x = 99 >>> >>>

Re: I'm wrong or Will we fix the ducks limp?

Random832 : > On Sun, Jun 5, 2016, at 15:20, Marko Rauhamaa wrote: >> I say None is a wooden post, you say None is a puppy. >> >> What piece of Python code could put our dispute to rest? > > isinstance(None, object) Well, the wooden post is an object as are all puppies.

Re: I'm wrong or Will we fix the ducks limp?

Steven D'Aprano wrote: The *name* "x" is an entity which is bound to (i.e. a reference to) the object 99, in some specific namespace, at some specific time. The name itself is an English word consisting of a single letter, "x". This is one reason why the term "name" is not good subsitute for

Re: I'm wrong or Will we fix the ducks limp?

On Sun, Jun 5, 2016, at 23:52, Steven D'Aprano wrote: > Certainly not. x = y = 999 is required to bind the same object to x and > y. My statement was that if two variables can be bound to the same object, then variables *cannot* contain objects. The object has to exist somewhere, and this

Re: I'm wrong or Will we fix the ducks limp?

On Mon, 6 Jun 2016 03:42 am, Random832 wrote: > On Sun, Jun 5, 2016, at 02:37, Steven D'Aprano wrote: >> No they don't. You are confusing the implementation with the programming >> model. >> >> Following the assignment: >> >> x = 99 >> >> if you print(x), do you see something like "reference

Re: I'm wrong or Will we fix the ducks limp?

On Monday, June 6, 2016 at 1:08:21 PM UTC+12, Gregory Ewing wrote: > The only special-ish thing about [None] is that it's unique -- > there will never be another one like it, no matter how > much dog breeding you do. Fortunately, it's also immortal. Maybe not immortal, but it seems to have 533

Re: I'm wrong or Will we fix the ducks limp?

On Sunday, June 5, 2016 at 3:18:05 PM UTC+12, I wrote: > (This makes no difference for immutable objects, only mutable ones.) I retract this part. Thanks, Marko, for showing me where I was wrong. :) -- https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

Random832 wrote: There *is* a variable called None [getattr(__builtins__, 'None')] which holds a leash tied to that puppy ... But nothing's special about the object itself, no more than any other object. The only special-ish thing about it is that it's unique -- there will never be another one

Re: I'm wrong or Will we fix the ducks limp?

On 03Jun2016 16:09, Sayth Renshaw wrote: (By the way, the "pf = pf.append(thing)" construction is weird. All you need is pf.append(thing).) I got the pf = pf.append(thing) from doing pandas because in pandas its not an inplace function. In Python this doesn't do

Re: I'm wrong or Will we fix the ducks limp?

On Sun, Jun 5, 2016, at 15:20, Marko Rauhamaa wrote: > I say None is a wooden post, you say None is a puppy. > > What piece of Python code could put our dispute to rest? isinstance(None, object) Anyway, I read the "wooden post" claim as suggesting that a reference to None is somehow different

Re: I'm wrong or Will we fix the ducks limp?

Random832 : > On Sun, Jun 5, 2016, at 02:37, Steven D'Aprano wrote: >> You bind values (that is, objects) > > Values are not objects. x and z have the same value, and their objects > are identical but distinct, but they are different because they point > (or refer, or by

Re: I'm wrong or Will we fix the ducks limp?

Random832 : > On Sun, Jun 5, 2016, at 04:01, Marko Rauhamaa wrote: >> You could also think of variables as pegs, references as leashes, and >> objects as cute puppies. One puppy could be held with multiple >> leashes hung on separate pegs. Some puppies hold leashes in

Re: I'm wrong or Will we fix the ducks limp?

On Sun, Jun 5, 2016, at 04:01, Marko Rauhamaa wrote: > You could also think of variables as pegs, references as leashes, and > objects as cute puppies. One puppy could be held with multiple leashes > hung on separate pegs. Some puppies hold leashes in their mouths. Every > leash is tied to a puppy

Re: I'm wrong or Will we fix the ducks limp?

On Sun, Jun 5, 2016, at 02:37, Steven D'Aprano wrote: > No they don't. You are confusing the implementation with the programming > model. > > Following the assignment: > > x = 99 > > if you print(x), do you see something like "reference 0x12345"? No. > > Do you have to dereference that

Re: I'm wrong or Will we fix the ducks limp?

Steven D'Aprano : > On Sun, 5 Jun 2016 01:17 pm, Lawrence D’Oliveiro wrote: >> Are variables like little boxes? Yes they are. > > That's *exactly* what variables in Python are not like. Of course they are. Or, rather, the little-box mental model is no worse than any other.

Re: I'm wrong or Will we fix the ducks limp?

On Sun, 5 Jun 2016 01:17 pm, Lawrence D’Oliveiro wrote: > On Saturday, June 4, 2016 at 3:55:12 AM UTC+12, Matt Wheeler wrote: >> It's best to think of them as names, rather than variables, as names in >> python don't behave quite how you'll expect variables to if you're coming >> from some other

Re: I'm wrong or Will we fix the ducks limp?

On Saturday, June 4, 2016 at 3:55:12 AM UTC+12, Matt Wheeler wrote: > It's best to think of them as names, rather than variables, as names in > python don't behave quite how you'll expect variables to if you're coming > from some other languages. I have made heavy use of Python as well as many

Re: I'm wrong or Will we fix the ducks limp?

On Sat, 4 Jun 2016 12:50 pm, Christopher Reimer wrote: >> Nor can you uppercase a string until the string exists: >> >> s = "hello world" >> s = s.uppercase() > > >>> s = "hello world".upper() > >>> print(s) > HELLO WORLD "hello world" creates a string. Then you call .upper() on that string.

Re: I'm wrong or Will we fix the ducks limp?

On 6/3/2016 7:31 PM, Steven D'Aprano wrote: On Sat, 4 Jun 2016 09:06 am, Sayth Renshaw wrote: I cant create a list with an append method pf.append(thing) in one go . Correct. You cannot append to a list until the list exists. Nor can you uppercase a string until the string exists: s =

Re: I'm wrong or Will we fix the ducks limp?

On Sat, 4 Jun 2016 09:06 am, Sayth Renshaw wrote: > I cant create a list with an append method pf.append(thing) in one go . Correct. You cannot append to a list until the list exists. Nor can you uppercase a string until the string exists: s = "hello world" s = s.uppercase() Nor can you add

Re: I'm wrong or Will we fix the ducks limp?

On 6/3/2016 10:20 AM, Sayth Renshaw wrote: Very briefly because I hope to shot down eloquently. Python is beautiful and is supposed to be a duck typed language, Yes? Then if I create and assign to a new variable with a list action why does the duck not quack? It feels wrong to spend a line

Re: I'm wrong or Will we fix the ducks limp?

> > def getsMeet(files=file_list): > > """Get a File or List of Files. > > > > From the list of files determine > > what meetings exist and prepare them > > to be parsed > > """ > > pyqFiles = [] > > for filename in sorted(file_list): > > pyqFiles =

Re: I'm wrong or Will we fix the ducks limp?

> > pyqFiles = [] > > for filename in sorted(file_list): > > pyqFiles = pyqFiles.append(pq(filename=my_dir + filename)) > > > > return pyqFiles > > [snip] > > PS I am really having a lot of fun coding. > > To have even more fun, note that the above can be replaced by

Re: I'm wrong or Will we fix the ducks limp?

On Saturday, 4 June 2016 02:04:43 UTC+10, Michael Selik wrote: > > > That totally makes sense I was just double checking, had hoped I could > > create a variable assign it to a list and append in one stroke. > > > > In fact you can! It's called a "list comprehension" > > pyqFiles =

Re: I'm wrong or Will we fix the ducks limp?

def getsMeet(files=file_list): """Get a File or List of Files. From the list of files determine what meetings exist and prepare them to be parsed """ pyqFiles = [] for filename in sorted(file_list): pyqFiles = pyqFiles.append(pq(filename=my_dir +

Re: I'm wrong or Will we fix the ducks limp?

On Fri, 3 Jun 2016 07:20:24 -0700 (PDT), Sayth Renshaw wrote: [snip] > pyqFiles = [] > for filename in sorted(file_list): > pyqFiles = pyqFiles.append(pq(filename=my_dir + filename)) > > return pyqFiles [snip] > PS I am really having a lot of fun coding. To have even more

Re: I'm wrong or Will we fix the ducks limp?

On Fri, Jun 3, 2016 at 11:58 AM Sayth Renshaw wrote: > That totally makes sense I was just double checking, had hoped I could > create a variable assign it to a list and append in one stroke. > In fact you can! It's called a "list comprehension" pyqFiles =

Re: I'm wrong or Will we fix the ducks limp?

That totally makes sense I was just double checking, had hoped I could create a variable assign it to a list and append in one stroke. Thanks Sayth -- https://mail.python.org/mailman/listinfo/python-list

Re: I'm wrong or Will we fix the ducks limp?

Hi, On Fri, 3 Jun 2016, 16:04 Sayth Renshaw, wrote: > > So at the point I create the variable it refers to an object. > It's best to think of them as names, rather than variables, as names in python don't behave quite how you'll expect variables to if you're coming from

Re: I'm wrong or Will we fix the ducks limp?

On Fri, Jun 3, 2016 at 9:04 AM, Sayth Renshaw wrote: > > >> The problem is that you think that *variables* have a type. This isn't >> the case. Objects have a type. A variable is a name by which you can >> refer to an object. There are various ways in which you can

Re: I'm wrong or Will we fix the ducks limp?

> The problem is that you think that *variables* have a type. This isn't > the case. Objects have a type. A variable is a name by which you can > refer to an object. There are various ways in which you can associate a > object with a variable, the most obvious being an assignment statement. So

Re: I'm wrong or Will we fix the ducks limp?

Sayth Renshaw writes: > Very briefly because I hope to shot down eloquently. > > Python is beautiful and is supposed to be a duck typed language, Yes? > > Then if I create and assign to a new variable with a list action why > does the duck not quack? > > It feels wrong to

  1   2   >