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
On 2006-07-24 16:51:56, danielx wrote:
> Gerhard's reply sounded not so confident.
Yes, it is not. It's just the conclusion I drew from my experiments. (I'm
still all wet behind the ears WRT Python...)
As long as there was no write access to the variable, the inner function
could read the value
danielx wrote:
> Gerhard Fiedler wrote:
[...]
>>Yes, but it is the line "tok = ''" that seems to cause tok to be now a
>>variable of the inner function's scope (rather than the variable tok of
>>breakLine).
>
>
> OHH! Yes, that sounds like it could be it. Wow, to me, that behavior is
> eXtremely
Gerhard Fiedler wrote:
> On 2006-07-23 14:53:33, danielx wrote:
>
> > I can't figure out why Josiah's breakLine function won't work either. I
> > know Josiah has had his problem resolved, but I'd still like to know
> > why his func won't work. I'd like to redirect this discussion in that
> > direct
danielx wrote:
> Bruno Desthuilliers wrote:
>
>>Josiah Manson a écrit :
>>
>>>I found that I was repeating the same couple of lines over and over in
>>>a function and decided to split those lines into a nested function
>>>after copying one too many minor changes all over. The only problem is
>>>th
Bruno Desthuilliers wrote:
(snip)
> First point: the nested function only have access to names that exists
> in the enclosing namespace at the time it's defined.
Duh.
Sometimes I'd better go to bed instead of answering posts here - I'd say
less stupidities. re-reading this, I can't believe I actu
On 2006-07-23 14:53:33, danielx wrote:
> I can't figure out why Josiah's breakLine function won't work either. I
> know Josiah has had his problem resolved, but I'd still like to know
> why his func won't work. I'd like to redirect this discussion in that
> direction, if I may.
I think what happe
Bruno Desthuilliers wrote:
> Josiah Manson a écrit :
> > I found that I was repeating the same couple of lines over and over in
> > a function and decided to split those lines into a nested function
> > after copying one too many minor changes all over. The only problem is
> > that my little helper
Bruno Desthuilliers wrote:
> Justin Azoff a écrit :
> > if len(tok) > 0:
> > should be written as
> > if(tok):
> >
>
> actually, the parenthesis are useless.
yes, that's what happens when you edit something instead of typing it
over from scratch :-)
--
- Justin
--
http://mail.python.or
Lawrence D'Oliveiro a écrit :
> In message <[EMAIL PROTECTED]>, Justin
> Azoff wrote:
>
>
>>Simon Forman wrote:
>>
>>>That third option seems to work fine.
>>
>>Well it does, but there are still many things wrong with it
>>
>>if len(tok) > 0:
>>should be written as
>>if(tok):
>
>
> I p
Justin Azoff a écrit :
> Simon Forman wrote:
>
>>That third option seems to work fine.
>
>
> Well it does, but there are still many things wrong with it
>
> if len(tok) > 0:
> should be written as
> if(tok):
>
actually, the parenthesis are useless.
--
http://mail.python.org/mailman/l
Justin Azoff a écrit :
> Simon Forman wrote:
>
>>That third option seems to work fine.
>
>
> Well it does, but there are still many things wrong with it
>
(snip)
> tok = ''
> tok = toc + c
> should be written as
> tok = []
> tok.append(c)
> and later
> ''.join(toc)
IIRC, s
Josiah Manson a écrit :
> I found that I was repeating the same couple of lines over and over in
> a function and decided to split those lines into a nested function
> after copying one too many minor changes all over. The only problem is
> that my little helper function doesn't work! It claims tha
Josiah Manson wrote:
> I just did some timings, and found that using a list instead of a
> string for tok is significantly slower (it takes 1.5x longer). Using a
> regex is slightly faster for long strings, and slightly slower for
> short ones. So, regex wins in both berevity and speed!
I think th
I just did some timings, and found that using a list instead of a
string for tok is significantly slower (it takes 1.5x longer). Using a
regex is slightly faster for long strings, and slightly slower for
short ones. So, regex wins in both berevity and speed!
--
http://mail.python.org/mailman/list
Thank you for your corrections to the previous code. Your regex
solution is definitely much cleaner. Referring to your other
suggestions, is the advantage of using a list of chars instead of
adding to a string just a bow to big-O complexity, or are there other
considerations? First I had tried appe
In message <[EMAIL PROTECTED]>, Justin
Azoff wrote:
> Simon Forman wrote:
>> That third option seems to work fine.
>
> Well it does, but there are still many things wrong with it
>
> if len(tok) > 0:
> should be written as
> if(tok):
I prefer the first way. Besides, your way is sub-opt
Simon Forman wrote:
> That third option seems to work fine.
Well it does, but there are still many things wrong with it
if len(tok) > 0:
should be written as
if(tok):
tok = ''
tok = toc + c
should be written as
tok = []
tok.append(c)
and later
''.join(toc)
anyway, th
Gerhard Fiedler wrote:
> On 2006-07-21 21:05:22, Josiah Manson wrote:
>
> > I found that I was repeating the same couple of lines over and over in
> > a function and decided to split those lines into a nested function
> > after copying one too many minor changes all over. The only problem is
> > th
1 - 100 of 101 matches
Mail list logo
