On Wed, Sep 28, 2011 at 5:06 PM, The Geek wrote:
> I'm clearly not understanding something about scope in python... Any help
> is appreciated
> In the following script I'm attempting to create 2 Foo objects, for each Foo
> object I create 2 Bars and add them to Foo's bar array
> Something hokey i
I'm clearly not understanding something about scope in python... Any help
is appreciated
In the following script I'm attempting to create 2 Foo objects, for each Foo
object I create 2 Bars and add them to Foo's bar array
Something hokey is occurring with the "foo.bars.append(bar)" line such that
On 2005-05-15, M.E.Farmer wrote:
>> No. You claimed
>
> This will only create a tuple in memory
>
> That is not what I said please do not edit my words and call it a
> quote!
Again the whole sentence:
Message-ID: <[EMAIL PROTECTED]>
| This will only create a tuple in memory that has no name t
It looks like the docs could use some examples of the various
assignments it refers to.
I think something like Bengt posted would be a nice addition if it
included assignments with slices and dicts too.
Just a thought.
M.E.Farmer
--
http://mail.python.org/mailman/listinfo/python-list
Fredrik and Bengt:
Thank you for the time.
I will study the docs and play with the shell till this is firm.
M.E.Farmer
--
http://mail.python.org/mailman/listinfo/python-list
>No. You claimed
This will only create a tuple in memory
That is not what I said please do not edit my words and call it a
quote!
>But we just learned that this is not the case.
Yes it seems I was proven wrong and have learned much from the
discussion ;)
That is why I am here to learn from othe
Fredrik Lundh wrote:
> which is one of the things you really love when you link against
> underdocumented Fortran programs from C. ("is that parameter
> a scalar or an array? crash! oh, an array. how many values does
> it expect? crash! oh, a few more, I suppose").
+1 QOTW
STeVe
--
http://mail.
On Sun, 15 May 2005 08:00:47 +0200, "Fredrik Lundh" <[EMAIL PROTECTED]> wrote:
>M.E.Farmer wrote:
>
>> I said exactly what I meant, the parentheses around the values creates
>> a tuple that you have no reference to!
>
>repeating it doesn't make you right; no extra tuple is created, and the
>parens
On 2005-05-14, M.E.Farmer wrote:
> I explained what i meant in previous post there was nothing more than
> just a discussion
No. You claimed
This will only create a tuple in memory
But we just learned that this is not the case.
> I have no real problem here just more of a sore point in style
Bernd Nawothnig wrote:
> > You're thinking you're passing the arguments as reference
>
> That is the way Fortran handles them:
which is one of the things you really love when you link against
underdocumented Fortran programs from C. ("is that parameter
a scalar or an array? crash! oh, an array.
M.E.Farmer wrote:
> I said exactly what I meant, the parentheses around the values creates
> a tuple that you have no reference to!
repeating it doesn't make you right; no extra tuple is created, and the
parens are part of the syntax:
If the target is a target list enclosed in parentheses or
"M.E.Farmer" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> But if the parens are just fluff then get rid of them, it is clearer *
> at least to me * ;)
While I find unnecessary parens on the right of '=' tolerable, I agree as
to the style preference.
Terry J. Reedy
--
http:
Ok I give up you have convinced me. Of what I am not sure ;)
Anyway I have always viewed :
a,b,c= (1,2,3)
as unpacking a tuple
and :
(a,b,c) = (1,2,3)
as creation of a tuple
It was a false assumption, I have used Python for years and have never
written an unpacking as:
(a,b,c) = (1,2,3)
I have alwa
I explained what i meant in previous post there was nothing more than
just a discussion I have no real problem here just more of a sore point
in style for me. I feel that parens are quite overloaded and it can be
confusing to newbies.
But if the parens are just fluff then get rid of them, it is cle
M.E.Farmer wrote:
>>They're both an UNPACK_SEQUENCE byte-code.
>
> I have dissed it myself ;)
> My argument, if you can call it that, is that it is not clear that
> Python is going to do a tuple unpacking here or not !
Hmm... Well, I wouldn't say that. I think it's quite clear that
Python's do
>It actually is the same, and I don't think implicit or explicit is the
>difference you should be citing here.
Why not it is relevant and true that Python is doing an implicit
unpacking of the values in that unnamed tuple.
Quoting myself """It might be the "same" as
no parens but it isn't very clea
On 14 May 2005 13:25:55 -0700, "M.E.Farmer" <[EMAIL PROTECTED]> wrote:
>I said exactly what I meant, the parentheses around the values creates
>a tuple that you have no reference to! It also has a side effect of
I don't understand what you are saying, or meaning ;-)
BTW, the function call has noth
On 14 May 2005 10:44:30 -0700, "M.E.Farmer" <[EMAIL PROTECTED]> wrote:
[...]
>Be sure to study up on namespaces, it will ease your Python woes.
>Namespaces are the most fundamental part of Python that new users don't
>understand. Namespace mastery will take you far.
>Just remember there are only tw
Steven Bethard wrote:
>
> I don't know the implementation enough to know whether or not a tuple is
> actually created when "b" and "c" are bound to their values, but I'd be
> willing to bet that whatever happens to "(b, c)" is exactly the same as
> what happens to "b, c".
Some corroborating ev
M.E.Farmer wrote:
> I said exactly what I meant, the parentheses around the values creates
> a tuple that you have no reference to! It also has a side effect of
> binding the names inside the tuple to a value and placing them in the
> local namespace( implicit tuple unpacking ). It might be the "sa
I said exactly what I meant, the parantheses around the values creates
a tuple that you have no reference to! It also has a side effect of
binding the names inside the tuple to a value and placing them in the
local namespace. It might be the "same" but it isn't very clear. If you
want a tuple make
I said exactly what I meant, the parentheses around the values creates
a tuple that you have no reference to! It also has a side effect of
binding the names inside the tuple to a value and placing them in the
local namespace( implicit tuple unpacking ). It might be the "same" as
no parens but it is
On Sat, 14 May 2005 20:38:26 +0200, Bernd Nawothnig <[EMAIL PROTECTED]> wrote:
>
>> On 2005-05-14, M.E.Farmer wrote:
>
>> (x,y,dotp,sumx,maxv) = abc(x,y,dotp,sumx,maxv)
>> This will only create a tuple in memory that has no name to reference
>> it by!
>
>Maybe. But it does not seem to hurt. And I
David wrote:
> Thank you very much. Tulpes are really neat now that I've looked at
> them. So after just fixing it, I changed it up and I would like to
> show it off now.
>
> #! /usr/bin/python
> #This program takes two vectors and multiplies them
> #against a 10X10 array. It also then gives th
Yes, I gathered.
We all get our habits from somewhere :-)
Regards,
Philippe
Bernd Nawothnig wrote:
> On 2005-05-14, Philippe C. Martin wrote:
>
>> You're thinking you're passing the arguments as reference
>
> That is the way Fortran handles them:
>
> [...]
>
>>> Right now I'm taking a simp
> On 2005-05-14, M.E.Farmer wrote:
> (x,y,dotp,sumx,maxv) = abc(x,y,dotp,sumx,maxv)
> This will only create a tuple in memory that has no name to reference
> it by!
Maybe. But it does not seem to hurt. And I am not sure the tupel _is_
really created in that situation.
> How would you access the
Hmm don't know what happened. I guess the formatting got all chewed up.
--
http://mail.python.org/mailman/listinfo/python-list
Thank you very much. Tulpes are really neat now that I've looked at
them. So after just fixing it, I changed it up and I would like to
show it off now.
#! /usr/bin/python
#This program takes two vectors and multiplies them
#against a 10X10 array. It also then gives the dot product,
#sum, and ma
M.E.Farmer wrote:
> (x,y,dotp,sumx,maxv) = abc(x,y,dotp,sumx,maxv)
> This will only create a tuple in memory that has no name to reference
> it by!
Huh? This binds the names "x", "y", "dotp", "sumx" and "maxv" to the
values returned by abc:
py> def abc(*args):
... return args
...
py> (x,y,d
(x,y,dotp,sumx,maxv) = abc(x,y,dotp,sumx,maxv)
This will only create a tuple in memory that has no name to reference
it by!
How would you access the returned value?
If you want a tuple you need to assign all the return vales to a single
name.
mytup = abc(x,y,dotp,sumx,maxv)
M.E.Farmer
--
http://m
David wrote:
> Hi I'm trying to teach myself python and so far to good, but I'm
having
> a bit of trouble getting a function to work the way I think it should
> work. Right now I'm taking a simple program I wrote in Fortran and
> trying to do it in Python. I got it to work, but now I'm trying to
On 2005-05-14, Philippe C. Martin wrote:
> You're thinking you're passing the arguments as reference
That is the way Fortran handles them:
[...]
>> Right now I'm taking a simple program I wrote in Fortran
Bernd
--
Those who desire to give up freedom in order to gain security,
will not hav
Hi,
You're thinking you're passing the arguments as reference (look at mutable
vs non-mutable)
Your function returns the values in a tupple (x,y,...); you need to fetch
the values from that tupple
Regards,
Philippe
David wrote:
> Hi I'm trying to teach myself python and so far to good, bu
On 2005-05-14, David wrote:
> abc(x,y,dotp,sumx,maxv)
(x,y,dotp,sumx,maxv) = abc(x,y,dotp,sumx,maxv)
Bernd
--
Those who desire to give up freedom in order to gain security,
will not have, nor do they deserve, either one. [T. Jefferson]
--
http://mail.python.org/mailman/listinfo/python-list
Hi I'm trying to teach myself python and so far to good, but I'm having
a bit of trouble getting a function to work the way I think it should
work. Right now I'm taking a simple program I wrote in Fortran and
trying to do it in Python. I got it to work, but now I'm trying to
modularize it. My fo
35 matches
Mail list logo
