On 9/4/2012 4:28 PM, channel727...@gmail.com wrote:
The Python C API function PyEval_EvalCode let's you execute compiled
Python code. I want to execute a block of Python code as if it were
executing within the scope of a function, so that it has its own
dictionary of local variables which don't a
the the locals dictionary, which is also the globals
dictionary. Now, a function defined at module scope which needs to lookup x
won't find x within the function-scope locals, because Python doesn't copy
module-scope locals into function-scope locals. But this normally isn't a
pro
Peter Otten wrote:
LOAD_NAME is pretty dumb, it looks into the local namespace and if that
lookup fails falls back to the global namespace. Someone probably thought "I
can do better", and reused the static name lookup for nested functions for
names that occur only on the right-hand side of ass
, but my *guess* about the
> reasoning is that the second case contains an assignment to A inside of
> the class namespace, and assignments make a variable local to a scope, in
> this case, the function scope. Therefore, the A on the rhs is looked up in
> that scope as well. However, this is just
Stefan Behnel wrote:
> I couldn't find any documentation on this, but my *guess* about the
> reasoning is that the second case contains an assignment to A inside
> of the class namespace, and assignments make a variable local to a
> scope, in this case, the function scope. Th
eturn X
...
>>> foo(2).A
1
Works that way in Py2.7 and Py3.3.
I couldn't find any documentation on this, but my *guess* about the
reasoning is that the second case contains an assignment to A inside of the
class namespace, and assignments make a variable local to a scope, in this
>>> foo(2).A
1
Works that way in Py2.7 and Py3.3.
I couldn't find any documentation on this, but my *guess* about the
reasoning is that the second case contains an assignment to A inside of the
class namespace, and assignments make a variable local to a scope, in this
case,
Tim Roberts wrote:
Mike Kent wrote:
On Feb 2, 6:40 pm, Baris Demir wrote:
def simpleCut(d=dict()):
temp=d
for i in temp.keys():
if(temp[i] == ...) :
temp[i]=new_value
return temp
You have been bitten by the shared default paramet
Mike Kent wrote:
>
>On Feb 2, 6:40 pm, Baris Demir wrote:
>
>> def simpleCut(d=dict()):
>> temp=d
>> for i in temp.keys():
>> if (temp[i] == ...) :
>> temp[i]=new_value
>> return temp
>
>You have been bitten by the shared default parameter noobie trap
On Mon, 02 Feb 2009 16:37:07 -0800, Mike Kent wrote:
> On Feb 2, 6:40 pm, Baris Demir wrote:
>
>> def simpleCut(d=dict()):
>> temp=d
>> for i in temp.keys():
>> if (temp[i] == ...) :
>> temp[i]=new_value
>> return temp
>
> You have been bitten by th
On Feb 2, 6:40 pm, Baris Demir wrote:
> def simpleCut(d=dict()):
> temp=d
> for i in temp.keys():
> if (temp[i] == ...) :
> temp[i]=new_value
> return temp
You have been bitten by the shared default parameter noobie trap:
http://www.python.org/doc/fa
> If you want a copy when you have
> to do so explicitly with "temp=d.copy()".
Or that! I forgot about that method. :)
Curiously, in 160k lines of code, I haven't explicitly copied a dictionary
once. I find that odd.
--S
--
http://mail.python.org/mailman/listinfo/python-list
On Mon, Feb 2, 2009 at 3:40 PM, Baris Demir wrote:
> Hi everybody,
>
> I am quite new to python and using it for my thesis. Luckily I found out
> some kind of behavior surprising to me and so unwanted in my code. I could
> not find any explanation, so solution for the code.
> It is simply like t
Baris Demir wrote:
> Hi everybody,
>
> I am quite new to python and using it for my thesis. Luckily I found
> out some kind of behavior surprising to me and so unwanted in my code. I
> could not find any explanation, so solution for the code.
> It is simply like this:
>
> /*li = another_module.gl
Hi everybody,
I am quite new to python and using it for my thesis. Luckily I found
out some kind of behavior surprising to me and so unwanted in my code. I
could not find any explanation, so solution for the code.
It is simply like this:
/*li = another_module.global_variable
f=simpleCut(li)
En Sat, 31 Jan 2009 05:31:47 -0200, Brendan Miller
escribió:
If I:
import sys
sys = sys.version
This executes find but:
import sys
def f():
sys = sys.version
This gives an error indicating that the sys on the right hand side of =
is undefined. What gives?
Python doesn't have local
On Fri, Jan 30, 2009 at 11:31 PM, Brendan Miller wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> If I:
>
> import sys
>
> sys = sys.version
>
> This executes find but:
>
> import sys
>
> def f():
>sys = sys.version
>
> This gives an error indicating that the sys on the right hand
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
If I:
import sys
sys = sys.version
This executes find but:
import sys
def f():
sys = sys.version
This gives an error indicating that the sys on the right hand side of =
is undefined. What gives?
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
On 2006-08-11 07:48:33, Slawomir Nowaczyk wrote:
> But let me try again, please (just one more time, if this doesn't work
> either I am willing to admit I do not see a simple analogy between
> Python and C variables :-)
>
>Python C
> variable: a
On Wed, 09 Aug 2006 15:11:16 -0300
Gerhard Fiedler <[EMAIL PROTECTED]> wrote:
#> On 2006-08-09 07:54:21, Slawomir Nowaczyk wrote:
#>
#> > Nope. Equivalence table can look like this:
#> >
#> >Python C
#> > variable:a variable:
At Wednesday 9/8/2006 16:15, [EMAIL PROTECTED] wrote:
I agree with the previous comments that this approach is "bad form".
But if you absolutely *must* modify an enclosing function's variables
with an inner function, all you need to do is remember that a Python
function is an object too, so it c
I agree with the previous comments that this approach is "bad form".
But if you absolutely *must* modify an enclosing function's variables
with an inner function, all you need to do is remember that a Python
function is an object too, so it can be assigned attributes. ;-)
def outer():
outer.x
On 2006-08-09 07:54:22, Slawomir Nowaczyk wrote:
> But I do not believe there is any "identity of a variable"
> which corresponds to "id()". Still, you used such term -- repeatedly.
>
> I do not know what do you mean by it.
In C, the "identity" of anything is usually the memory location. Same
l
On 2006-08-09 07:54:22, Slawomir Nowaczyk wrote:
> It was never my goal to show that Python and C variables behave the
> same way or anything.
>
> So it seems like we misunderstood each others intents.
That seems to be the case :)
I never really meant to say that I think that Python does not ha
On 2006-08-09 07:54:21, Slawomir Nowaczyk wrote:
> Nope. Equivalence table can look like this:
>
>Python C
> variable:a variable: a
> textual representation: "a" address operator: &a
> id of object: id
On Sun, 06 Aug 2006 11:37:46 -0300
Gerhard Fiedler <[EMAIL PROTECTED]> wrote:
#> On 2006-08-06 06:41:27, Slawomir Nowaczyk wrote:
#>
#> > Since Python doesn't (supposedly) have variables, it couldn't have come
#> > from Python.
#>
#> The idea (of this part of the thread) was to find the analogy
On Fri, 04 Aug 2006 14:09:15 -0300
Gerhard Fiedler <[EMAIL PROTECTED]> wrote:
#> > #> > I disagree. At least in my understanding, which, up to now, was
#> > #> > perfectly enough to explain everything about how Python variables
#> > #> > behave:
#> > #> >
#> > #> > The address operator in C is wh
Gerhard Fiedler wrote:
> On 2006-08-05 09:30:59, Antoon Pardon wrote:
>
> >> But this means that C variables are not analog to Python variables,
> >> [...]
> >
> > Yes they are.
>
> Nobody so far has been able to create a simple table with analog operations
> Python vs C that operates on C /variabl
On 2006-08-05, Gerhard Fiedler <[EMAIL PROTECTED]> wrote:
> On 2006-08-05 09:30:59, Antoon Pardon wrote:
>
>>> But this means that C variables are not analog to Python variables,
>>> [...]
>>
>> Yes they are.
>
> Nobody so far has been able to create a simple table with analog operations
> Python
On 2006-08-06 06:41:27, Slawomir Nowaczyk wrote:
> Since Python doesn't (supposedly) have variables, it couldn't have come
> from Python.
The idea (of this part of the thread) was to find the analogy between C
variables and Python variables, at least that's what you said a few
messages ago.
>
Dennis Lee Bieber wrote:
> On Sat, 5 Aug 2006 07:24:51 -0300, Gerhard Fiedler <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>> I know. It's just that your explicit analogy made this better visible, so
>> I wanted to add that to it. But I guess this thing is getting into the
On Fri, 04 Aug 2006 13:42:59 -0300
Gerhard Fiedler <[EMAIL PROTECTED]> wrote:
#> On 2006-08-04 12:12:44, Antoon Pardon wrote:
#>
#> >>> You can hardly claim that what gets printed is the "id" of the variable
c.
#> >>> (Well, you can claim, but few C programmers would follow you.)
#> >>
#> >> Tha
On Sat, 05 Aug 2006 02:55:03 -0700
Bill Pursell <[EMAIL PROTECTED]> wrote:
#> Gerhard Fiedler wrote:
#> > There's no Python equivalent to "int*p=345; *p++;".
#>
#> Sure there is:
#>
#> os.kill(os.getpid(), signal.SIGSEGV)
LOL... that's a good one :)
--
Best wishes,
Slawomir Nowaczyk
On 2006-08-05 09:30:59, Antoon Pardon wrote:
>> But this means that C variables are not analog to Python variables,
>> [...]
>
> Yes they are.
Nobody so far has been able to create a simple table with analog operations
Python vs C that operates on C /variables/ (not dereferenced pointers) and
m
On 2006-08-04, Gerhard Fiedler <[EMAIL PROTECTED]> wrote:
> On 2006-08-04 15:21:52, Dennis Lee Bieber wrote:
>
>> On Fri, 4 Aug 2006 14:09:15 -0300, Gerhard Fiedler <[EMAIL PROTECTED]>
>> declaimed the following in comp.lang.python:
>>
>>> Python === C
>>> Textual representation a === Address oper
On 2006-08-05 02:02:03, Dennis Lee Bieber wrote:
> I've not disagreed with you, but wanted to correct the
> associations... It is others who may disagree...
I know. It's just that your explicit analogy made this better visible, so I
wanted to add that to it. But I guess this thing is gettin
Gerhard Fiedler wrote:
>There's no Python equivalent to "int*p=345; *p++;".
Sure there is:
os.kill(os.getpid(), signal.SIGSEGV)
:)
--
http://mail.python.org/mailman/listinfo/python-list
On 2006-08-04 15:21:52, Dennis Lee Bieber wrote:
> On Fri, 4 Aug 2006 14:09:15 -0300, Gerhard Fiedler <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>> Python === C
>> Textual representation a === Address operator (&a)
>> id(a) === Dereference operator (*a)
>>
>> I think I
On 2006-08-04, Gerhard Fiedler <[EMAIL PROTECTED]> wrote:
> On 2006-08-04 12:12:44, Antoon Pardon wrote:
>
>>> That's possible. I wouldn't expect too many C programmers to have any
>>> notion of "id of a variable". I, for example, never thought about such
>>> thing before this thread.
>>
>> But ev
On 2006-08-04 11:41:03, Slawomir Nowaczyk wrote:
> #> > I disagree. At least in my understanding, which, up to now, was
> #> > perfectly enough to explain everything about how Python variables
> #> > behave:
> #> >
> #> > The address operator in C is what textual representation (i.e. what
> #> >
On 2006-08-04 12:12:44, Antoon Pardon wrote:
>> That's possible. I wouldn't expect too many C programmers to have any
>> notion of "id of a variable". I, for example, never thought about such
>> thing before this thread.
>
> But even in Python we don't speak of "id of a variable". It is not the
>
On 2006-08-04, Slawomir Nowaczyk <[EMAIL PROTECTED]> wrote:
> On Fri, 04 Aug 2006 10:10:45 -0300
> Gerhard Fiedler <[EMAIL PROTECTED]> wrote:
>
> #> You can hardly claim that what gets printed is the "id" of the variable c.
> #> (Well, you can claim, but few C programmers would follow you.)
>
> Tha
On Fri, 04 Aug 2006 10:10:45 -0300
Gerhard Fiedler <[EMAIL PROTECTED]> wrote:
#> On 2006-08-04 07:36:25, Slawomir Nowaczyk wrote:
#>
#> > #> The address operator is probably for a C programmer the closest to
#> > #> what the id() function is to a Python programmer.
#> >
#> > I disagree. At least
On 2006-08-04 07:36:25, Slawomir Nowaczyk wrote:
> #> The address operator is probably for a C programmer the closest to
> #> what the id() function is to a Python programmer.
>
> I disagree. At least in my understanding, which, up to now, was
> perfectly enough to explain everything about how Py
On Thu, 03 Aug 2006 17:27:26 -0300
Gerhard Fiedler <[EMAIL PROTECTED]> wrote:
#> But seriously, for my comment this seems off-topic.
Well, you wrote "but it's not really understandable with a C++ concept
of variable". It is perfectly understandable to me. That's all I said
(or, at least, all I wa
Antoon Pardon a écrit :
> On 2006-07-31, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>
>>Antoon Pardon wrote:
>>(snip)
>>
>>>Sure it is usefull. It may be not 100% formally correct, but often
>>>things that are not 100% formally correct can be better in bringing
>>>an idea accross.
>>
>>hear he
On 2006-08-03 10:57:22, Slawomir Nowaczyk wrote:
> #> In any case, the following doesn't seem to be implementation detail
> #> (and rather a part of the language), but it's not really
> #> understandable with a C++ concept of "variable":
> #>
> #> >>> a=3
> #> >>> id(a)
> #> 3368152
> #> >>> b=a
On Sun, 30 Jul 2006 11:18:10 -0300
Gerhard Fiedler <[EMAIL PROTECTED]> wrote:
#> In any case, the following doesn't seem to be implementation detail
#> (and rather a part of the language), but it's not really
#> understandable with a C++ concept of "variable":
#>
#> >>> a=3
#> >>> id(a)
#> 336815
On 2006-08-02, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> On 2 Aug 2006 13:09:26 GMT, Antoon Pardon <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>>
>> And how is this all relevant in deciding that the source language for
>> the above interpreter actions isn't C? What th
On 2006-08-02, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> On 1 Aug 2006 17:44:54 GMT, Antoon Pardon <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>> Suppose I write a C-interpreter and then would translate a statement
>> like "c = c + 100" into actions the interpreter wou
On 2006-08-01, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> On Tue, 1 Aug 2006 11:12:31 -0300, Gerhard Fiedler <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>> There's maybe a point in comparing Python variables to C pointers. But it
>> lacks in the respect that a C program
Antoon Pardon wrote:
> Even this doesn't:
>
> def foo():
> if False:
> a = 1
> else:
> b = a
>
> a = 1
> foo()
>
> Yet seems to work (which I think is an error in the optimisation;
What definition of 'seems to work' are you using? It throws an
UnboundLocalError excep
On 2006-08-01, danielx <[EMAIL PROTECTED]> wrote:
> Gerhard Fiedler wrote:
>> On 2006-07-30 09:54:14, Antoon Pardon wrote:
>>
>> > Aren't you looking too much at implementation details now?
>>
>> Possibly, but at this point I'm still trying to understand how Python does
>> these things, and what th
On 2006-07-31 23:52:07, danielx wrote:
>> You don't expect the "identity" of the variable b to change with a
>> simple assignment from a C/C++ point of view. You also don't expect the
>> "identity" of a and b to be the same after assigning one to the other.
>> You can create C++ classes that behav
On 2006-07-31, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
> (snip)
>> Sure it is usefull. It may be not 100% formally correct, but often
>> things that are not 100% formally correct can be better in bringing
>> an idea accross.
>
> hear hear...
>
> And yet you still fail
Gerhard Fiedler wrote:
> On 2006-07-30 09:54:14, Antoon Pardon wrote:
>
> > Aren't you looking too much at implementation details now?
>
> Possibly, but at this point I'm still trying to understand how Python does
> these things, and what the useful abstraction level is for me. I also still
> have
Antoon Pardon wrote:
(snip)
> Sure it is usefull. It may be not 100% formally correct, but often
> things that are not 100% formally correct can be better in bringing
> an idea accross.
hear hear...
And yet you still fail to understand why I claimed Python didn't have
variables ? Talk about stubb
On 2006-07-30, Gerhard Fiedler <[EMAIL PROTECTED]> wrote:
> On 2006-07-30 12:45:50, Antoon Pardon wrote:
>
>>> [...] we'd have to use a common definition of "variable". This is a term
>>> so widely used that I'm not sure there is a useful single definition of
>>> it; do you know one?
>>
>> A name
Antoon Pardon wrote:
> On 2006-07-29, Gerhard Fiedler <[EMAIL PROTECTED]> wrote:
>> On 2006-07-29 13:47:37, Antoon Pardon wrote:
>>
>>> I think the important thing to remember is that the assignment in Python
>>> is a alias maker and not a copy maker. In languages like C, Fortran,
>>> pascal, the a
"Gerhard Fiedler" <[EMAIL PROTECTED]> wrote:
8<-
| I'm not sure where you're trying to go. I think that most people (and even
| Bruno, who argued this issue most strongly) call Python variables
| "variables" every now and then, or maybe even usually. But it was hel
On 2006-07-30 12:45:50, Antoon Pardon wrote:
>> [...] we'd have to use a common definition of "variable". This is a term
>> so widely used that I'm not sure there is a useful single definition of
>> it; do you know one?
>
> A name in a scope to which is attached some value/object. Now whether
> t
On 2006-07-30, Gerhard Fiedler <[EMAIL PROTECTED]> wrote:
> On 2006-07-30 09:54:14, Antoon Pardon wrote:
>
>> Aren't you looking too much at implementation details now?
>
> Possibly, but at this point I'm still trying to understand how Python does
> these things, and what the useful abstraction lev
On 2006-07-30 09:54:14, Antoon Pardon wrote:
> Aren't you looking too much at implementation details now?
Possibly, but at this point I'm still trying to understand how Python does
these things, and what the useful abstraction level is for me. I also still
have very little experience how I'll put
On 2006-07-29, Gerhard Fiedler <[EMAIL PROTECTED]> wrote:
> On 2006-07-29 13:47:37, Antoon Pardon wrote:
>
>> I think the important thing to remember is that the assignment in Python
>> is a alias maker and not a copy maker. In languages like C, Fortran,
>> pascal, the assignment makes a copy from
On 2006-07-29 13:47:37, Antoon Pardon wrote:
> I think the important thing to remember is that the assignment in Python
> is a alias maker and not a copy maker. In languages like C, Fortran,
> pascal, the assignment makes a copy from what is on the righthand and
> stores that in the variable on th
On 2006-07-29, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> On 28 Jul 2006 18:20:52 GMT, Antoon Pardon <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>
>> That is not true. It may be the case in a number of languages but
>> my experience with lisp and smalltalk, though rathe
On 2006-07-28, Gerhard Fiedler <[EMAIL PROTECTED]> wrote:
> On 2006-07-28 15:20:52, Antoon Pardon wrote:
>
>>> Typically, "variable" implies a data storage location that can take on
>>> different values. Emphasis on "location" -- the name is fixed to a
>>> memory location whose contents can be vari
On 2006-07-29, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> On 28 Jul 2006 17:48:03 GMT, Antoon Pardon <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>>
>> That is no reason to say that python has no variables. If someone would
>> explain the difference between objects in s
On 2006-07-28 14:32:59, Dennis Lee Bieber wrote:
> On Fri, 28 Jul 2006 11:41:30 -0300, Gerhard Fiedler <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>> wondered (this is slightly related) is whether it wouldn't be really good
>> to make the difference between mutable and im
On 2006-07-28 15:20:52, Antoon Pardon wrote:
>> Typically, "variable" implies a data storage location that can take on
>> different values. Emphasis on "location" -- the name is fixed to a
>> memory location whose contents can be varied.
>
> That is not true. It may be the case in a number of lan
On 2006-07-28, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> Hmmm, I've not followed the PEPs -- has any thought been given to
> unifying class/instance and dictionary notation so that
>
> a['b']
> and
> a.b
If that is what you want, you could use the following
On 2006-07-28, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> On 27 Jul 2006 18:09:37 GMT, Antoon Pardon <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>>
>> It is irrelevant because the word "variable" is used in a lot of
>> different languages. A lot of them with behaviour
On 2006-07-27, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> Antoon Pardon a écrit :
>> On 2006-07-27, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>>
>>>Antoon Pardon wrote:
>>>
On 2006-07-27, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>>>
>>>(snip)
>>>
>>>It can only take y
On 2006-07-28 04:07:20, Bruno Desthuilliers wrote:
> Gerhard Fiedler a écrit :
>> Isn't being on the LHS (of an assignment) the only way to (re)bind a
>> variable?
>
>
> s/variable/name/
>
Ok, I missed this one :)
>> Are there situations where binding happens without an explicit
>> assignment
Gerhard Fiedler a écrit :
> On 2006-07-27 17:10:55, Bruno Desthuilliers wrote:
>
>
>>>Isn't being on the LHS the only way to write to a non-mutable object?
>>
>>You *don't* "write to a non-mutable object". You rebind the name to
>>another object (mutable or not, that's not the problem).
>
>
>
On 2006-07-27 17:10:55, Bruno Desthuilliers wrote:
>> Isn't being on the LHS the only way to write to a non-mutable object?
>
> You *don't* "write to a non-mutable object". You rebind the name to
> another object (mutable or not, that's not the problem).
Ok, sloppy writing (sloppy thinking, or
Gerhard Fiedler a écrit :
> On 2006-07-27 14:15:34, Dennis Lee Bieber wrote:
>
>
>>>In a language like C the name doesn't hold anything either. The name is
>>>just a way for refering to a memory space which will hold something.
>>>
>>
>> Except for one difference... In C (and most other lan
Gerhard Fiedler a écrit :
> On 2006-07-25 13:33:40, Dennis Lee Bieber wrote:
>
>
>>>Surprising for me are actually two things: 1- the fact itself, and 2- that
>>>term "binding", and that whatever it means (I'll have to read more on that,
>>>now that I know the term) is different for read-only and
Gerhard Fiedler a écrit :
> On 2006-07-27 13:44:29, Bruno Desthuilliers wrote:
>
>
>>What bother me with the "hold" term is that I understand it as meaning
>>that the name is some kind of container by itself - which it is not.
>>Consider the following:
>>
>>d = dict()
>>d['name'] = 'parrot'
>>
>>
Antoon Pardon a écrit :
> On 2006-07-27, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>
>>Antoon Pardon wrote:
>>
>>>On 2006-07-27, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>>>
>>
>>(snip)
>>
>>It can only take you so far. Now it's time you know the truth: there are
>>*no* 'variabl
On 2006-07-27 14:15:34, Dennis Lee Bieber wrote:
>> In a language like C the name doesn't hold anything either. The name is
>> just a way for refering to a memory space which will hold something.
>>
> Except for one difference... In C (and most other languages) that
> memory space is FIXED
On 2006-07-27, Dennis Lee Bieber <[EMAIL PROTECTED]> wrote:
> On 27 Jul 2006 14:11:35 GMT, Antoon Pardon <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>> In a language like C the name doesn't hold anything either.
>> The name is just a way for refering to a memory space whic
On 2006-07-27, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> On 2006-07-27, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>>
> (snip)
>It can only take you so far. Now it's time you know the truth: there are
>*no* 'variables' in Python (hence the term 'binding')
On 2006-07-27 13:44:29, Bruno Desthuilliers wrote:
> What bother me with the "hold" term is that I understand it as meaning
> that the name is some kind of container by itself - which it is not.
> Consider the following:
>
> d = dict()
> d['name'] = 'parrot'
>
> Would you say that the string "na
Gerhard Fiedler wrote:
> On 2006-07-27 09:42:16, Bruno Desthuilliers wrote:
>
>
>>>Are you saying Python variables don't hold references to "actual" Python
>>>objects?
>>
>>Exactly.
>>
>>
>>>That idea has been working well for me so far.
>>
>>It can only take you so far. Now it's time you know t
Antoon Pardon wrote:
> On 2006-07-27, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>
(snip)
It can only take you so far. Now it's time you know the truth: there are
*no* 'variables' in Python (hence the term 'binding').
>>>
>>>
>>>That depends on what you want to mean with the term. IMO
On 2006-07-27, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> Antoon Pardon wrote:
>> On 2006-07-27, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>>
>>>danielx wrote:
>>>
Bruno Desthuilliers wrote:
>>>
>>>(snip)
>>>
>>Surprising for me are actually two things: 1- the fact itself,
Antoon Pardon wrote:
> On 2006-07-27, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
>
>>danielx wrote:
>>
>>>Bruno Desthuilliers wrote:
>>>
>>
>>(snip)
>>
>Surprising for me are actually two things: 1- the fact itself, and 2- that
>term "binding", and that whatever it means > (I'll have t
On 2006-07-27 09:42:16, Bruno Desthuilliers wrote:
>> Are you saying Python variables don't hold references to "actual" Python
>> objects?
>
> Exactly.
>
>> That idea has been working well for me so far.
>
> It can only take you so far. Now it's time you know the truth: there are
> *no* 'varia
On 2006-07-27, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> danielx wrote:
>> Bruno Desthuilliers wrote:
>>
> (snip)
>>>
Surprising for me are actually two things: 1- the fact itself, and 2- that
term "binding", and that whatever it means > (I'll have to read more on
that,
now
danielx wrote:
> Bruno Desthuilliers wrote:
>
(snip)
>>
>>>Surprising for me are actually two things: 1- the fact itself, and 2- that
>>>term "binding", and that whatever it means > (I'll have to read more on that,
>>>now that I know the term)
>>
>>a "binding" is the association of a name and a re
Gerhard Fiedler wrote:
> Going back to the original question... What would be the most
> common/useful way to access variables from the outer function for writing
> from within the inner function?
I've done something like this (which doesn't look very nice)
def myfunc():
tok = ['']
def i
On 2006-07-25, Bruno Desthuilliers <[EMAIL PROTECTED]> wrote:
> Gerhard Fiedler wrote:
>> On 2006-07-25 04:06:24, Steve Holden wrote:
>>
> Since Python has no "local variable declaration", there must be a rule
> to distinguish local names from names living in the enclosing
> namespaces. The rule i
Bruno Desthuilliers wrote:
> Gerhard Fiedler wrote:
> > On 2006-07-25 04:06:24, Steve Holden wrote:
> >
> >
> >>Dennis Lee Bieber wrote:
> >>
> >>>On Mon, 24 Jul 2006 17:35:50 -0300, Gerhard Fiedler <[EMAIL PROTECTED]>
> >>>declaimed the following in comp.lang.python:
> >>>
> >>>
> It is surpr
On 2006-07-25 13:33:40, Dennis Lee Bieber wrote:
>> Surprising for me are actually two things: 1- the fact itself, and 2- that
>> term "binding", and that whatever it means (I'll have to read more on that,
>> now that I know the term) is different for read-only and read/write access.
>>
> Binding
"Dennis Lee Bieber" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> The names in the parameter list of the "def" statement are bound to
> the objects associated with the actual call. After that, they behave
> very much as locals... Now -- with defaults it gets a touch trickier...
A
Gerhard Fiedler wrote:
> On 2006-07-25 04:06:24, Steve Holden wrote:
>
>
>>Dennis Lee Bieber wrote:
>>
>>>On Mon, 24 Jul 2006 17:35:50 -0300, Gerhard Fiedler <[EMAIL PROTECTED]>
>>>declaimed the following in comp.lang.python:
>>>
>>>
It is surprising in the sense that binding seems not to be
On 2006-07-25 04:06:24, Steve Holden wrote:
> Dennis Lee Bieber wrote:
>> On Mon, 24 Jul 2006 17:35:50 -0300, Gerhard Fiedler <[EMAIL PROTECTED]>
>> declaimed the following in comp.lang.python:
>>
>>> It is surprising in the sense that binding seems not to be necessary
>>> for read access.
>>
>
Dennis Lee Bieber wrote:
> On Mon, 24 Jul 2006 17:35:50 -0300, Gerhard Fiedler <[EMAIL PROTECTED]>
> declaimed the following in comp.lang.python:
>
>
>>It is surprising in the sense that binding seems not to be necessary for
>>read access.
>>
It does, I would agree, seem a little counter-intuiti
On 2006-07-24 17:09:24, Steve Holden wrote:
> Would I do?
It seems so :)
> If there's a binding to a name *anywhere* in the function's body then
> that name is treated as local to the function.
>
> This is a matter of static analysis, and is irrespective of where in the
> body the assignment
1 - 100 of 120 matches
Mail list logo
