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
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
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
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
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
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):
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(BaseCl
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
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
id.
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 -- &
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.
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 on
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
unrefere
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 P
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 compos
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
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 no
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
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
ha
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 sens
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 o
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
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 P
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
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 som
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
Gregory Ewing wrote:
+-+
+---+ | |
a | --+>| |
+---+ | |
+-+
^
+---+
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
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
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 an
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
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
--
-+
>
> 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
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
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.
:
: +-+
:
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 cann
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 t
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 quali
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
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 come
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 se
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"
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
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
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 pointer
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
n 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
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/py
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 _
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
au
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.pyt
uages, 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 sufficient
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/pytho
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
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
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
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 li
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
>wi
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 to
>>> 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 some
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 containin
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
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
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 au
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
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
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 interpre
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 feat
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/Pa
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
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 fo
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
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 acce
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 almos
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".
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
> 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!
>
>
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
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 d
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 reaso
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
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 lab
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 t
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:
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
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 thinki
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
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.pyth
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
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
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
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
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
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 re
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 th
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
>> PROGRAMM
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
> r
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
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 b
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 u
1 - 100 of 205 matches
Mail list logo
