Re: Data model and attribute resolution in subclasses
On Monday, March 2, 2020 at 3:12:33 PM UTC-6, Marco Sulla wrote: > Is your project published somewhere? What changes have you done to the > interpreter? I'm writing my own mess: https://github.com/rockobonaparte/cloaca It's a .NET Pythonish interpreter with the distinction of using a whole lot of async-await so I can do expressive game scripting with it in one thread. If IronPython had a handle on async-await then I'd probably not be doing this at all. Well, it was also a personal education project to learn me some Python internals for an internal company job change, but they aren't interested in me at all. :( I still hack with it because I got far enough to have a REPL I could dump into Unity and it immediately looked very useful. -- https://mail.python.org/mailman/listinfo/python-list
Re: Data model and attribute resolution in subclasses
On Monday, March 2, 2020 at 7:09:24 AM UTC-6, Lele Gaifax wrote: > Yes, you just used it, although you may have confused its meaning: > Yeah I absolutely got it backwards. That's a fun one I have to fix in my project now! -- https://mail.python.org/mailman/listinfo/python-list
Re: Data model and attribute resolution in subclasses
On Fri, 28 Feb 2020 at 08:28, Adam Preble wrote: > > I have been making some progress on my custom interpreter project Is your project published somewhere? What changes have you done to the interpreter? -- https://mail.python.org/mailman/listinfo/python-list
Re: Data model and attribute resolution in subclasses
Adam Preble writes: > On Sunday, March 1, 2020 at 3:08:29 PM UTC-6, Terry Reedy wrote: > >> Because BaseClass is the superclass of SubClass. > > So there's a mechanism for parent classes to know all their children? Yes, you just used it, although you may have confused its meaning: >>> class Base: ... pass ... >>> class Derived(Base): ... pass ... >>> print(Base.__subclasses__()) [] ciao, lele. -- nickname: Lele Gaifax | Quando vivrò di quello che ho pensato ieri real: Emanuele Gaifas | comincerò ad aver paura di chi mi copia. l...@metapensiero.it | -- Fortunato Depero, 1929. -- https://mail.python.org/mailman/listinfo/python-list
Re: Data model and attribute resolution in subclasses
On Sunday, March 1, 2020 at 3:08:29 PM UTC-6, Terry Reedy wrote: > Because BaseClass is the superclass of SubClass. So there's a mechanism for parent classes to know all their children? -- https://mail.python.org/mailman/listinfo/python-list
Re: Data model and attribute resolution in subclasses
On 3/1/2020 4:49 AM, Adam Preble wrote: Based on what I was seeing here, I did some experiments to try to understand better what is going on: class BaseClass: def __init__(self): self.a = 1 def base_method(self): return self.a def another_base_method(self): return self.a + 1 class SubClass(BaseClass): def __init__(self): super().__init__() self.b = 2 c = SubClass() print(c.__dict__) print(c.__class__.__dict__) print(c.__class__.__subclasses__()) print(c.__class__.mro()) print(c.__class__.mro()[1].__dict__) print(getattr(c, "base_method")) print(c.b) print(c.a) print(c.__class__.__subclasses__()) [] What?! Why isn't this []? Because BaseClass is the superclass of SubClass. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: Data model and attribute resolution in subclasses
Based on what I was seeing here, I did some experiments to try to understand
better what is going on:
class BaseClass:
def __init__(self):
self.a = 1
def base_method(self):
return self.a
def another_base_method(self):
return self.a + 1
class SubClass(BaseClass):
def __init__(self):
super().__init__()
self.b = 2
c = SubClass()
print(c.__dict__)
print(c.__class__.__dict__)
print(c.__class__.__subclasses__())
print(c.__class__.mro())
print(c.__class__.mro()[1].__dict__)
print(getattr(c, "base_method"))
print(c.b)
print(c.a)
With some notes:
print(c.__dict__)
{'a': 1, 'b': 2}
So the instance directly has a. I am guessing that the object's own dictionary
is directly getting these are both __init__'s are run.
print(c.__class__.__dict__)
{'__module__': '__main__', '__init__': , '__doc__': None}
I am guessing this is what is found and stuffed into the class' namespace when
the class is built; that's specifically the BUILD_CLASS opcode doing its thing.
print(c.__class__.__subclasses__())
[]
What?! Why isn't this []?
print(c.__class__.mro())
[, , ]
This is more like what I expected to find with subclasses. Okay, no, method
resolution order is showing the entire order.
print(c.__class__.mro()[1].__dict__)
{'__module__': '__main__', '__init__': , 'base_method': , 'another_base_method': , '__dict__': , '__weakref__': , '__doc__': None}
No instance-level stuff. Looks like it's the base class namespace when the
BUILD_CLASS opcode saw it. Okay, looking good.
print(getattr(c, "base_method"))
>
I'm guessing here it didn't find it in the object's __dict__ nor the class'
__dict__ so it went in mro and found it in BaseClass.
So I need a __dict__ for the class based on the code defined for it when the
class is defined. That's associated with the class. I need another dictionary
for each instance. That will get stuffed with whatever started getting dumped
into it in __init__ (and possibly elsewhere afterwards).
What __dict__ actually is can vary. The mappingproxy helps make sure that
strings are given as keys (among other things?).
--
https://mail.python.org/mailman/listinfo/python-list
Re: Data model and attribute resolution in subclasses
On 2/28/2020 2:21 AM, Adam Preble wrote:
I have been making some progress on my custom interpreter project but I found I
have totally blown implementing proper subclassing in the data model. What I
have right now is PyClass defining what a PyObject is. When I make a PyObject
from a PyClass, the PyObject sets up a __dict__ that is used for attribute
lookup. When I realized I needed to worry about looking up parent namespace
stuff, this fell apart because my PyClass had no real notion of a namespace.
I'm looking at the Python data model for inspiration. While I don't have to
implement the full specifications, it helps me where I don't have an
alternative. However, the data model is definitely a programmer document; it's
one of those things where the prose is being very precise in what it's saying
and that can foil a casual reading.
Here's what I think is supposed to exist:
1. PyObject is the base.
2. It has an "internal dictionary." This isn't exposed as __dict__
The internal mapping *is* visible.
>>> object.__dict__
mappingproxy({'__repr__': ,
'__hash__': , '__str__':
, '__getattribute__': wrapper '__getattribute__' of 'object' objects>, '__setattr__': wrapper '__setattr__' of 'object' objects>, '__delattr__': '__delattr__' of 'object' objects>, '__lt__': 'object' objects>, '__le__': objects>, '__eq__': ,
'__ne__': , '__gt__': wrapper '__gt__' of 'object' objects>, '__ge__': of 'object' objects>, '__init__': objects>, '__new__': 0x7FFBEFE989A0>, '__reduce_ex__': 'object' objects>, '__reduce__': objects>, '__subclasshook__': objects>, '__init_subclass__': objects>, '__format__': ,
'__sizeof__': , '__dir__':
, '__class__': '__class__' of 'object' objects>, '__doc__': 'The base class of the
class hierarchy.\n\nWhen called, it accepts no arguments and returns a
new featureless\ninstance that has no instance attributes and cannot be
given any.\n'})
The internal mapping is not an instance of dict, and need/should not be
as it is frozen.
>>> o = object()
>>> o.a = 3
Traceback (most recent call last):
File "", line 1, in
o.a = 3
AttributeError: 'object' object has no attribute 'a'
When classes and objects do have a dict __dict__, __dict__ is not in
__dict__, to avoid recursion. gettattribute or __getattribute__ must
special case '__dict__'. I am guessing this as what must be from the
evidence, without seeing the actual code.
3. PyClass subclasses PyObject.
4. PyClass has a __dict__
Is there a term for PyObject's internal dictionary. It wasn't called __dict__
and I think that's for good reasons. I guess the idea is a PyObject doesn't
have a namespace, but a PyClass does (?).
Now to look something up. I assume that __getattribute__ is supposed to do
something like:
1. The PyClass __dict__ for the given PyObject is consulted.
2. The implementation for __getattribute__ for the PyObject will default to looking into
the "internal dictionary."
3. Assuming the attribute is not found, the subclasses are then consulted using
the subclass' __getattribute__ calls. We might recurse on this. There's
probably some trivia here regarding multiple inheritance; I'm not entirely
concerned (yet).
For non-reserved names Attribute lookup starts with the object dict,
then object class, then superclasses. Dunder names usually start with
the object class.
4. Assuming it's never found, then the user sees an AttributeError
Would each of these failed lookups result in an AttributeError?
I presume so. They are caught and only re-raised only if there is no
where else to look.
--
Terry Jan Reedy
--
https://mail.python.org/mailman/listinfo/python-list
Data model and attribute resolution in subclasses
I have been making some progress on my custom interpreter project but I found I have totally blown implementing proper subclassing in the data model. What I have right now is PyClass defining what a PyObject is. When I make a PyObject from a PyClass, the PyObject sets up a __dict__ that is used for attribute lookup. When I realized I needed to worry about looking up parent namespace stuff, this fell apart because my PyClass had no real notion of a namespace. I'm looking at the Python data model for inspiration. While I don't have to implement the full specifications, it helps me where I don't have an alternative. However, the data model is definitely a programmer document; it's one of those things where the prose is being very precise in what it's saying and that can foil a casual reading. Here's what I think is supposed to exist: 1. PyObject is the base. 2. It has an "internal dictionary." This isn't exposed as __dict__ 3. PyClass subclasses PyObject. 4. PyClass has a __dict__ Is there a term for PyObject's internal dictionary. It wasn't called __dict__ and I think that's for good reasons. I guess the idea is a PyObject doesn't have a namespace, but a PyClass does (?). Now to look something up. I assume that __getattribute__ is supposed to do something like: 1. The PyClass __dict__ for the given PyObject is consulted. 2. The implementation for __getattribute__ for the PyObject will default to looking into the "internal dictionary." 3. Assuming the attribute is not found, the subclasses are then consulted using the subclass' __getattribute__ calls. We might recurse on this. There's probably some trivia here regarding multiple inheritance; I'm not entirely concerned (yet). 4. Assuming it's never found, then the user sees an AttributeError Would each of these failed lookups result in an AttributeError? I don't know how much it matters to me right now that I implement exactly to that, but I was curious if that's really how that goes under the hood. -- https://mail.python.org/mailman/listinfo/python-list
Relational data model, relations, and relationships (was: To whoever hacked into my Database)
Dennis Lee Bieber writes: > On Fri, 08 Nov 2013 13:31:02 +, Mark Lawrence > declaimed the following: > > >The only relational database that has no relationships as effectively > >there's only one table, despite what Denis McMahon (amongst others?) > >has said. Relational databases aren't about implementing relationships between tables. They're about implementing the relational data model http://www.c2.com/cgi/wiki?RelationalModel> http://www.c2.com/cgi/wiki?RelationalDatabase>. > In terms of relational database theory -- "relation" IS what > most people call a "table": the dependent data is "related" to the > primary key of the table. Yes. In databases using SQL, one table implements a relation, where “relation” is a term of art from relational data theory. > Foreign keys to other tables are part of the definition. And between two relations connected by a foreign key, there exists a relationship — which is *not* what the “relational” in relational databases are about. Confusing? Yep. Relational theory is *not* a theory about relationship between tables. Relational databases are so called not because of relationships between tables, but because they implement relational theory. -- \ “It is the integrity of each individual human that is in final | `\examination. On personal integrity hangs humanity's fate.” | _o__) —Richard Buckminster Fuller, _Critical Path_, 1981 | Ben Finney -- https://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
In article <4dc7fa2f$0$29991$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano wrote: >On Mon, 09 May 2011 12:52:27 +1200, Gregory Ewing wrote: > >> Steven D'Aprano wrote: >> >>> Since you haven't explained what you think is happening, I can only >>> guess. >> >> Let me save you from guessing. I'm thinking of a piece of paper with a >> little box on it and the name 'a' written beside it. There is an arrow >> from that box to a bigger box. >> >> +-+ >> +---+ | | >> a | --+>| | >> +---+ | | >> +-+ >> >> There is another little box labelled 'b'. After executing 'a = b', both >> little boxes have arrows pointing to the same big box. >[...] >> In this model, a "reference" is an arrow. Manipulating references >> consists of rubbing out the arrows and redrawing them differently. > >All very good, but that's not what takes place at the level of Python >code. It's all implementation. I think Hans Georg Schaathun made a good >objection to the idea that "Python has references": > >In Pascal a pointer is a distinct data type, and you can >have variables of a given type or of type pointer to that >given type. That makes the pointer a concrete concept >defined by the language. > >The same can't be said of "references" in Python. It's not part of Python >the language, although it might be part of Python's implementation. > > > >> Also >> in this model, a "variable" is a little box. It's *not* the same thing >> as a name; a name is a label for a variable, not the variable itself. > >That's essentially the same model used when dealing with pointers. I've >used it myself, programming in Pascal. The "little box" named a or b is >the pointer variable, and the "big box" is the data that the pointer >points to. > >It's not an awful model for Python: a name binding a = obj is equivalent >to sticking a reference (a pointer?) in box a that points to obj. >Certainly there are advantages to it. > >But one problem is, the model is ambiguous with b = a. You've drawn >little boxes a and b both pointing to the big box (which I deleted for >brevity). But surely, if a = 1234 creates a reference from a to the big >box 1234, then b = a should create a reference from b to the box a? There are cleaner languages. Algol 68 , Forth. This is Forth. VARIABLE A VARIABLE B 1234 ( anonymous "object" created by the language ) A ! A @ B !( Copy the content, equivalent of B=A). Algol 68 B:=A compiler : THINK ! THINK ! A is a "ref int" so it can't be stored into b which is a "ref int" which is the name of a place where an int can be stored (not where a ref int could be stored.) Solution: Algol dereferences A into an int, by getting its content. But it is a rule, very explicitly explained in the language definition. (If you are that clean you can handle "ref ref int q" where q is the name of a place where a "ref int" can be stored.) "real a" is in fact an abbreviation of "ref real a=loc real" meaning "a" is a reference to a local real, that is anonymous. The = means that the connection between a and that real is an identity, i.e. the connection can't be broken. (Forget about C++, "casting away const", yuck! ) In Forth and in Algol 68 storing a constant into a variable is very different from copying the content of a variable to some other variable. > >-- >Steven Groetjes Albert -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
In article , Chris Angelico wrote: >On Sat, May 7, 2011 at 7:21 PM, Gregory Ewing > wrote: >> Hans Georg Schaathun wrote: >> >>> You cannot reference nor manipulate a reference in python, and that IMHO >>> makes them more abstract. >> >> You can manipulate them just fine by moving them >> from one place to another: > >I think "manipulate" here means things like pointer arithmetic, which >are perfectly normal and common in C and assembly, but not in >languages where they're references. Adding an integer to a reference to an array element could have been perfectly well-defined in Algol: ref real operator+(ref real, int) That is called overloading of the plus operator not "pointer arithmetic". It is a misconception that these manipulation are dirty or ill-defined or unsafe. A similar extension would be possible in Python. Allusion to assembler where one adds a number to a register and can't tell whether the register contains an address or data are misleading. [This is not to say that I think it is advisable]. > >Chris Angelico Groetjes Albert. -- -- Albert van der Horst, UTRECHT,THE NETHERLANDS Economic growth -- being exponential -- ultimately falters. albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Chris Angelico wrote: There has to be a way to get from some mythical "home" location (which we know in Python as locals()+globals()+current expression - the "current namespace") to your object. That might involve several names, or none at all, but if there's no such path, the object is unreferenced and must be disposed of. Yes, that's what I mean by "bound to some anonymous thing". Somewhere in the implementation there must be one or more "root" references, but they don't necessarily have any names that you can refer to from Python. When I say "not bound to any name", I just mean that it's okay to leave some bindings out of your diagram if they're not pertinent to what you're trying to illustrate. For example, you can draw a box representing a string object and trust that something will keep it alive long enough for you to draw an arrow to it from the name you're assigning it to. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 5/10/2011 3:41 AM, Gregory Ewing wrote: Actually, you're right. What I've presented is a paper-and-pencil implementation of the Python data model. Together with a set of rules for manipulating the diagram under the direction of Python code, you have a complete implementation of Python that you can execute in your head. I think that it would be both fun and useful to have an animated graphical tutorial that used and box and arrow model. Names should be in ovals (instead of the little boxes used here due to text limitations) to differentiate them from objects. Immutable objects could have solid boundaries and mutables a broken line boundary. Collection objects would have dotted lines to separate slots. Ovals could also use different lines for builtins, globals, and locals. And you NEED such an implementation in order to reason correctly about Python programs under all circumstances. I find it very difficult to imagine *any* implementation of Python, computer-based or otherwise, that doesn't have something equivalent to references. Whether you call them that, or pointers, or arrows, or object bindings, or something else, the concept needs to be there in some form. Since namespaces link names in a namespace with objects not in the namespace, any practical implementation needs a third entity to link or associated each name with an object. This is pretty much needed to explain multiple links without objects being in multiple locations. It is also needed to explain how an object can link to itself. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Wed, May 11, 2011 at 1:40 AM, Hans Georg Schaathun wrote: > On Wed, 11 May 2011 01:27:36 +1000, Chris Angelico > wrote: > : Language is for communication. If we're not using the same meanings > : for words, we will have problems. > > So if you adopt the word class to mean a type (or composite type), > as in python, what word would you use for a class of types (as in > haskell or ada)? > > I think there are too many meanings and too few words ... > > That's why some languages support overloading. Of course. Nobody ever said that one name had to point to one value... oh wait. Yes, Virginia, there is overloading. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Wed, 11 May 2011 01:27:36 +1000, Chris Angelico wrote: : Language is for communication. If we're not using the same meanings : for words, we will have problems. So if you adopt the word class to mean a type (or composite type), as in python, what word would you use for a class of types (as in haskell or ada)? I think there are too many meanings and too few words ... That's why some languages support overloading. I am afraid we just need to cope with it, overloading I mean. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Wed, May 11, 2011 at 1:16 AM, Grant Edwards wrote: > And what do we mean by "agree"? > > What do we mean by "mean"? > > It's turtles all they down... When I use a word, it means just what I choose it to mean - neither more nor less. -- Humpty Dumpty. Language is for communication. If we're not using the same meanings for words, we will have problems. Chris Angelico PS. By "mean", I mean average. Except when I mean mean. But now I'm just being mean. -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 2011-05-10, Hans Georg Schaathun wrote: > On Tue, 10 May 2011 14:05:34 + (UTC), Grant Edwards > wrote: >: Because it's easier to communicate if everybody agrees on what a word >: means. > > Why should we agree on that particular word? Are there any other words > we agree about? Other key words, such as class, object, or function don't > have universal meanings. And what do we mean by "agree"? What do we mean by "mean"? It's turtles all they down... -- Grant Edwards grant.b.edwardsYow! at gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Tue, 10 May 2011 14:05:34 + (UTC), Grant Edwards wrote: : Because it's easier to communicate if everybody agrees on what a word : means. Why should we agree on that particular word? Are there any other words we agree about? Other key words, such as class, object, or function don't have universal meanings. :-) -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 2011-05-10, Gregory Ewing wrote: > Steven D'Aprano wrote: > >> It's just that the term "variable" is so useful and so familiar that it's >> easy to use it even for languages that don't have variables in the C/ >> Pascal/Fortran/etc sense. > > Who says it has to have the Pascal/Fortran/etc sense? Because it's easier to communicate if everybody agrees on what a word means. -- Grant Edwards grant.b.edwardsYow! The SAME WAVE keeps at coming in and COLLAPSING gmail.comlike a rayon MUU-MUU ... -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Tue, May 10, 2011 at 12:29 AM, Steven D'Aprano wrote: > If objects can be in two places at once, why can't names? Just because. Because then you'd need some way to identify which object you wanted to refer to - something like name[0] and name[1]. A tuple is one effective way to do this (sort of - actually, the name points at the tuple and the tuple points at each of the objects). On Tue, May 10, 2011 at 12:47 PM, MRAB wrote: > I had heard something about the meaning of the word "gift", so I > checked in Google Translate. For Swedish "gift" it says: > > noun > 1. POISON > 2. VENOM > 3. TOXIN > 4. VIRUS Beware of Swedes bearing gifts! On Tue, May 10, 2011 at 5:41 PM, Gregory Ewing wrote: > Anonymous objects are fine. You just draw a little box and > don't write any label beside it. Or you don't bother drawing > a little box at all and just draw a big box until such time > as some little box that you care about needs to point to it. > > If that's a problem, then you have the same problem talking > about names bound to objects. An anonymous object obviously > doesn't have any name bound to it. So you have to admit that > objects can exist, at least temporarily, without being bound > to anything, or bound to some anonymous thing. There has to be a way to get from some mythical "home" location (which we know in Python as locals()+globals()+current expression - the "current namespace") to your object. That might involve several names, or none at all, but if there's no such path, the object is unreferenced and must be disposed of. IIRC that's not just an implementation detail (the garbage collector), but a language guarantee (that the __del__ method will be called). Names are immaterial to that. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Steven D'Aprano wrote:
All very good, but that's not what takes place at the level of Python
code. It's all implementation.
Actually, you're right. What I've presented is a paper-and-pencil
implementation of the Python data model. Together with a set of
rules for manipulating the diagram under the direction of Python
code, you have a complete implementation of Python that you can
execute in your head.
And you NEED such an implementation in order to reason correctly
about Python programs under all circumstances.
I find it very difficult to imagine *any* implementation of
Python, computer-based or otherwise, that doesn't have something
equivalent to references. Whether you call them that, or pointers,
or arrows, or object bindings, or something else, the concept
needs to be there in some form.
But surely, if a = 1234 creates a reference from a to the big
box 1234, then b = a should create a reference from b to the box a?
+-+
+---+ | |
a | --+>| |
+---+ | |
^ +-+
|
+-|-+
b | | |
+---+
You can't expect anyone to draw correct conclusions from the
diagram alone; you also need to explain the rules for manipulating
the diagram under control of Python code.
Here, the explanation goes something like this:
1. The right hand side of an assignment denotes a big box. The
literal 1234 in a program denotes a big box containing the integer
value 1234.
2. The left hand side of an assignment denotes a little box. The
effect of an assignment is to make the arrow from the left hand
side's little box point to the big box denoted by the right hand
side.
So the assignment a = 1234 results in
+-+
+---+ | |
a | --+>| 1234 |
+---+ | |
+-+
3. When a name is used on the right hand side, it denotes whichever
big box is pointed to by the arrow from its little box. So given
the above diagram, the assignment b = a results in
+-+
+---+ | |
a | --+>| 1234 |
+---+ | |
+-+
^
+---+|
b | --+-
+---+
Furthermore, from rule 2 alone it's evident that no assignment
can ever make an arrow lead from one little box to another
little box. Arrows can only lead from a little box to a big
box.
That's how it works in C and Pascal (well, at least with the appropriate
type declarations).
Um, no, it doesn't, really. There's no way 'b = a' can give
you that in C; you would have to write 'b = &a'. And you
couldn't do it at all in standard Pascal, because there is
no equivalent to the & operator there.
Your model is closer to what the CPython implementation
actually does,
I think it's close -- actually, I would say isomorphic --
to what *any conceivable* Python implementation would do in
some form.
n = len('hello world')
What about outside len? Where's the little box
pointing to 'hello world'?
So it seems your model fails to deal with sufficiently anonymous objects.
Anonymous objects are fine. You just draw a little box and
don't write any label beside it. Or you don't bother drawing
a little box at all and just draw a big box until such time
as some little box that you care about needs to point to it.
If that's a problem, then you have the same problem talking
about names bound to objects. An anonymous object obviously
doesn't have any name bound to it. So you have to admit that
objects can exist, at least temporarily, without being bound
to anything, or bound to some anonymous thing.
Both the call to len and the call to func push their results onto the
stack. There's no little box pointing to the result.
If you want to model things at that level of detail, then the
stack itself is an array of little boxes inside a frame object.
And the frame object is pointed to by a little box in its
calling frame object, etc. until you get to some global little
box, that doesn't have a name in Python, but exists somewhere
and keeps the chain of active stack frames alive.
But you don't have to draw any of that if you don't want to.
For practical reasons, there must be some sort of
indirection. But that's implementation and not the VM's model.
No, it's not just implementation. Indirection is needed for
*correct semantics*, not just practicality.
There is a problem with my model o
Re: What other languages use the same data model as Python?
On Tue, 10 May 2011 13:49:04 +1200, Gregory Ewing wrote: > Steven D'Aprano wrote: > >> It's just that the term "variable" is so useful and so familiar that >> it's easy to use it even for languages that don't have variables in the >> C/ Pascal/Fortran/etc sense. > > Who says it has to have the Pascal/Fortran/etc sense? Why should static > languages have a monopoly on the use of the term? That seems like a > rather languagist attitude! Established usage. They came first, and outnumber us :/ But I wouldn't quite say they have a monopoly of the term. Where there is no risk of misunderstanding, it's fine to use the term. Mathematicians' "variable" is different still, but there's very little risk of misunderstanding. I'm far less cautious about using "variable" when I'm talking to you, because I know you won't be confused, than I would be when talking to a newbie, who may be. When two people use the same words, but their understanding of them are slightly different, it's often easier to change the terminology than it is to break people's preconceptions and connotations. > And BTW, applying it to Python is not inconsistent with its usage in > Pascal. In the technical vocabulary of Pascal, a "variable" is anything > that can appear on the left hand side of an assignment. The analogous > term in C is "lvalue". Sure, but if you think Python "variables" behave like Pascal "variables", you'll may be surprised by Python and wonder why integer arguments are call by value and list arguments are call by reference... -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 10/05/2011 02:51, Gregory Ewing wrote: Steven D'Aprano wrote: Or Chinese Gooseberries, better known by the name thought up by a marketing firm, "kiwi fruit". And I'm told that there is a language (one of the Nordic ones, IIRC) where "kiwi" means "stone". So in that country they wonder why they should be getting so excited about something called a "stonefruit". :-) I had heard something about the meaning of the word "gift", so I checked in Google Translate. For Swedish "gift" it says: noun 1. POISON 2. VENOM 3. TOXIN 4. VIRUS adjective 1. MARRIED 2. WEDDED -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Steven D'Aprano wrote: Or Chinese Gooseberries, better known by the name thought up by a marketing firm, "kiwi fruit". And I'm told that there is a language (one of the Nordic ones, IIRC) where "kiwi" means "stone". So in that country they wonder why they should be getting so excited about something called a "stonefruit". :-) -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Steven D'Aprano wrote: It's just that the term "variable" is so useful and so familiar that it's easy to use it even for languages that don't have variables in the C/ Pascal/Fortran/etc sense. Who says it has to have the Pascal/Fortran/etc sense? Why should static languages have a monopoly on the use of the term? That seems like a rather languagist attitude! And BTW, applying it to Python is not inconsistent with its usage in Pascal. In the technical vocabulary of Pascal, a "variable" is anything that can appear on the left hand side of an assignment. The analogous term in C is "lvalue". -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Gregory Ewing wrote: +-+ +---+ | | a | --+>| | +---+ | | +-+ ^ +---+ | b | --+---| +---+ In this model, a "reference" is an arrow. Manipulating references consists of rubbing out the arrows and redrawing them differently. Greg, this is an excellent model, thank you for taking the time to put it together for the list... very helpful. Both Summerfield and Lutz use the same model (and almost the identical graphic symbolism) to explain dynamic typing in Python. Summerfield's Programming in Python 3 2nd ed. has a good explanation similar, see pages 17 and 32 (there are others). Lutz has an entire chapter devoted to the topic in Learning Python 4th ed., see chapter six. He calls it the Dynamic Typing Interlude. The model is in-the-field and very workable; and yet, it does have limitations, as most models do. For visual thinkers this model probably comes closest to being most helpful, esp in the beginning. kind regards, m harris -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Mon, 9 May 2011 21:18:29 +1000, Chris Angelico wrote: : Analogies are like diagrams. Not all of them are perfect or useful. : : The boxes are different sizes. If you really want them to look : different, do one as squares and one as circles, but don't try that in : plain text. Analogies, even imperfect ones, are good when we are clear about the fact that they are analogies. Using C pointers to illustrate how to use bound names in python may be useful, but only if we are clear about the fact that it is an analogy and do not pretend that it explains it in full. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 5/9/2011 10:29 AM, Steven D'Aprano wrote: If people then ask, how does the interpreter know the names?, I can add more detail: names are actually strings in a namespace, which is usually nothing more than a dict. Oh, and inside functions, it's a bit more complicated still. And so on. Which is why I think it best to stick with 'A namespace is a many-to-one mapping (in other words, a function) of names to objects'. Any programmer should understand the abstractions 'mapping' and 'function'. Asking how the interpreter finds the object associated with a name amounts to asking how to do tabular lookup. Well, we basically know, though the details depends on the implementation of the table (mapping). An interpreter can *implement* namespaces various ways. One is to objectify names and namespaces as strings and dicts. If the set of names in a namespace is fixed, another way is to objectify names and namespaces as ints and arrays. Python prohibits 'from x import *' within functions precisely to keep the set of local namespace names fixed. Therefore, CPython can and does always use C ints and array for function local namespaces. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Steven D'Aprano wrote: > It's not an awful model for Python: a name binding a = obj is equivalent > to sticking a reference (a pointer?) in box a that points to obj. > Certainly there are advantages to it. > > But one problem is, the model is ambiguous with b = a. You've drawn > little boxes a and b both pointing to the big box (which I deleted for > brevity). But surely, if a = 1234 creates a reference from a to the big > box 1234, then b = a should create a reference from b to the box a? :) There's a way around that too. Describe literals as "magic names" or "Platonic names" that are bound to objects in ideal space. I actually considered that for a while as a way of explaining to newbs why the characters in a string literal could be different from the characters in the string value. This would probably have troubles of its own; I never took it through the knock-down drag-out disarticulation that would show what the problems were. Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Steven D'Aprano wrote: But that's wrong! Names (little boxes) can't point to *slots in a list*, any more than they can point to other names! This doesn't work: --> L = [None, 42, None] --> a = L[0] --> L[0] = 23 --> print(a) # This doesn't work! 23 Minor nitpick -- having a comment saying "this doesn't work" then having output showing that it does is confusing. I had to load up the interpretor to make sure I was confused! ;) ~Ethan~ -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 09/05/2011 15:29, Steven D'Aprano wrote: [... snippage galore ...] Slightly abstract comment: while I don't usually get much enjoyment out of the regular "Python is call-by-value; no it isn't; yes it is" debates, I always enjoy reading Steven D'Aprano's responses. Thanks, Mr D'A. :) TJG -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
re than they can point to other names! This doesn't work: >>> L = [None, 42, None] >>> a = L[0] >>> L[0] = 23 >>> print(a) # This doesn't work! 23 It's a pity that Python doesn't actually have references. Imagine how much time we'd save: all the unproductive time we spend arguing about whether Python has references, we could be fixing bugs caused by the use of references instead... > But without any little boxes or arrows, you can't represent the list > itself as a coherent object. You would have to go around and label > various objects with 'a[0]', 'a[1]', etc. > > +-+ >a[0] | | > | | > | | > +-+ > > +-+ > a[1] | | > | | > | | > +-+ > > This is not very satisfactory. If the binding of 'a' changes, you have > to hunt for all your a[i] labels, rub them out and rewrite them next to > different objects. It's hardly conducive to imparting a clear > understanding of what is going on, whereas the boxes-and-arrows model > makes it instantly obvious. But I wouldn't do it like that. I'd do it like this: 01234 ++++++ a |||||| |||||| |||||| ++++++ which conveniently happens to be the way Python lists actually are set up. More or less. [...] > Finally, there's another benefit of considering a reference to be a > distinct entity in the data model. If you think of the little boxes as > being of a fixed size, just big enough to hold a reference, then it's > obvious that you can only bind it to *one* object at a time. Otherwise > it might appear that you could draw more than one arrow coming out of a > name, or write the same name next to more than one object. But that's pretty much an arbitrary restriction. Why are the boxes so small? Just because. Why can't you carefully tease the thread of blutack apart, into a bifurcated Y shaped thread? Just because. If objects can be in two places at once, why can't names? Just because. (Actually, because Guido decrees it so. Also because it would be kinda crazy to do otherwise. I can't think of any language that has a many:many mapping between names and values.) -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Mon, May 9, 2011 at 8:38 PM, Hans Georg Schaathun wrote: > The flaw of this model, and I am not discounting its merits, just > pointing out that it isn't perfect, is that it creates the illusion > that references are boxes (objects) just like data objects, leading > the reader to think that we could have a reference to a reference. > If they are all boxes, by can't we make reference thereto? http://www.xkcd.com/895/ Analogies are like diagrams. Not all of them are perfect or useful. The boxes are different sizes. If you really want them to look different, do one as squares and one as circles, but don't try that in plain text. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Mon, 09 May 2011 12:52:27 +1200, Gregory Ewing wrote: : Let me save you from guessing. I'm thinking of a piece of paper with : a little box on it and the name 'a' written beside it. There is an : arrow from that box to a bigger box. : : +-+ :+---+ | | : a | --+>| | :+---+ | | : +-+ The flaw of this model, and I am not discounting its merits, just pointing out that it isn't perfect, is that it creates the illusion that references are boxes (objects) just like data objects, leading the reader to think that we could have a reference to a reference. If they are all boxes, by can't we make reference thereto? -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Sat, 07 May 2011 21:21:45 +1200, Gregory Ewing wrote: : You can manipulate them just fine by moving them : from one place to another: : : a = b : : You can use them to get at stuff they refer to: : : a = b.c : a[:] = b[:] Surely you can refer to the objects, but you cannot refer to the reference. : You can compare them: : : if a is b: : ... This could be implemented as pointer comparison, but it is not defined as such and there is no requirement that it be. : That's about all you can do with pointers in Pascal, : and I've never heard anyone argue that Pascal pointers : are any more or less abstract than any other piece of : data in that language. In Pascal a pointer is a distinct data type, and you can have variables of a given type or of type pointer to that given type. That makes the pointer a concrete concept defined by the languagedefined by the language. -- :-- Hans Georg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Steven D'Aprano wrote: Since you haven't explained what you think is happening, I can only guess. Let me save you from guessing. I'm thinking of a piece of paper with a little box on it and the name 'a' written beside it. There is an arrow from that box to a bigger box. +-+ +---+ | | a | --+>| | +---+ | | +-+ There is another little box labelled 'b'. After executing 'a = b', both little boxes have arrows pointing to the same big box. +-+ +---+ | | a | --+>| | +---+ | | +-+ ^ +---+ | b | --+---| +---+ In this model, a "reference" is an arrow. Manipulating references consists of rubbing out the arrows and redrawing them differently. Also in this model, a "variable" is a little box. It's *not* the same thing as a name; a name is a label for a variable, not the variable itself. It seems that you would prefer to eliminate the little boxes and arrows and write the names directly beside the objects: +-+ a | | | | b | | +-+ +-+ c | | | | | | +-+ But what would you do about lists? With little boxes and arrows, you can draw a diagram like this: +---+ +---+ a | --+->| | +-+ +---+ +---+ | | | --+->| | +---+ | | | | +-+ +---+ (Here, the list is represented as a collection of variables. That's why variables and names are not the same thing -- the elements of the list don't have textual names.) But without any little boxes or arrows, you can't represent the list itself as a coherent object. You would have to go around and label various objects with 'a[0]', 'a[1]', etc. +-+ a[0] | | | | | | +-+ +-+ a[1] | | | | | | +-+ This is not very satisfactory. If the binding of 'a' changes, you have to hunt for all your a[i] labels, rub them out and rewrite them next to different objects. It's hardly conducive to imparting a clear understanding of what is going on, whereas the boxes-and-arrows model makes it instantly obvious. There is a half-way position, where we use boxes to represent list items, but for bare names we just draw the arrow coming directly out of the name: +---+ a ->| | +-+ +---+ | | | --+->| | +---+ | | | | +-+ +---+ But this is really just a minor variation. It can be a useful shorthand, but it has the drawback of making it seem as though the binding of a bare name is somehow different from the binding of a list element, when it isn't really. Finally, there's another benefit of considering a reference to be a distinct entity in the data model. If you think of the little boxes as being of a fixed size, just big enough to hold a reference, then it's obvious that you can only bind it to *one* object at a time. Otherwise it might appear that you could draw more than one arrow coming out of a name, or write the same name next to more than one object. It seems to me that the boxes-and-arrows model, or something isomorphic to it, is the most abstract model you can make of Python that captures everything necessary to reason about it both easily and correctly. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Sun, May 8, 2011 at 4:16 PM, Dennis Lee Bieber wrote:
> On Sun, 08 May 2011 10:54:57 +1200, Gregory Ewing
> declaimed the following in
> gmane.comp.python.general:
>
>>
>> What would *you* call a[i]?
>>
> Depending upon the nature of the beast, I'd be tempted to call it a
> "fully qualified name" or a "partially qualified name"
>
> a = [1, 2, 4, ("c", "d", "e")]
Why is an integer more or less important than a tuple? a[3] is no less
qualified than a[2]; each of them points to an object. One of those
objects happens to contain other objects.
What if you had:
stdio = [stdin, stdout, stderr]
They might be 'file' objects, or they might be integers (unlikely in
Python), or they could be pipes or other file-like objects, or they
might be some kind of special tee object that contains two file
objects. Let's say your standard I/O uses the notation
stdout.write('message') and that you have a subclass of tuple that
will apply the . operator to all its members (is that possible in
Python? If not, pretend it is). You could then execute
stdio[1]=(stdout,teeobject) to easily copy your screen output to
another file. At this point, you can actually pretend that stdio[0]
and stdio[1] are identical objects, but you can use stdio[1][1] and
you can't use stdio[0][1] - which means that, per your definition, one
of them is only partially qualified.
As Inigo Montoya said, there is too much - let me sum up. Lists/tuples
and integers are equally objects, so whether or not you have a 'name'
is not affected by what type of object it points to.
Chris Angelico
--
http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On May 8, 7:17 am, Steven D'Aprano wrote: > On Sat, 07 May 2011 21:21:45 +1200, Gregory Ewing wrote: > > Hans Georg Schaathun wrote: > > >> You cannot reference nor manipulate a reference in python, and that > >> IMHO makes them more abstract. > > > You can manipulate them just fine by moving them from one place to > > another: > > > a = b > > I see no reference there, nor do I see any moving taking place. What I > see is a name binding operation. What is happening is that the name "a" > is being bound to the object "b" (or to be precise, to whatever object is > currently bound to name "b"). > > Since you haven't explained what you think is happening, I can only > guess. My guess is that you are thinking about some implementation of the > Python VM which uses some sort of reference internally. Perhaps it's > CPython, which uses pointers, or some C++ implementation which actually > uses an indirect pointer-like data structure called "reference", or maybe > even some old-time FORTRAN I implementation that simulates pointers with > integer indexes into a fixed size array. It could be anything. > > But whatever you're thinking of, it's not the behaviour of *Python* code, > it's behaviour of the Python virtual machine's implementation. > > It astonishes me how hard it is to distinguish between abstraction levels > when discussing computer languages. We don't have this problem in other > fields. Nobody talking about (say) Solitaire on a computer would say: > > "Blat the pixels in the rect A,B,C,D to the rect E,F,G,H. That will free > up the Ace of Spades and allow you to memcopy the records in the far > right column of the tableau into the foundation." > > but when it comes to high-level computer languages like Python, we do the > equivalent *all the time*. It has to be so -- because the Turing machine like the modern computer is an unbelievable abstraction squasher. Yes unbelievable in the sense that people simply cant come to terms with this. [Witness your "It astonishes me..." Harris: "I take exception.." etc] The modern computer (von Neumann) <- self-modifying code <- Data=Code <- Undecidability (Halting problem) <- Consistency XOR Completeness (Godels theorem(s)) <- Leaky Abstractions as inevitable If anyone thinks Godels theorems are easy trivial, he probably does not know what he is talking about, Yet we think that computers are easy to understand? [Ive personally witnessed PhDs in computer science not appreciate compilers' inability to do certain things, and yet they could go and take a bunch of lectures on the halting problem. What they understand is anybody's guess :-) ] Coming back to topic: The argument (about bindings, variables etc) arises because python (like lisp) is an imperative language masquerading as a functional one. Such arguments dont arise in Haskell or in assembly language. They arise and are tolerable in C. They are terrible in C++ because all the abstractions are built to leak. Where python sits in this (circular) spectrum is an interesting question (and I watch the arguments with much interest) -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Steven D'Aprano wrote: Nobody talking about (say) Solitaire on a computer would say: "Blat the pixels in the rect A,B,C,D to the rect E,F,G,H. That will free up the Ace of Spades and allow you to memcopy the records in the far right column of the tableau into the foundation." but when it comes to high-level computer languages like Python, we do the equivalent *all the time*. I find exception to that argument. That is an example of the bogus analogy fallacy. (I am offering this in friendship, actually). The two cases have nothing to do with one another, do not affect one another directly or indirectly, and are not helpful for comparison sake. Analogies are generally not helpful in discussion and ought to be avoided generally... except for entertainment sake... and frankly I have found many of your analogies most entertaining (and creative) ! Second point, we seldom do anything *all the time* / this is a fallacy that presupposes extreme references, as we think about the argument; extreme exageration is not helpful... may or may not be rightly extreme, and may or may not be relevant. What can be said (about the argument) is that we sometimes waste time arguing over abstraction layers with limited cross-dependent understanding. (I include myself in this.) (myself, as well) ... the humility is appreciated. And people get into (often angry) arguments over definitions, when what they're really arguing about is what is happening at different abstraction levels. Sometimes. More often than not, folks are not really angry (I am seldom angry at my computer terminal... its one of the places where I relax, learn, communicate, and relate with other computer scientists who enjoy what they do because its enjoyable. I do agree with you that we all sometimes talk past each other because we're arguing from within a 'different' level of abstraction. kind regards, m harris -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Sat, 07 May 2011 21:21:45 +1200, Gregory Ewing wrote: > Hans Georg Schaathun wrote: > >> You cannot reference nor manipulate a reference in python, and that >> IMHO makes them more abstract. > > You can manipulate them just fine by moving them from one place to > another: > > a = b I see no reference there, nor do I see any moving taking place. What I see is a name binding operation. What is happening is that the name "a" is being bound to the object "b" (or to be precise, to whatever object is currently bound to name "b"). Since you haven't explained what you think is happening, I can only guess. My guess is that you are thinking about some implementation of the Python VM which uses some sort of reference internally. Perhaps it's CPython, which uses pointers, or some C++ implementation which actually uses an indirect pointer-like data structure called "reference", or maybe even some old-time FORTRAN I implementation that simulates pointers with integer indexes into a fixed size array. It could be anything. But whatever you're thinking of, it's not the behaviour of *Python* code, it's behaviour of the Python virtual machine's implementation. It astonishes me how hard it is to distinguish between abstraction levels when discussing computer languages. We don't have this problem in other fields. Nobody talking about (say) Solitaire on a computer would say: "Blat the pixels in the rect A,B,C,D to the rect E,F,G,H. That will free up the Ace of Spades and allow you to memcopy the records in the far right column of the tableau into the foundation." but when it comes to high-level computer languages like Python, we do the equivalent *all the time*. (I include myself in this.) And people get into (often angry) arguments over definitions, when what they're really arguing about is what is happening at different abstraction levels. A simplified view: At the Python level: binding of objects to names. No data is copied except by use of a direct "copy" instruction, e.g. slicing. At the Python VM level: objects pushed and popped from a stack. At the VM implementation level: Name binding may be implemented by copying pointers, or some other reference, in some data structure representing name spaces. Or by any other mechanism you like, so long as the behaviour at the Python level is the same. At the assembly language level: memory is copied from one address to another. At the hardware level: we usually describe bit manipulation in terms of binary AND, XOR and OR, but even that may be an abstraction: it's possible that the only binary op physically used by the machine is NAND. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Gregory Ewing writes: > Ben Finney wrote: > > > No, I think not. The term “variable” usually comes with a strong > > expectation that every variable has exactly one name. > > I would say that many variables don't have names *at all*, unless you > consider an expression such as a[i] to be a "name". Again, our disagreement is not over the behaviour of Python, but over what an average newcomer to Python can be expected to understand by the term “variable” from its usage elsewhere in programming. > What would *you* call a[i]? What *I* would call that isn't relevant to the point. I do think it's even more misleading to call that “a variable”, though, since it's not what the Python docs call a variable and it's not what an average newcomer would call a variable. It's a reference. So is ‘a’, so is ‘i’; names are a special kind of reference. In Python, references are how we get at objects within our code, and names are one kind of reference. -- \ “Not using Microsoft products is like being a non-smoker 40 or | `\ 50 years ago: You can choose not to smoke, yourself, but it's | _o__) hard to avoid second-hand smoke.” —Michael Tiemann | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Sun, May 8, 2011 at 8:54 AM, Gregory Ewing wrote: > Ben Finney wrote: > >> No, I think not. The term “variable” usually comes with a strong >> expectation that every variable has exactly one name. > > I would say that many variables don't have names *at all*, > unless you consider an expression such as a[i] to be > a "name". And if you *do* consider that to be a name, > then clearly one variable can have a great many names. > > What would *you* call a[i]? a is a variable; i is a variable; a[i] is an expression. It's not a single name, and if you had two variables i and j with the same value, nobody would disagree that a[i] and a[j] ought to be the same thing. That's the whole point of arrays/lists/etc/etc. But if you want to fry your noggin, wrap your head around REXX's compound variables: a=5 b=3 array.a.b="Hello" /* see, this is a two-dimensional array */ c=63/10 array.c="world!" /* see, we can have non-integers as array indices */ d=a+1 result = array.a.b", "array.d.b /* "Hello, world!" */ So what is a "name" in REXX? You have to evaluate the compound variable as a set of tokens, then evaluate the whole thing again, and is that the name? Because the resulting "name" might not be a valid identifier... Yep, it's good stuff. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Ben Finney wrote: No, I think not. The term “variable” usually comes with a strong expectation that every variable has exactly one name. I would say that many variables don't have names *at all*, unless you consider an expression such as a[i] to be a "name". And if you *do* consider that to be a name, then clearly one variable can have a great many names. What would *you* call a[i]? -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Chris Angelico wrote: I think "manipulate" here means things like pointer arithmetic, I don't believe that allowing arithmetic on pointers is a prerequisite to considering them first-class values. You can't do arithmetic on pointers in Pascal, for example, but nobody argues that Pascal pointers are not values. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
In article <87aaeymfww@benfinney.id.au>, Ben Finney wrote: > No, I think not. The term âvariableâ usually comes with a strong > expectation that every variable has exactly one name. Heh. You've never used common blocks in Fortran? Or, for that matter, references in C++? I would call either of those "two names for the same variable". -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Gregory Ewing writes: > > On Thu, 05 May 2011 07:43:59 +1000, Ben Finney wrote: > > > >>‘x’ is a name. Names are bound to values. Talk of “variable” only > >>confuses the issue because of the baggage carried with that term. > > But to use 'name' as a complete replacement for 'variable', I don't propose doing that. > In Python I use 'variable' to mean more or less 'something that can be > assigned to', which accords with the way it's used in relation to many > other languages, and doesn't suggest any restriction to things named > by a single identifier. No, I think not. The term “variable” usually comes with a strong expectation that every variable has exactly one name. Your more broad usage would need to be carefully explained to newbies anyway, so I don't see a good reason to use the term “variable” for that either. > Seems to me that anyone taking that connotation from it has not yet > been sufficiently educated about the Python data model itself. Yes, of course. But why not meet such newcomers partway, by not confusing the issue with a term which needs such delicate treatment? > >>Saying “variable” and “has the value” > > But I don't say "has a value", I say "refers to". Good for you. Most don't. -- \ Q: “I've heard that Linux causes cancer...” Torvalds: “That's a | `\ filthy lie. Besides, it was only in rats and has not been | _o__) reproduced in humans.” —Linus Torvalds | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Gregory Ewing wrote: > because modern architectures are so freaking complicated > that it takes a computer to figure out the best instruction > sequence certainly is, I would not imagine one who writes on scraps of paper :D :D :D -- goto /dev/null -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 2011-05-07, Gregory Ewing wrote: > Grant Edwards wrote: >> if you feel it just right and you have just the >>>right synchro-mesh setup, you can slide from 3rd into 4th without >>>every touching the clutch peddle... >> >>>and if that isn't automatic, I don't know what is >> >> No, that's _not_ automatic if you have to do it yourself. It's >> automatic when it happens without user-intervention. > > Does it count if the transmission is activated > by saying "Home, Jeeves"? Only if your name is Bertie Wooster. -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Grant Edwards wrote: if you feel it just right and you have just the right synchro-mesh setup, you can slide from 3rd into 4th without every touching the clutch peddle... and if that isn't automatic, I don't know what is No, that's _not_ automatic if you have to do it yourself. It's automatic when it happens without user-intervention. Does it count if the transmission is activated by saying "Home, Jeeves"? -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Andreas Tawn wrote: If True and False: waveFunction.collapse(cat) Call-by-entanglement would be interesting. Anything that the callee does to the parameter would affect the caller, but you would only be able to tell by examining a trace of the output afterwards. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Thu, 05 May 2011 07:43:59 +1000, Ben Finney wrote: ‘x’ is a name. Names are bound to values. Talk of “variable” only confuses the issue because of the baggage carried with that term. But to use 'name' as a complete replacement for 'variable', you have to stretch it to include things like a[i], b.c, e.f(x).g[i:j].k, etc. which goes rather a long way beyond the everyday meaning of the word. In Python I use 'variable' to mean more or less 'something that can be assigned to', which accords with the way it's used in relation to many other languages, and doesn't suggest any restriction to things named by a single identifier. But the data model of Python doesn't fit well with the ideas that the term “variable” connotes for most programmers: Seems to me that anyone taking that connotation from it has not yet been sufficiently educated about the Python data model itself. Part of explaining that data model consists of instilling the very idea that the things in Python that are analogous to variables in other languages only refer to data rather than containing the actual data. Saying “variable” and “has the value” But I don't say "has a value", I say "refers to". -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
John Nagle wrote: Such tuples are still identical, even if they contain identical references to immutable objects. The point is you'd have to do the comparison only one level deep, so it wouldn't be exactly the same as == on tuples. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Sat, May 7, 2011 at 7:21 PM, Gregory Ewing wrote: > Hans Georg Schaathun wrote: > >> You cannot reference nor manipulate a reference in python, and that IMHO >> makes them more abstract. > > You can manipulate them just fine by moving them > from one place to another: I think "manipulate" here means things like pointer arithmetic, which are perfectly normal and common in C and assembly, but not in languages where they're references. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Hans Georg Schaathun wrote: You cannot reference nor manipulate a reference in python, and that IMHO makes them more abstract. You can manipulate them just fine by moving them from one place to another: a = b You can use them to get at stuff they refer to: a = b.c a[:] = b[:] You can compare them: if a is b: ... That's about all you can do with pointers in Pascal, and I've never heard anyone argue that Pascal pointers are any more or less abstract than any other piece of data in that language. As for "referencing" a reference, you can't really do that in Pascal either, at least not the way you can in C, because (plain) Pascal doesn't have an address-of operator. The only way to get a pointer to a pointer in Pascal is to heap-allocate a single pointer, which isn't normally a very useful thing to do. -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Sat, May 7, 2011 at 5:25 AM, harrismh777 wrote: > Chris Torek wrote: >>> >>> with the Python-named-Monty, we have "rigidly defined areas of >>> >doubt and uncertainty". These exist for good reasons: to allow >>> >different implementations. >> >> Oops, attribution error: this comes from Douglas Adams rather >> than Monty Python. > > Well, its certainly Monte-esq I like it, whoever said it. Same style of humour, they both derived significantly from Spike Milligan and "The Goon Show". That particular quote relates to the famous computer that calculated the number 42, which - to drag this, kicking and screaming, back to some semblance of on-topicness - was clearly built with a view to conserving programmer time at the expense of execution time. I don't understand why they didn't just recode the heavy computation in C and cut it down to just a few thousand years... Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Chris Torek wrote: with the Python-named-Monty, we have "rigidly defined areas of >doubt and uncertainty". These exist for good reasons: to allow >different implementations. Oops, attribution error: this comes from Douglas Adams rather than Monty Python. Well, its certainly Monte-esq I like it, whoever said it. -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
In article I wrote, in part: >Like it or not, Python has similar "defined as undefined" grey >areas: one is not promised, for instance, whether the "is" operator >is always True for small integers that are equal (although it is >in CPython), nor when __del__ is called (if ever), and so on. As >with the Python-named-Monty, we have "rigidly defined areas of >doubt and uncertainty". These exist for good reasons: to allow >different implementations. Oops, attribution error: this comes from Douglas Adams rather than Monty Python. -- In-Real-Life: Chris Torek, Wind River Systems Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603 email: gmail (figure it out) http://web.torek.net/torek/index.html -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
In article
harrismh777 wrote:
>There may be some language somewhere that does pass-by-reference which
>is not implemented under the hood as pointers, but I can't think of
>any... 'cause like I've been saying, way down under the hood, we only
>have direct and indirect memory addressing in today's processors. EOS.
There have been Fortran compilers that implemented modification of
variables via "value-result" rather than "by-reference".
This is perhaps best illustrated by some code fragments:
SUBROUTINE FOO(X, Y)
INTEGER X, Y
...
X = 3
Y = 4
RETURN
SUBROUTINE BAR(A)
FOO(A, 0)
RETURN
might compile to the equivalent of the following C code:
void foo(int *x0, int *y0) {
int x = *x0, y = *y0;
...
*x0 = x;
*y0 = y;
}
void bar(int *a0) {
int a = *a0;
int temp = 0;
foo(&a, &temp);
*a0 = a;
}
In order to allow both by-reference and value-result, Fortran
forbids the programmer to peek at the machinery. That is, the
following complete program is invalid:
SUBROUTINE PEEK(X)
INTEGER X, GOTCHA
COMMON /BLOCK/ GOTCHA
PRINT *, 'INITIALLY GOTCHA = ', GOTCHA
X = 4
PRINT *, 'AFTER X=4 GOTCHA = ', GOTCHA
RETURN
PROGRAM MAIN
INTEGER GOTCHA
COMMON /BLOCK/ GOTCHA
GOTCHA = 3
PEEK(GOTCHA)
PRINT *, 'FINALLY GOTCHA = ', GOTCHA
STOP
END
(It has been so long since I used Fortran that the above may not
be quite right in ways other than the one intended. Please forgive
small errors. :-) )
The trick in "subroutine peek" is that it refers to both a "global
variable" (in Fortran, simulated with a common block) and a "dummy
variable" (as it is termed in Fortran) -- the parameter that aliases
the global variable -- in such a way that we can see *when* the
change happens. If "gotcha" starts out set to 3, remains 3 after
assignment to x, and changes to 4 after peek() returns, then peek()
effectively used value-result to change the parameter. If, on the
other hand, "gotcha" became 4 immediately after the assignment to
x, then peek() effectively used by-reference.
The key take-away here is not so much the trick by which we "peeked
inside" the implementation (although peeking *is* useful in solving
the "murder mystery" we have after some program aborts with a
core-dump or what-have-you), but rather the fact that the Fortran
language proper forbids us from peeking at all. By forbidding it
-- by making the program illegal -- the language provide implementors
the freedom to use *either* by-reference or value-result. All
valid Fortran programs behave identically under either kind of
implementation.
Like it or not, Python has similar "defined as undefined" grey
areas: one is not promised, for instance, whether the "is" operator
is always True for small integers that are equal (although it is
in CPython), nor when __del__ is called (if ever), and so on. As
with the Python-named-Monty, we have "rigidly defined areas of
doubt and uncertainty". These exist for good reasons: to allow
different implementations.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html
--
http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
>>> John Nagle wrote:
A reasonable compromise would be that "is" is treated as "==" on
immutable objects.
(Note: I have no dog in this fight, I would be happy with a changed
"is" or with the current one -- leaky abstractions are fine with
me, provided I am told *when* they may -- or sometimes may not --
leak. :-) )
>> On 5/5/2011 3:06 AM, Gregory Ewing wrote:
>>> That wouldn't work for tuples, which can contain references
>>> to other objects that are not immutable.
>On Thu, May 5, 2011 at 9:41 AM, John Nagle wrote:
>> Such tuples are still identical, even if they
>> contain identical references to immutable objects.
In article
Ian Kelly wrote:
a = (1, 2, [3, 4, 5])
b = (1, 2, [3, 4, 5])
a == b
>True
a is b # Using the proposed definition
>True
I believe that John Nagle's proposal would make "a is b" false,
because while a and b are both immutable, they contain *different*
refernces to *mutable* objects (thus failing the "identical
references to immutable objects" part of the claim).
On the other hand, should one do:
L = [3, 4, 5]
a = (1, 2, L)
b = (1, 2, L)
then "a is b" should (I say) be True under the proposal -- even
though they contain (identical) references to *mutable* objects.
Loosely speaking, we would define the "is" relation as:
(x is y) if and only if
(id(x) == id(y)
or
(x is immutable and y is immutable and
(for all components xi and yi of x, xi is yi)))
In this case, even if the tuples "a" and "b" have different id()s,
we would find that both have an immutable type, and both have
components -- in this case, numbered, subscriptable tuple elements,
but instances of immutable class types like decimal.Decimal would
have dictionaries instead -- and thus we would recursively apply
the modified "is" definition to each element. (For tuples, the
"all components" implies that the lengths must be equal; for class
instances, it implies that they need to have "is"-equal attributes,
etc.)
It's not entirely clear to me whether different immutable classes
(i.e., different types) but with identical everything-else should
compare equal under this modified "is". I.e., today:
$ cp /usr/lib/python2.?/decimal.py /tmp/deccopy.py
$ python
...
>>> sys.path.append('/tmp')
>>> import decimal
>>> import deccopy
>>> x = decimal.Decimal('1')
>>> y = deccopy.Decimal('1')
>>> print x, y
1 1
>>> x == y
False
and obviously "x is y" is currently False:
>>> type(x)
>>> type(y)
However, even though the types differ, both x and y are immutable
[%] and obviously (because I copied the code) they have all the
same operations. Since they were both created with the same starting
value, x and y will behave identically given identical treatment.
As such, it might be reasonable to ask that "x is y" be True
rather than False.
[% This is not at all obvious -- I have written an immutable class,
and it is pretty easy to accidentally mutate an instance inside
the class implementation. There is nothing to prevent this in
CPython, at least. If there were a minor bug in the decimal.Decimal
code such that x.invoke_bug() modified x, then x would *not* be
immutable, even though it is "intended to be". (As far as I know
there are no such bugs in decimal.Decimal, it's just that I had
them in my "Money" class.)]
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: gmail (figure it out) http://web.torek.net/torek/index.html
--
http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 2011-05-05, Chris Angelico wrote: > On Fri, May 6, 2011 at 1:29 AM, Roy Smith wrote: >> "Hey, let's override operator,() and have some fun" > > Destroying sanity, for fun and profit. I was thinking more along the lines of stuff like combining the envelope pattern (an interface class containing a pointer to an implementation) with template classes to create type-safe polymorphic types with specializable, decoupled implementations. A Python programmer just feels depressed that anyone could have a need for such innovations, though. ;) -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Fri, May 6, 2011 at 1:29 AM, Roy Smith wrote: > "Hey, let's override operator,() and have some fun" Destroying sanity, for fun and profit. Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Fri, May 6, 2011 at 2:27 AM, Andreas Tawn wrote: > If True and False: > waveFunction.collapse(cat) > > > That's going to be fun ;o) If a process crashes and init isn't there to hear it, does it produce a core dump? Chris Angelico -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Ian Kelly wrote: On the other hand, the @ syntax is analogous to declaring reference types in C++ (e.g. "int&" as opposed to "int *"). In both cases you have to tell the interpreter / compiler that you want to use the decoration / pass-by-reference feature, and the actual work is done for you automatically. [ @Ian, Neil ] :)... uh, it was worth a shot... No, I see your point... with the slight small push-back that dereferencing a pointer with '*' can't really be called 'work' can it? ( I know, you'll say yes, because the 'compiler' didn't do it ! ) :)) -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Thu, May 5, 2011 at 10:58 AM, harrismh777 wrote: > Grant Edwards wrote: >> >> That's what I was trying to say, but probably not as clearly. The "&" >> operatore returnas a_value_ that the OP passes_by_value_ to a >> function. That function then uses the "*" operator to use that value >> to access some data. > > I'm gonna try a D'Aprano-style bogus argument for a moment... > > ... saying that 'C' does not support pass-by-reference because you have to > direct the compiler with the '&' and '*' characters is a little like saying > that > > Python does not support decorations ! ... > > > ... because you have to direct the interpreter with some > > > @ bogus-decorator-syntax > > > I want Python to support decorations automatically ! It seems to me that manually referencing and dereferencing in C is more akin to decorating functions like this: def foo(x): do_stuff() foo = decorate(foo) On the other hand, the @ syntax is analogous to declaring reference types in C++ (e.g. "int &" as opposed to "int *"). In both cases you have to tell the interpreter / compiler that you want to use the decoration / pass-by-reference feature, and the actual work is done for you automatically. -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 5/5/2011 9:19 AM, Neil Cerutti wrote: On 2011-05-04, John Nagle wrote: That's a quirk of CPython's boxed number implementation. All integers are boxed, but there's a set of canned objects for small integers. CPython's range for this is -5 to +256, incidentally. That's visible through the "is" operator. Arguably, it should not be. But that's the sole purpose of the is operator. You either expose those details, or you don't have an is operator at all. Which is to say, the CPython testsuite has a CPython-specific implementation test that uses 'is' to test that implementation detail. -- Terry Jan Reedy -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 2011-05-05, harrismh777 wrote: > ... saying that 'C' does not support pass-by-reference because > you have to direct the compiler with the '&' and '*' characters > is a little like saying that > > Python does not support decorations ! ... > > > ... because you have to direct the interpreter with some > > > @ bogus-decorator-syntax > > > I want Python to support decorations automatically ! You do have to declare decorators when defining them, but they are called automatically when you call the decorated function, with no special syntax required. C pointers don't automatically dereference themselves. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Ethan Furman wrote: PS My thanks to those who kept explaining in various ways about the difference between language supported features and programmer constructs -- I hadn't realized before this thread that call-by-reference was not a language feature of C, but rather a programmer-implemented feature using the C operators. You are most welcome. :) -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
harrismh777 wrote: Grant Edwards wrote: I give up. You don't seem to understand the C language defintion or what is commonly meant by "pass by reference". ah, don't give up... here is a link that might help to clarify some of these semantics... me thinks: http://en.wikipedia.org/wiki/Pass_by_reference#Call_by_value Indeed it does (emphasis added): "In call-by-reference evaluation (also referred to as pass-by-reference), a function receives an *implicit* reference to a variable used as argument" In C the the reference is explicit, which the article states in the next paragraph: "Even among languages that don't exactly support call-by-reference, many, including C and ML, support explicit references (objects that refer to other objects), such as pointers" ~Ethan~ PS My thanks to those who kept explaining in various ways about the difference between language supported features and programmer constructs -- I hadn't realized before this thread that call-by-reference was not a language feature of C, but rather a programmer-implemented feature using the C operators. -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Grant Edwards wrote: No, that's_not_ automatic if you have to do it yourself. It's automatic when it happens without user-intervention. Now I think you're trolling... ... no, I was only kidding... :) -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Grant Edwards wrote: That's what I was trying to say, but probably not as clearly. The "&" operatore returnas a_value_ that the OP passes_by_value_ to a function. That function then uses the "*" operator to use that value to access some data. I'm gonna try a D'Aprano-style bogus argument for a moment... ... saying that 'C' does not support pass-by-reference because you have to direct the compiler with the '&' and '*' characters is a little like saying that Python does not support decorations ! ... ... because you have to direct the interpreter with some @ bogus-decorator-syntax I want Python to support decorations automatically ! ;-) -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 2011-05-05, Neil Cerutti wrote: > On 2011-05-05, Roy Smith wrote: >> Of course, C++ lets you go off the deep end with abominations >> like references to pointers. Come to think of it, C++ let's >> you go off the deep end in so many ways... > > But you can do some really cool stuff in the deep end. Until you get pulled under and drowned by some flailing goof who oughtn't be there. -- Grant Edwards grant.b.edwardsYow! Zippy's brain cells at are straining to bridge gmail.comsynapses ... -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 2011-05-05, Roy Smith wrote:
> In article ,
> Grant Edwards wrote:
>
>> That's what I was trying to say, but probably not as clearly. The "&"
>> operatore returnas a _value_ that the OP passes _by_value_ to a
>> function. That function then uses the "*" operator to use that value
>> to access some data.
>
> Then, of course, there's references in C++. I think it's fair to call
> the following "call by reference" in the sense we're talking about it
> here.
>
> void f(int& i) {
>i = 5;
> }
> int i = 42;
> f(i);
If after the call to f(i) the caller sees that i == 5, then that's
call by reference. But, we were talking about C.
> Of course, C++ lets you go off the deep end with abominations like
> references to pointers. Come to think of it, C++ let's you go off
> the deep end in so many ways...
:)
--
Grant Edwards grant.b.edwardsYow! Is this sexual
at intercourse yet?? Is it,
gmail.comhuh, is it??
--
http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 2011-05-05, harrismh777 wrote: > Steven D'Aprano wrote: >> In fairness, he's not the only one. M Harris has twice now linked to an >> IBM site that describes pass-by-reference in C in terms of passing a >> pointer to the argument you want as the argument. Admittedly, doing so >> gives you almost the same behaviour, except that you have to dereference >> the pointers yourself. >> >> That's a pretty big difference though, and gets to the core of the >> argument: it's a bit like arguing that manual cars are fitted with >> exactly the same automatic transmission as auto cars, it's just that you >> have to engage the clutch and shift gears yourself. > > > ... and actually, if you feel it just right and you have just the > right synchro-mesh setup, you can slide from 3rd into 4th without > every touching the clutch peddle... That's possible on pretty much any modern automotive or small-truck transmission, and it's not really that hard to do. I can go from 1st up to 5th and back down to 1st without touching the clutch. I don't as a habit do it, because it puts unnecessary wear on the syncros (and I've had cars with pretty weak syncros -- Alfa-Romeo Spyders were famous for the 2nd gear syncro wearing out). > and if that isn't automatic, I don't know what is No, that's _not_ automatic if you have to do it yourself. It's automatic when it happens without user-intervention. Now I think you're trolling... -- Grant Edwards grant.b.edwardsYow! I want to dress you at up as TALLULAH BANKHEAD and gmail.comcover you with VASELINE and WHEAT THINS ... -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 2011-05-05, Steven D'Aprano wrote: > On Thu, 05 May 2011 14:14:22 +, Grant Edwards wrote: > >> On 2011-05-05, harrismh777 wrote: >>> Grant Edwards wrote: The "pass by value" and "pass by reference" parameter passing mechanisms are pretty well defined, and C uses "pass by value". >>> >>> Yeah, that's kind-a funny, cause I'm one of the guys (old farts) that >>> helped define them >> >> I give up. You don't seem to understand the C language defintion or >> what is commonly meant by "pass by reference". > > > In fairness, he's not the only one. M Harris has twice now linked to an > IBM site that describes pass-by-reference in C in terms of passing a > pointer to the argument you want as the argument. Admittedly, doing so > gives you almost the same behaviour, except that you have to dereference > the pointers yourself. > > That's a pretty big difference though, and gets to the core of the > argument: it's a bit like arguing that manual cars are fitted with > exactly the same automatic transmission as auto cars, it's just that > you have to engage the clutch and shift gears yourself. I like that analogy. "My car has an automatic transmission except you have to shift gears yourself with that lever and that it has a clutch operated by that pedal instead of a hydrostatic torque converter." -- Grant Edwards grant.b.edwardsYow! ... bleakness at ... desolation ... plastic gmail.comforks ... -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Thu, May 5, 2011 at 9:41 AM, John Nagle wrote: > On 5/5/2011 3:06 AM, Gregory Ewing wrote: >> >> John Nagle wrote: >> >>> A reasonable compromise would be that "is" is treated as "==" on >>> immutable objects. >> >> That wouldn't work for tuples, which can contain references >> to other objects that are not immutable. > > Such tuples are still identical, even if they > contain identical references to immutable objects. >>> a = (1, 2, [3, 4, 5]) >>> b = (1, 2, [3, 4, 5]) >>> a == b True >>> a is b # Using the proposed definition True >>> a[0] is b[0] True >>> a[1] is b[1] True >>> a[2] is b[2] False >>> a[2].append(6) >>> a (1, 2, [3, 4, 5, 6]) >>> b (1, 2, [3, 4, 5]) >>> a == b False >>> a is b False Thus a and b cannot be used interchangeably even though "a is b" originally returned True. -- http://mail.python.org/mailman/listinfo/python-list
RE: What other languages use the same data model as Python?
> Steven D'Aprano wrote: > > > Some day, we'll be using quantum computers without memory addresses, > [ ... > ] it will still be possible to > > represent data indirectly via *some* mechanism. > > :) Cool! Pass-by-coincidence! And Python 3 already has dibs on the > 'nonlocal' keyword! > > Mel. > If True and False: waveFunction.collapse(cat) That's going to be fun ;o) Cheers, Drea -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Grant Edwards wrote: I give up. You don't seem to understand the C language defintion or what is commonly meant by "pass by reference". ah, don't give up... here is a link that might help to clarify some of these semantics... me thinks: http://en.wikipedia.org/wiki/Pass_by_reference#Call_by_value kind regards, m harris -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Steven D'Aprano wrote: In fairness, he's not the only one. M Harris has twice now linked to an IBM site that describes pass-by-reference in C in terms of passing a pointer to the argument you want as the argument. Admittedly, doing so gives you almost the same behaviour, except that you have to dereference the pointers yourself. That's a pretty big difference though, and gets to the core of the argument: it's a bit like arguing that manual cars are fitted with exactly the same automatic transmission as auto cars, it's just that you have to engage the clutch and shift gears yourself. ... and actually, if you feel it just right and you have just the right synchro-mesh setup, you can slide from 3rd into 4th without every touching the clutch peddle... and if that isn't automatic, I don't know what is man those were the days... now I just press a button that says, "Auto 4-wheel Lock", set the gps, and take a nap... :) -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 5/5/2011 6:59 AM, Steven D'Aprano wrote: On Thu, 05 May 2011 21:48:20 +1000, Chris Angelico wrote: On Thu, May 5, 2011 at 9:44 PM, Mel wrote: John Nagle wrote: On 5/4/2011 5:46 PM, harrismh777 wrote: Or, as stated earlier, Python should not allow 'is' on immutable objects. A reasonable compromise would be that "is" is treated as "==" on immutable objects. I foresee trouble testing among float(5), int(5), Decimal(5) ... Define 'x is y' as 'type(x)==type(y) and isinstance(x,(int,float,tuple,etc,etc,etc)) and x==y' then. That's close to the right answer. `is` is supposed to be a *fast* operator, not even slower than equality testing. That's an implementation problem. Those are cheap tests at the machine code level. An efficient test looks like this: def istest(a, b) : if id(a) == id(b) : # the cheap address test return(True) if type(x) != type(y) : # cheap binary comparison return(False) if mutable(x) : # the interpreter knows this return(False) return(x == y) # equality test for mutables Probably about 12 machine instructions, and the full "==" test is only reached for cases in which "is" now produces wrong answers. It's encouraging that a Google code search finds no matches of if .* is \" or if .* is 1 in Python code. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Mel wrote: represent data indirectly via*some* mechanism. :) Cool! Pass-by-coincidence! And Python 3 already has dibs on the 'nonlocal' keyword! I was thinking pass-by-osmosis :) -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Thu, 05 May 2011 07:43:59 +1000, Ben Finney wrote: > Steven D'Aprano writes: > >> Given the following statement of Python code: >> >> >>> x = "spam" >> >> what is the value of the variable x? > > Mu (無). > > ‘x’ is a name. Names are bound to values. Talk of “variable” only > confuses the issue because of the baggage carried with that term. Yes, good point. Consider me chastised, because I actually knew that. It's just that the term "variable" is so useful and so familiar that it's easy to use it even for languages that don't have variables in the C/ Pascal/Fortran/etc sense. > But the data model of Python doesn't fit well with the ideas that the > term “variable” connotes for most programmers: a box, perhaps of a rigid > shape (data type) or not, which is labelled ‘x’ and nothing else. For > another variable to have an equal value, that value needs to be copied > and put in a separate box; or perhaps some special reference to the > original needs to be made and placed in a box. > > Saying “variable” and “has the value” just invites baggage needlessly, > and creates many assumptions about Python's data model which has to be > un-done, often after much false mental scaffolding has been built on > them by the newbie and needs to be dismantled carefully. I've quoted your two paragraphs because I think they're very important, not because I intend arguing. Possibly a first for me :) However > Python isn't pass by anything. Nothing gets copied, nothing gets passed; > when a function is called with an object as a parameter, the object > stays put, and simply gets a new temporary name bound to it for the > function's use. This, however, is incorrect. "Passing" in this sense refers to calling the function with an argument, hence "pass by..." and "call by..." are synonyms. The mechanics of how the compiler or interpreter makes arguments available to functions has real consequences at the language level: the calling strategy used by the compiler effects the language semantics. >> > Whatever, a rose by any other name...) >> >> Do you really think that roses would be the symbol of romantic love if >> they were called "disgusting stink-weeds of perversion and death"? > > Juliet's point stands, though: they would still smell as sweet, and the > term you describe would be unlikely to catch on since it doesn't > describe them well at all. Perhaps a counter-example is that of the tomato, which never took off as a food in Europe until people stopped calling them "love apples", and thinking that they were deadly poison. Or Chinese Gooseberries, better known by the name thought up by a marketing firm, "kiwi fruit". -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 5/5/2011 3:06 AM, Gregory Ewing wrote: John Nagle wrote: A reasonable compromise would be that "is" is treated as "==" on immutable objects. That wouldn't work for tuples, which can contain references to other objects that are not immutable. Such tuples are still identical, even if they contain identical references to immutable objects. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Steven D'Aprano wrote: > Some day, we'll be using quantum computers without memory addresses, [ ... ] it will still be possible to > represent data indirectly via *some* mechanism. :) Cool! Pass-by-coincidence! And Python 3 already has dibs on the 'nonlocal' keyword! Mel. -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
In article <92fsvjfkg...@mid.individual.net>, Neil Cerutti wrote: > On 2011-05-05, Roy Smith wrote: > > Of course, C++ lets you go off the deep end with abominations > > like references to pointers. Come to think of it, C++ let's > > you go off the deep end in so many ways... > > But you can do some really cool stuff in the deep end. "Hey, let's override operator,() and have some fun" -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Wed, 04 May 2011 09:18:56 -0700, Devin Jeanpierre wrote: > On May 4, 9:44 am, Hans Georg Schaathun wrote: >> : The only twist is that you never get to dereference : >> pointers in Python, but you can in C. Not much of a twist if you ask : >> me, but then again, I've been thinking in thismodelfor years. Maybe : >> I'm brainwashed. :) >> >> You are. You explain Python in terms of C. That's useful when you >> talk to other speakers of C. >> >> If you want to explain the language to a broader audience, you should >> use terminology from the language's own level of abstraction. > > No, I explained Python in terms of pointers/reference. Python has no pointers or references unless you simulate them yourself using other data types. They exist as implementation details of the Python virtual machine, which is at least two levels below that of Python code. The first is the byte code which runs in the virtual machine; the second is the code in the VM. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Thu, 05 May 2011 14:14:22 +, Grant Edwards wrote: > On 2011-05-05, harrismh777 wrote: >> Grant Edwards wrote: >>> The "pass by value" and "pass by reference" parameter passing >>> mechanisms are pretty well defined, and C uses "pass by value". >> >> Yeah, that's kind-a funny, cause I'm one of the guys (old farts) that >> helped define them > > I give up. You don't seem to understand the C language defintion or > what is commonly meant by "pass by reference". In fairness, he's not the only one. M Harris has twice now linked to an IBM site that describes pass-by-reference in C in terms of passing a pointer to the argument you want as the argument. Admittedly, doing so gives you almost the same behaviour, except that you have to dereference the pointers yourself. That's a pretty big difference though, and gets to the core of the argument: it's a bit like arguing that manual cars are fitted with exactly the same automatic transmission as auto cars, it's just that you have to engage the clutch and shift gears yourself. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 2011-05-05, Roy Smith wrote: > Of course, C++ lets you go off the deep end with abominations > like references to pointers. Come to think of it, C++ let's > you go off the deep end in so many ways... But you can do some really cool stuff in the deep end. -- Neil Cerutti -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Wed, 04 May 2011 16:22:42 -0600, Ian Kelly wrote: > However, I hope we can all agree that pass-by-pointer shares certain > features with both pass-by-value and pass-by-reference, and there are > perfectly reasonable arguments for lumping it in either category, yes? *cries* Please don't invent another "pass by foo" term Seriously though, "pass by foo" refers to what the compiler or interpreter does when you, the coder, call a function with some variable, say, x: f(x) It is not referring to what you, the coder, does when you want to pass an indirect reference of some sort to a chunk of data to some function. In many languages, you would use a pointer, and write the function call something like this: f(^x) (using Pascal's up-arrow notation for "pointer to"). Such "pass by pointer" is a tactic used by the coder, as opposed to a language feature. I believe this distinction between what the compiler does, and what the coder does, is at the heart of much confusion. Pointers that are passed as arguments are themselves data, just as much as ints or floats, or (in languages that have first-class functions) functions. -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On Wed, 04 May 2011 14:58:38 -0500, harrismh777 wrote: > Benjamin Kaplan wrote: >> CPython is implemented in C because that's the language chosen. Python >> is also implemented in Java, C#, Python, and several other languages. > > True enough. If I used Jython, I would want to take a look at those > sources... as well as the Java sources... which were wrtten in, um, C. No, Java sources are written in Java. That's why they're *Java* sources. Perhaps you mean that the Java compiler is written in C? Highly unlikely: Java compilers have been self-hosting for many years now. http://en.wikipedia.org/wiki/Self-hosting -- Steven -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
In article <4dc29cdd$0$29991$c3e8da3$54964...@news.astraweb.com>, Steven D'Aprano wrote: > C is better described as a high-level assembler, or a low-level language. > It is too close to the hardware to describe it as high-level, it has no > memory management, few data abstractions, and little protection. +1 I (and most people who really know C and the specific hardware architecture they're working on) should be able to look at a C program and (modulo optimization) pretty much be able to write down the generated assembler by hand. In fact, I used to do exactly that. I was once working on M-6800 hardware (8/16-bit microprocessor). I used to write out procedures in C, then hand-compile it into assembler code (and leave the C code as a comment). I wasn't a true masochist, however. I did let an assembler convert it to hex for me before I keyed it in :-) On the other hand, trying to do that for something like C++ is damn near impossible. There's too much stuff that happens by magic. Creation (and destruction) of temporary objects. Exception handling. RTTI. Not to mention truly black magic like template expansion. -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
Steven D'Aprano wrote: You should read Paul Graham on the Blub Paradox: http://www.paulgraham.com/avg.html Excellent-! ... thanks, fun article. ... where is that lisp manual anyway? ... oh, yeah, emacs! :) -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 2011-05-05, Steven D'Aprano wrote: > On Wed, 04 May 2011 14:22:38 -0500, harrismh777 wrote: > >> Here is the thing that everyone forgets... all we have to work with >> is a von Neumann processor. (same as EDVAC, ENIAC, the VIC20, etc). > > Actually, this is incorrect. Most processors these days are hybrids > between that and either the Harvard or Modified Harvard architecture: > > http://en.wikipedia.org/wiki/Modified_Harvard_architecture > http://en.wikipedia.org/wiki/Harvard_architecture > http://en.wikipedia.org/wiki/Von_Neumann_architecture And a lot of the are still full-up Harvard architecture (e.g. the entire Atmel AVR family and Intel 8051 family for example). -- Grant Edwards grant.b.edwardsYow! When this load is at DONE I think I'll wash it gmail.comAGAIN ... -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
In article ,
Grant Edwards wrote:
> That's what I was trying to say, but probably not as clearly. The "&"
> operatore returnas a _value_ that the OP passes _by_value_ to a
> function. That function then uses the "*" operator to use that value
> to access some data.
Then, of course, there's references in C++. I think it's fair to call
the following "call by reference" in the sense we're talking about it
here.
void f(int& i) {
i = 5;
}
int i = 42;
f(i);
Of course, C++ lets you go off the deep end with abominations like
references to pointers. Come to think of it, C++ let's you go off the
deep end in so many ways...
--
http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 2011-05-05, Gregory Ewing wrote: > harrismh777 wrote: >> 'C' is still the best high-level language on that processor. > > Some would argue that C is actually better than assembler these > days, because modern architectures are so freaking complicated > that it takes a computer to figure out the best instruction > sequence. :-( Been there, done that. Many years ago, it took me more than a week (and required the help of an ARM instruction set guru) to come up with an assembly language IP checksum routine for the ARM that out-performed the somewhat naive NetBSD "C" version. When we switched to the FreeBSD stack (and a newer compiler) a few years later, my assembly code got tossed out because was no longer any faster than the C version. -- Grant Edwards grant.b.edwardsYow! Half a mind is a at terrible thing to waste! gmail.com -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 2011-05-05, harrismh777 wrote: > Dennis Lee Bieber wrote: >>> > We do not consider passing a pointer as*by value* because its an >>> > address; by definition, that is pass-by-reference. We are not passing >> To most of the world, pass-by-reference means the COMPILER, not the >> PROGRAMMER is obtaining and passing the address, and the compiler also >> always dereferences the passed "value"... The programmer has no control >> over whether to operate on the address or the data referenced by the >> address. > > Who is "most of the world" ? Pretty much everybody except you. Please see: > http://publib.boulder.ibm.com/infocenter/comphelp/v8v101/index.jsp?topic=%2Fcom.ibm.xlcpp8a.doc%2Flanguage%2Fref%2Fcplr233.htm Yea, I read that. It doesn't support your argument. It agrees with the rest of the world. -- Grant Edwards grant.b.edwardsYow! I need to discuss at BUY-BACK PROVISIONS gmail.comwith at least six studio SLEAZEBALLS!! -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 2011-05-05, Gregory Ewing wrote: > Hans Georg Schaathun wrote: >> Is transmission by name the same as call by object? > > No, it's not. With call-by-name, the caller passes a > small function (known as a "thunk") that calculates the > address of the parameter. Every time the callee needs to > refer to the parameter, it evaluates this function. > > This allows some neat tricks, but it's massive overkill for most > uses. It also is a very good source of surprising bugs. -- Grant Edwards grant.b.edwardsYow! I feel like I'm at in a Toilet Bowl with a gmail.comthumbtack in my forehead!! -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 2011-05-05, harrismh777 wrote: > Tim Roberts wrote: >> The fact that the parameter "a" >> in BumpMe happens to be an address is completely irrelevent to the >> definition of the parameter passing mechanism. >> >> C has pass-by-value, exclusively. End of story. > > Yeah, Tim, I know... but that's my entire point in a nut-shell... > whether the language is pass-by-value or pass-by-reference has less to > do with how it is 'defined' (its mechanism--- indirection and stack) No, whether the _language_ is pass by value or pass-by-reference has _entirely_ to do with it's definition. > and more to do with how it is routinely used with the standard > features it provides--- in this case memory indirection--- as > pointers. Now you're talking about how you can implement higher level constructs using a language that doesn't directly implement such constructs. You might as well say that C is a linked-list language like Lisp since you can write a linked list implementation in C. If you said that you'd be just as wrong as saying that C uses call-by-reference. -- Grant Edwards grant.b.edwardsYow! I want another at RE-WRITE on my CEASAR gmail.comSALAD!! -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 2011-05-05, Gregory Ewing wrote: > harrismh777 wrote: >> 'C' does provide for pointers which are used by all 'C' >> programmers to firmly provide pass-by-reference in their coding > > Yes, but when they do that, they're building an abstraction > of their own on top of the facilities provided by the C > language. I've pointed that out to him. He's talking about what _he_ does in his program. We're talking about the C language definition and what the compiler does. > C itself has no notion of pass-by-reference. Exactly. C is pass by value. > If it did, the programmer would be able to use it directly > instead of having to insert & and * operators himself. That's what I was trying to say, but probably not as clearly. The "&" operatore returnas a _value_ that the OP passes _by_value_ to a function. That function then uses the "*" operator to use that value to access some data. -- Grant Edwards grant.b.edwardsYow! DIDI ... is that a at MARTIAN name, or, are we gmail.comin ISRAEL? -- http://mail.python.org/mailman/listinfo/python-list
Re: What other languages use the same data model as Python?
On 2011-05-05, harrismh777 wrote: > Grant Edwards wrote: >> The "pass by value" and "pass by reference" parameter passing >> mechanisms are pretty well defined, and C uses "pass by value". > > Yeah, that's kind-a funny, cause I'm one of the guys (old farts) that > helped define them I give up. You don't seem to understand the C language defintion or what is commonly meant by "pass by reference". -- Grant Edwards grant.b.edwardsYow! Inside, I'm already at SOBBING! gmail.com -- http://mail.python.org/mailman/listinfo/python-list
