On 3/30/2012 2:41 PM Barry Drake said...
On 30/03/12 19:18, Cranky Frankie wrote:
Here's what you need - he starts simple and winds up with some nice
games:
http://www.amazon.com/Python-Programming-Absolute-Beginner-Edition/dp/1435455002/ref=sr_1_6?ie=UTF8&qid=1333131438&sr=8-6
If you have
On 30/03/12 19:18, Cranky Frankie wrote:
Here's what you need - he starts simple and winds up with some nice games:
http://www.amazon.com/Python-Programming-Absolute-Beginner-Edition/dp/1435455002/ref=sr_1_6?ie=UTF8&qid=1333131438&sr=8-6
Wow! I found an e-book copy online and got it. Looks go
Barry,
On Fri, 2012-03-30 at 18:27 +0100, Barry Drake wrote:
> On 30/03/12 17:58, Mark Lawrence wrote:
> > The recipe here
> > http://code.activestate.com/recipes/410692-readable-switch-construction-without-lambdas-or-di/
> >
> >
> > refers to several other recipes which you might want to take a
On 3/30/2012 10:56 AM Prasad, Ramit said...
Lists are mutable objects. When you pass a list to a function you bind
a name in the functions namespace to the list object. Every name
binding to that object will have the ability to modify the list.
If you want to modify the list but not change it f
[snip]
>I'm used to c
> variables going out of scope once you leave the called function. I
> imagine if you want to leave the variables unchanged, you have to
> re-assign them inside the function.
[snip]
Lists are mutable objects. When you pass a list to a function you bind
a name in the functi
On 30/03/12 17:22, Prasad, Ramit wrote:
Unlike C, the parenthesis in if statements and returns are not
necessary. Furthermore, the way Python binds names means that
modifying the list in getflags modifies it in the callee. No need to
return and reassign results.
This is lovely. It's so much
On 30/03/12 17:58, Mark Lawrence wrote:
The recipe here
http://code.activestate.com/recipes/410692-readable-switch-construction-without-lambdas-or-di/
refers to several other recipes which you might want to take a look
at, sorry I meant to mention this earlier.
Oh, that's neat. Not worth
On 30/03/2012 15:04, Barry Drake wrote:
One of the few c things I miss is the switch/case statement. if and elif
in it's place is a bit cumbersome. Still, it works.
The recipe here
http://code.activestate.com/recipes/410692-readable-switch-construction-without-lambdas-or-di/
refers to severa
> [...]
> > C switch is just a different way of doing an if/elif tree, I do not
> > really see any real difference. Although, if there is you can feel free
> > to enlighten me. :)
> [...]
>
> 'fraid not -- though it depends on which compiler and how many cases.
> For 3 or more cases compilers will
Ramit,
On Fri, 2012-03-30 at 16:22 +, Prasad, Ramit wrote:
[...]
> C switch is just a different way of doing an if/elif tree, I do not
> really see any real difference. Although, if there is you can feel free
> to enlighten me. :)
[...]
'fraid not -- though it depends on which compiler and
> Furthermore, the way Python binds names means that modifying the list
> in getflags modifies it in the callee. No need to return and reassign
> results.
I correct myself. It has nothing to do with name binding, but entirely
to do with Python's object model.
Ramit
Ramit Prasad | JPMorgan Chas
> > Hi there I've just joined this list and thought I'd introduce
myself.
Welcome!
> > correct = 0
> > match = 0
> > wrong = 0
> > results = [correct, match, wrong]
> >
> > results = getflag(flag_1, results)
> > results = getflag(flag_2, results)
> > results = get
Barry Drake wrote:
> On 30/03/12 16:19, Evert Rol wrote:
>> Not sure. In the sense that you can "optimise" (refactor) it in the same
>> way you could do with C. Eg: results = [0, 0, 0]
>> flags = [0, 1, 2, 3]
>> for flag in flags:
>> results = getflag(flag, results)
>>
>
> That's exactly wha
Barry,
On Fri, 2012-03-30 at 16:42 +0100, Barry Drake wrote:
[...]
> def getflag(thisflag, results):
> if (thisflag == 2):
> results[0] += 1
> elif (thisflag == 1):
> results[1] += 1
> elif (thisflag == 0):
> results[2] += 1
> return(results)
Two tho
On Fri, Mar 30, 2012 at 9:12 PM, Barry Drake wrote:
> On 30/03/12 16:19, Evert Rol wrote:
>>
>> Not sure. In the sense that you can "optimise" (refactor) it in the same
>> way you could do with C. Eg:
>> results = [0, 0, 0]
>> flags = [0, 1, 2, 3]
>> for flag in flags:
>> results = getflag(fla
On 30/03/12 16:19, Evert Rol wrote:
Not sure. In the sense that you can "optimise" (refactor) it in the same way
you could do with C. Eg:
results = [0, 0, 0]
flags = [0, 1, 2, 3]
for flag in flags:
results = getflag(flag, results)
That's exactly what I hoped for. I hadn't realised I can
On 30/03/2012 15:13, Barry Drake wrote:
On 30/03/12 15:04, Barry Drake wrote:
One of the things I wanted to do is to use a four integer array to get
four integers returned from a function. I ended up using what I think
is a list. (I'm not really sure of the datatypes yet). This is what I
Pleas
Hi and welcome Barry,
> One of the things I wanted to do is to use a four integer array to get four
> integers returned from a function. I ended up using what I think is a list.
> (I'm not really sure of the datatypes yet). This is what I did, and it
> works, but looks very inelegant to me:
On 30/03/12 15:04, Barry Drake wrote:
One of the things I wanted to do is to use a four integer array to get
four integers returned from a function. I ended up using what I think
is a list. (I'm not really sure of the datatypes yet). This is what I
did, and it works, but looks very inelegant
Thanks all.
I think my fundamental error was in thinking of *menu.tx*t as the file and *
inp* as containing it's contents in some way. Much more helpful to think of
*inp* as the file and then do things to it.
Thanks again
Neil
This email is confidential and intended for addressee only .
On Mon
On 6/20/10, Steven D'Aprano wrote:
> On Mon, 21 Jun 2010 09:02:55 am Alex Hall wrote:
>> On 6/20/10, Neil Thorman wrote:
> [...]
>> inp = file("menu.txt", "r")
>> >
>> > *What is inp? What does it now contain?*
>>
>> It is now a reference to the location of the txt file.
>
> [pedantic]
> No,
On Mon, 21 Jun 2010 09:02:55 am Alex Hall wrote:
> On 6/20/10, Neil Thorman wrote:
[...]
> inp = file("menu.txt", "r")
> >
> > *What is inp? What does it now contain?*
>
> It is now a reference to the location of the txt file.
[pedantic]
No, it's actually an abstract data structure that wrap
"Neil Thorman" wrote
This is from Alan Gauld's Learning to Program: Handling Files.
http://www.freenetpages.co.uk/hp/alan.gauld/
One other thing. That page is now quite old and out of date. You
should switch to the current web site:
http://www.alan-g.me.uk/
inp = file("menu.txt", "r")
"Neil Thorman" wrote
inp = file("menu.txt", "r")
*What is inp? What does it now contain?*
print inp.readlines()
['spam & eggs\n', 'spam & chips\n', 'spam & spam']
but if I do it again I get:
print inp.readlines()
[]
I'm baffled, why is inp now empty?
OK, I've been asked thios before
On 20 June 2010 19:38, Neil Thorman wrote:
> I'm picking this up as a hobby really, not having done any programming
> since Acorn I'm pretty much starting form scratch (and even back in the
> BASIC day I never really got to grips with files).
> This is from Alan Gauld's Learning to Program: Handl
On 6/20/10, Neil Thorman wrote:
> I'm picking this up as a hobby really, not having done any programming since
> Acorn I'm pretty much starting form scratch (and even back in the BASIC day
> I never really got to grips with files).
> This is from Alan Gauld's Learning to Program: Handling Files.
>
26 matches
Mail list logo
