On 02/07/2013 07:14 PM, Rick Johnson wrote:
> So if you want to use "global variables" , (bka: Module level
> variables), then simply declare them with a None value like this:
>
> globalVariable = None
This is a nice convention, but at best it's just a helpful notation that
helps a programmer kn
On 02/07/2013 07:14 PM, Rick Johnson wrote:
> On Wednesday, February 6, 2013 7:36:28 PM UTC-6, Ethan Furman wrote:
>> As Michael Torrie pointed out, the 'global' keyword is needed:
>
> Wrong. The global keyword is in fact NOT needed and something i
> consider to be another wart of the language (Py
On Wednesday, February 6, 2013 7:36:28 PM UTC-6, Ethan Furman wrote:
> As Michael Torrie pointed out, the 'global' keyword is needed:
Wrong. The global keyword is in fact NOT needed and something i consider to be
another wart of the language (PyWart on this subject coming soon!).
Now, whilst Mi
On 02/06/2013 04:57 PM, Ethan Furman wrote:
On 02/06/2013 04:43 PM, c wrote:
But the function in the module is also within a *class* so I don't
think the function does have access to the module's global namespace.
Here's the hierarchy:
-- Module namespace
class namespace (Database
On 02/06/2013 04:43 PM, c wrote:
But the function in the module is also within a *class* so I don't
think the function does have access to the module's global namespace.
Here's the hierarchy:
-- Module namespace
class namespace (DatabaseAccess is the name of the class)
--
On 02/06/2013 05:45 PM, CM wrote:
> But the function in the module is also within a *class* so I don't
> think the function does have access to the module's global namespace.
> Here's the hierarchy:
>
> -- Module namespace
> class namespace (DatabaseAccess is the name of the class)
>
I was using self correctly, I think; but I should have said that the
code in the importing module would be within a class, so self there
refers to that class. But that's a side point.
I agree that utilities.shared_cursor is visible within the importing
module. But the problem below remains for m
On Feb 6, 7:03 pm, Michael Torrie wrote:
> On 02/06/2013 03:41 PM, CM wrote:
>
> > Thank you. But, I'm sorry, I'm not following this enough to get it to
> > work. Shouldn't it be a little more like this:
>
> No, not exactly.
>
>
>
> > # in utilities module
> > shared_cursor = DatabaseAccess_ins
On 02/06/2013 05:03 PM, Michael Torrie wrote:
> Every function in a module has access to the module's global namespace.
> And your shared_cursor is there, inside of the utilities reference,
> since utilities was imported into your module, "importer."
Just to be clear:
mod1.py:
a=5
-
On 02/06/2013 03:41 PM, CM wrote:
> Thank you. But, I'm sorry, I'm not following this enough to get it to
> work. Shouldn't it be a little more like this:
No, not exactly.
>
> # in utilities module
> shared_cursor = DatabaseAccess_instance #but how? see my question
> below...
How what?
> #
On Feb 6, 12:04 am, Terry Reedy wrote:
> On 2/5/2013 11:40 PM, CM wrote:
>
>
>
>
>
>
>
>
>
> > I have recently moved all my SQLite3 database-related functions into a
> > class, DatabaseAccess, that lives in a "utilities" module. When the
> > application loads, the namespace of the instance of the
On 2/5/2013 11:40 PM, CM wrote:
I have recently moved all my SQLite3 database-related functions into a
class, DatabaseAccess, that lives in a "utilities" module. When the
application loads, the namespace of the instance of the class is
populated with two different cursors for two different datab
I have recently moved all my SQLite3 database-related functions into a
class, DatabaseAccess, that lives in a "utilities" module. When the
application loads, the namespace of the instance of the class is
populated with two different cursors for two different databases the
whole application needs t
13 matches
Mail list logo
