Hi Chris,
James has already given a response but I can't resist also chiming in,
see below:
On 11 July 2012 15:30, Chris Hare wrote:
> I like where this is going Walter. I guess where I am confused is this:
>
> the globals are not static - they are set once and then won't change during
> the l
On Wed, Jul 11, 2012 at 10:30 AM, Chris Hare wrote:
>
> On Jul 11, 2012, at 8:05 AM, Walter Prins wrote:
>
> > [snip]
>
> > Your original example modified as demonstration:
> >
> > a.py:
> >
> > import shared
> > import b
> >
> > def func1():
> >print "global var in func1 = %s" % sha
On Jul 11, 2012, at 8:05 AM, Walter Prins wrote:
> [snip]
> Your original example modified as demonstration:
>
> a.py:
>
> import shared
> import b
>
> def func1():
>print "global var in func1 = %s" % shared.global_var
>
> class intclass:
>def func2(self):
>
Hi,
On 11 July 2012 01:31, Chris Hare wrote:
> Thanks Alan -- I am thinking I am just gonna go with the RAM based SQLite
> database ….
That seems an awfully large hammer for a little global variable
problem. Why can you not (as a start) just move the global(s) into
their own namespace/location
On Jul 11, 2012, at 4:48 AM, tutor-requ...@python.org wrote:
> Message: 1
> Date: Tue, 10 Jul 2012 19:31:09 -0500
> From: Chris Hare
> To: tutor@python.org
> Subject: Re: [Tutor] advice on global variables
> Message-ID: <38ebadce-c2b1-4f15-b6e1-cb725f800...@labr.net>
&g
On Jul 10, 2012, at 6:24 PM, Alan Gauld wrote:
> On 11/07/12 00:16, Alan Gauld wrote:
>
>>> One thought was a RAM based SQLite database, but that seems
>> > like a lot of work. I dunno, maybe that is the option.
>>
>> is definitely the best option where the "global" needs to be shared
>> acros
On 11/07/12 00:16, Alan Gauld wrote:
One thought was a RAM based SQLite database, but that seems
> like a lot of work. I dunno, maybe that is the option.
is definitely the best option where the "global" needs to be shared
across different programs as well as different modules in a single
I
On 10/07/12 20:11, Chris Hare wrote:
I know they are bad.
They are not totally bad and most real programs wind up
having one or two globals, although usually those globals
are top level container classes, perhaps even an Application
class or similar.
I am not sure how else to handle this pro
Sent from my iPad
On Jul 10, 2012, at 3:11 PM, Chris Hare wrote:
>
> I know they are bad. That is why I would prefer not to use it, but I am not
> sure how else to handle this problem.
>
> In this app, the user must log in. Once authenticated, they have a userid
> stored in the SQLite da
> > Just as a note, this would not really work if the variable needs to be
> > changed and read from several places when the value is an immutable
> > type such as numbers / strings. In that case, then you could use
> > the same logic but instead place the value in a list and pass that
> > and alwa
On Tue, Jul 10, 2012 at 1:32 PM, Prasad, Ramit
wrote:
>> You should avoid using the global statement.
>>
>> In your case, I would think you could just add an argument to the method:
>>
>> class MyObj(object):
>> def __init__(self, arg):
>> self.arg = arg
>> def my_func(self, new_ar
On Tue, Jul 10, 2012 at 4:32 PM, Prasad, Ramit wrote:
> > You should avoid using the global statement.
> >
> > In your case, I would think you could just add an argument to the method:
> >
> > class MyObj(object):
> > def __init__(self, arg):
> > self.arg = arg
> > def my_func(self
> You should avoid using the global statement.
>
> In your case, I would think you could just add an argument to the method:
>
> class MyObj(object):
> def __init__(self, arg):
> self.arg = arg
> def my_func(self, new_arg):
> self.arg = new_arg
>
> to call it:
>
> arg =
> >
> > file: a.py
> >
> > import b
> > global_var = "global"
> >
> To answer your most basic question:
[file b.py]
> import a
> a.global_var
This would be a cyclical import and is bad even if it does not fail.
Remove the common dependencies (in this case the global variables)
and place it in a
On Tue, Jul 10, 2012 at 3:11 PM, Chris Hare wrote:
>
> I know they are bad. That is why I would prefer not to use it, but I am
> not sure how else to handle this problem.
>
> In this app, the user must log in. Once authenticated, they have a userid
> stored in the SQLite database. Before split
On Tue, Jul 10, 2012 at 12:11 PM, Chris Hare wrote:
>
> I know they are bad. That is why I would prefer not to use it, but I am not
> sure how else to handle this problem.
>
> In this app, the user must log in. Once authenticated, they have a userid
> stored in the SQLite database. Before spl
I know they are bad. That is why I would prefer not to use it, but I am not
sure how else to handle this problem.
In this app, the user must log in. Once authenticated, they have a userid
stored in the SQLite database. Before splitting my app into multiple files, I
used a global variable.
17 matches
Mail list logo
