Re: How should we use global variables correctly?

On Fri, Aug 23, 2019 at 4:00 AM Windson Yang wrote: > > Thank you all. I agreed with Frank that > > > It would make sense to use the 'global' keyword if you have a module > with various functions, several of which refer to 'foo', but only one of > which changes the value of 'foo'. > > I also found

Re: How should we use global variables correctly?

Thank you all. I agreed with Frank that > It would make sense to use the 'global' keyword if you have a module with various functions, several of which refer to 'foo', but only one of which changes the value of 'foo'. I also found an example in cpython/lib/gettext.py, only 'textdomain function' c

Re: How should we use global variables correctly?

On 23Aug2019 09:07, Frank Millman wrote: On 2019-08-23 8:43 AM, Windson Yang wrote: In class.py class Example: def __init__(self): self.foo = 1 def bar() return self.foo + 1 Expect the syntax, why using class variable self.foo would be better (or m

Re: How should we use global variables correctly?

On 23Aug2019 14:43, Windson Yang wrote: I also want to know what is the difference between "using 'global variables' in a py module" and "using a variable in class". For example: In global.py: foo = 1 def bar(): global foo return foo + 1

Re: How should we use global variables correctly?

On 2019-08-23 8:43 AM, Windson Yang wrote: I also want to know what is the difference between "using 'global variables' in a py module" and "using a variable in class". For example: In global.py: foo = 1 def bar(): global foo return foo

Re: How should we use global variables correctly?

I also want to know what is the difference between "using 'global variables' in a py module" and "using a variable in class". For example: In global.py: foo = 1 def bar(): global foo return foo + 1 In class.py class Exam

Re: How should we use global variables correctly?

On Fri, Aug 23, 2019 at 11:24 AM Windson Yang wrote: > > Thank you all for the great explanation, I still trying to find some good > example to use 'global', In CPython, I found an example use 'global' in > cpython/Lib/zipfile.py > > _crctable = None > def _gen_crc(crc): > for j in

Re: How should we use global variables correctly?

Thank you all for the great explanation, I still trying to find some good example to use 'global', In CPython, I found an example use 'global' in cpython/Lib/zipfile.py _crctable = None def _gen_crc(crc): for j in range(8): if crc & 1: crc = (crc >> 1) ^

Re: How should we use global variables correctly?

On 8/22/19 12:00 PM, Windson Yang wrote: > I can 'feel' that global variables are evil. I also read lots of articles > proves that (http://wiki.c2.com/?GlobalVariablesAreBad). However, I found > CPython Lib use quite a lot of `global` keyword. So how should we use > `glo

Re: How should we use global variables correctly?

On Fri, Aug 23, 2019 at 10:18 AM Cameron Simpson wrote: > As Michael says, "you can always read from a parent scope if the name > hasn't been used by the local scope". What this means is this: > > _MODULE_LEVEL_CACHE = {} > > def factors_of(n): > factors = _MODULE_LEVEL_CACHE.get(n

Re: How should we use global variables correctly?

On 22Aug2019 11:12, Michael Torrie wrote: On 8/22/19 10:00 AM, Windson Yang wrote: I can 'feel' that global variables are evil. I also read lots of articles proves that (http://wiki.c2.com/?GlobalVariablesAreBad). However, I found CPython Lib use quite a lot of `global` keyword. So

Re: How should we use global variables correctly?

On 8/22/19 10:00 AM, Windson Yang wrote: > I can 'feel' that global variables are evil. I also read lots of articles > proves that (http://wiki.c2.com/?GlobalVariablesAreBad). However, I found > CPython Lib use quite a lot of `global` keyword. So how should we use > `glo

How should we use global variables correctly?

I can 'feel' that global variables are evil. I also read lots of articles proves that (http://wiki.c2.com/?GlobalVariablesAreBad). However, I found CPython Lib use quite a lot of `global` keyword. So how should we use `global` keyword correctly? IIUC, it's fine that we use `global`

Re: PyMyth: Global variables are evil... WRONG!

On Sat, Nov 16, 2013 at 3:01 PM, Rick Johnson wrote: > Because when i see code that accesses a variable like this: > > var = value > > I have no way of knowing whether the mutation is happening > to a local variable, a module level variable, or even a true > global level variable (one which ex

Re: PyMyth: Global variables are evil... WRONG!

On Sat, Nov 16, 2013 at 3:01 PM, Rick Johnson wrote: > Let's see... Tkinter's design today is a single module > containing a staggering: > > 155,626 chars > > 3,733 lines Also: I see nothing wrong with a single module having 3-4K lines in it. Hilfe, the Pike REPL/interactive interpreter,

Re: PyMyth: Global variables are evil... WRONG!

n conventions for decoupling code: > subroutines, local variables, objects, modular code, and > so forth. Physical objects are inherently decoupled. Code > is inherently coupled, and we need conventions to decouple > it. One of those conventions is to prefer local variables > to global va

Re: PyMyth: Global variables are evil... WRONG!

On 11/15/2013 09:42 AM, Chris Angelico wrote: On Sat, Nov 16, 2013 at 2:26 AM, Tim Daneliuk wrote: On 11/15/2013 02:19 AM, Steven D'Aprano wrote: Nobody sets out to*design* a tangled mess. What normally happens is that a tangled mess is the result of*lack of design*. This has been an intere

Re: PyMyth: Global variables are evil... WRONG!

On 11/15/2013 02:19 AM, Steven D'Aprano wrote: Nobody sets out to*design* a tangled mess. What normally happens is that a tangled mess is the result of*lack of design*. This has been an interesting thread - to me anyway - but this bit above caught my eye. People write programs for lots of rea

Re: PyMyth: Global variables are evil... WRONG!

On Sat, Nov 16, 2013 at 2:26 AM, Tim Daneliuk wrote: > On 11/15/2013 02:19 AM, Steven D'Aprano wrote: >> Nobody sets out to*design* a tangled mess. What normally happens is that >> a tangled mess is the result of*lack of design*. > > This has been an interesting thread - to me anyway - but this b

Re: PyMyth: Global variables are evil... WRONG!

>> bug-free) code using process-wide global variables. > > Complete FUD. Maybe for you. Not for me. I wasn't taking about genius programmers like you Rick, that would be silly. I'm talking about mere mortals like the rest of us. >> Global variables are the spaghet

Re: PyMyth: Global variables are evil... WRONG!

On Fri, Nov 15, 2013 at 7:12 AM, Alister wrote: > Ricks non trolling posts do give him enough credibility to avoid > dismissing his ideas out of hand When he's talking about Tkinter, he knows his stuff, and is orders of magnitude more helpful than I would be (as I don't know Tkinter). When he's t

Re: PyMyth: Global variables are evil... WRONG!

On Thu, 14 Nov 2013 09:56:04 -0800, Ethan Furman wrote: > On 11/14/2013 09:37 AM, Joel Goldstick wrote: >> >> So, beyond that, what is the point of the thread? > > You haven't met Ranting Rick yet? He's a troll's troll, outdone only by > one other whose name I don't remember. > > His posts are,

Re: PyMyth: Global variables are evil... WRONG!

On 14/11/2013 17:56, Ethan Furman wrote: On 11/14/2013 09:37 AM, Joel Goldstick wrote: So, beyond that, what is the point of the thread? You haven't met Ranting Rick yet? He's a troll's troll, outdone only by one other whose name I don't remember. His posts are, amazingly enough, rants. Us

Re: PyMyth: Global variables are evil... WRONG!

On Thu, Nov 14, 2013 at 12:56 PM, Ethan Furman wrote: > On 11/14/2013 09:37 AM, Joel Goldstick wrote: >> >> >> So, beyond that, what is the point of the thread? > > > You haven't met Ranting Rick yet? He's a troll's troll, outdone only by one > other whose name I don't remember. > > His posts are

Re: PyMyth: Global variables are evil... WRONG!

On 11/14/2013 09:37 AM, Joel Goldstick wrote: So, beyond that, what is the point of the thread? You haven't met Ranting Rick yet? He's a troll's troll, outdone only by one other whose name I don't remember. His posts are, amazingly enough, rants. Usually about his (mis)perceptions of the

Re: PyMyth: Global variables are evil... WRONG!

i took your straw-man and > converted him into satire. You owe me gratitude for > *politely* ignoring your repeated logical fallacies. > >> Yes, the point is that process-wide global variables are >> demonstrated by 50+ years of programming experience to be >> best avoided

Re: PyMyth: Global variables are evil... WRONG!

're talking about the coder > shooting themselves in the foot, not Gunfight At The OK Corral. There's > no "favour" to return. And you missed the point that i took your straw-man and converted him into satire. You owe me gratitude for *politely* ignoring your repeated logi

Re: PyMyth: Global variables are evil... WRONG!

On Thu, 14 Nov 2013 14:29:41 +1100, Chris Angelico wrote: > On Thu, Nov 14, 2013 at 2:22 PM, Rick Johnson > wrote: >> Yeah, a "global" keyword that extends access ONLY as far as module >> level scope -- hardly a *true* global. > > I have yet to see any language that gives true globals. At very b

Re: PyMyth: Global variables are evil... WRONG!

highly coupled code is harmful whether it occurs due to global variables or via RPC calls or some other mechanism. But the difference is you have to work at it to write such highly coupled code with RPC calls, while with single-process globals such coupling occurs naturally without effort.

Re: PyMyth: Global variables are evil... WRONG!

ment and the "old shot-gun that Grandpa > has in the closet under lock and key" is your argument. That's the most insightful observation you've made in this thread so far. Yes, the point is that process-wide global variables are demonstrated by 50+ years of programming experience

Re: PyMyth: Global variables are evil... WRONG!

On Thu, Nov 14, 2013 at 3:33 PM, Roy Smith wrote: > In article , > Chris Angelico wrote: > >> I have yet to see any language that gives true globals. At very best, >> they're just process-wide! Honestly. How am I supposed to write code >> that accesses variables running on my New York server? >

Re: PyMyth: Global variables are evil... WRONG!

On Wednesday, November 13, 2013 10:33:22 PM UTC-6, Roy Smith wrote: > Wait, aren't you the guy who's into MUDs? Yes he is. But that's his second favorite hobby. His first is filling the "Devils Advocate" slot when Steven is too busy -- doing WHATEVER Steven does when he's not here. God only

Re: PyMyth: Global variables are evil... WRONG!

In article , Chris Angelico wrote: > I have yet to see any language that gives true globals. At very best, > they're just process-wide! Honestly. How am I supposed to write code > that accesses variables running on my New York server? Any one of a slew of remote procedure call protocols. These

Re: PyMyth: Global variables are evil... WRONG!

And what's this? *picks up hat* Where did this hat come from??? Spectator interrupts: Maybe Steven threw his hat in? No, no. Can't be. Steven would not wear something this old. I mean, it looks like something a farmer would put on a scarecrow or something??? *scratched head* OH

Re: PyMyth: Global variables are evil... WRONG!

On Wednesday, November 13, 2013 8:45:16 PM UTC-6, Steven D'Aprano wrote: > A fully-auto machine gun with a hair-trigger and no > safety is no different from a single-barrel shotgun with > a safety and a trigger lock! You can blow your foot off > with both! Yes. But in the case of the shotgun

Re: PyMyth: Global variables are evil... WRONG!

On Thu, Nov 14, 2013 at 2:22 PM, Rick Johnson wrote: > Yeah, a "global" keyword that extends access ONLY as far as > module level scope -- hardly a *true* global. I have yet to see any language that gives true globals. At very best, they're just process-wide! Honestly. How am I supposed to write

Re: PyMyth: Global variables are evil... WRONG!

On Wednesday, November 13, 2013 7:09:42 PM UTC-6, Steven D'Aprano wrote: > On Wed, 13 Nov 2013 23:42:24 +, Rhodri James wrote: > > On Tue, 12 Nov 2013 02:06:09 -, Rick Johnson wrote: > >> Python has globals, but we just can't admit it! > > A different subject entirely, but no more accuratel

Re: PyMyth: Global variables are evil... WRONG!

On Wed, 13 Nov 2013 18:10:59 -0800, Rick Johnson wrote: > On Wednesday, November 13, 2013 5:42:24 PM UTC-6, Rhodri James wrote: >> On Tue, 12 Nov 2013 02:06:09 -, Rick Johnson wrote: >> > PyMyth: Global variables are evil... WRONG! >> That's not a PyMyth. It&#

Re: PyMyth: Global variables are evil... WRONG!

On Wednesday, November 13, 2013 6:17:22 PM UTC-6, Tim Daneliuk wrote: > > But python modules can't be interfaces because interfaces > > should protect internal data, prevent external forces from > > meddling with internal state (EXCEPT via the rules of a > > predefined "contract"), hide dirty detai

Re: PyMyth: Global variables are evil... WRONG!

On Wednesday, November 13, 2013 4:00:15 PM UTC-6, Andrew Cooper wrote: > And what do you do when the wizards bend space-time to > make PI exactly 3, for the ease of other calculations when > building a sorting machine? Are you telling me that these wizards can't be bothered to write the integer "3

Re: PyMyth: Global variables are evil... WRONG!

On Wednesday, November 13, 2013 5:42:24 PM UTC-6, Rhodri James wrote: > On Tue, 12 Nov 2013 02:06:09 -, Rick Johnson wrote: > > PyMyth: Global variables are evil... WRONG! > That's not a PyMyth. It's a CompSciMyth, or to be more > accurate a good general Softw

Re: PyMyth: Global variables are evil... WRONG!

On Wed, 13 Nov 2013 23:42:24 +, Rhodri James wrote: > On Tue, 12 Nov 2013 02:06:09 -, Rick Johnson > wrote: > >> PyMyth: Global variables are evil... WRONG! > > That's not a PyMyth. It's a CompSciMyth, or to be more accurate a good > general Softwar

Re: PyMyth: Global variables are evil... WRONG!

On 11/11/2013 10:46 PM, Rick Johnson wrote: On Monday, November 11, 2013 8:47:09 PM UTC-6, Tim Daneliuk wrote: I think this is certainly the use case most people would suggest. But I think you may have missed the real reason most modern designers object to inter-module globals: The presence of

Re: PyMyth: Global variables are evil... WRONG!

On 13/11/2013 23:42, Rhodri James wrote: On Tue, 12 Nov 2013 02:06:09 -, Rick Johnson wrote: PyMyth: Global variables are evil... WRONG! That's not a PyMyth. It's a CompSciMyth, or to be more accurate a good general Software Engineering guideline regardless of language.

Re: PyMyth: Global variables are evil... WRONG!

On Tue, 12 Nov 2013 02:06:09 -, Rick Johnson wrote: PyMyth: Global variables are evil... WRONG! That's not a PyMyth. It's a CompSciMyth, or to be more accurate a good general Software Engineering guideline regardless of language. Like all guidelines it can be broken,

Re: PyMyth: Global variables are evil... WRONG!

On 13/11/2013 02:45, Rick Johnson wrote: > > "math.pi" should be "math.PI". and PI should be a CONSTANT. > And not just a pseudo constant, but a REAL constant that > cannot be changed. > And what do you do when the wizards bend space-time to make PI exactly 3, for the ease of other calculation

Re: PyMyth: Global variables are evil... WRONG!

On 2013-11-12 18:45, Rick Johnson wrote: > "math.pi" should be "math.PI". It's a real shame that this fails: >>> math.PI = math.pi oh...wait... > and PI should be a CONSTANT. And not just a pseudo constant, but a > REAL constant that cannot be changed. How much precision do you want? Perhap

Re: PyMyth: Global variables are evil... WRONG!

On Tuesday, November 12, 2013 4:41:34 PM UTC-6, jongiddy wrote: > On Tuesday, November 12, 2013 5:00:37 PM UTC, Rick Johnson wrote: > >1. Accept that globals are useful, and make them > > available through a "real" global syntax, not > > some attribute of a module that "appears" to

Re: PyMyth: Global variables are evil... WRONG!

On 11/11/2013 11:46 PM, Rick Johnson wrote: No, Python modules can be poked, prodded, and violated by any pervert who can spell the word "import". Or by clever programmers. Attribute values can be reassigned and state can be externally manipulated Perhaps for good reasons. resulting in a

Re: PyMyth: Global variables are evil... WRONG!

On Tuesday, November 12, 2013 5:00:37 PM UTC, Rick Johnson wrote: > > >1. Accept that globals are useful, and make them > > available through a "real" global syntax, not > > some attribute of a module that "appears" to be > > local, but in reality is global. Then prevent

Re: PyMyth: Global variables are evil... WRONG!

On Tuesday, November 12, 2013 11:00:37 AM UTC-6, Rick Johnson wrote: [snip] > We have all been brainwashed by authorities. First they > give us rules, then they give us the power to break > those rules. The devil himself said it best: http://www.youtube.com/watch?v=RGR4SFOimlk Hmm. How do we

Re: PyMyth: Global variables are evil... WRONG!

On 2013-11-12 09:00, Rick Johnson wrote: > Because the constant PI should never change. Sure we can > argue about granularity of PI, but that argument has no > weight on the fact that PI should be a constant. > > By placing PI in the module "math", we are creating a pseudo > interface. We (the cre

Re: PyMyth: Global variables are evil... WRONG!

eved that Python does not have globals, but it does! You just have to mutate then via a pseudo interface. > is why I was asking for a good example (i.e. > a realistic example where the use of global variables > provides the best solution). I gave a good example in my very first post: RR:

Re: PyMyth: Global variables are evil... WRONG!

o other modules and changing their attributes is a GOOD idea. This inconsistency is why I was asking for a good example (i.e. a realistic example where the use of global variables provides the best solution). Just because a tool allows you to do something does not make it a good idea. Try this para

Re: PyMyth: Global variables are evil... WRONG!

are just annoying to try to play (and nearly impossible for the church to follow), but when you find those really brilliant pieces that do something special (Sir Arthur Sullivan, I'm looking at you - especially having just been reading the booklet that came with the new Beauty Stone reco

Re: PyMyth: Global variables are evil... WRONG!

y. The fact that we have to mutate them via a "psuedo" interface makes us "falsely" believe we are using an interface -- but we aren't! PYTHON MADE ACCESSING GLOBAL VARIABLES MORE DIFFICULT! As example. I could import the math module and start fiddling with attributes. Let

Re: PyMyth: Global variables are evil... WRONG!

On Mon, 11 Nov 2013 18:06:09 -0800, Rick Johnson wrote: > > In this thread, i want to get to the bottom of this whole > "global-phobia" thing once and for all, and hopefully help you folks > understand that globals are not all that bad -- when DESIGNED and USED > correctly that is! it is the fin

Re: PyMyth: Global variables are evil... WRONG!

On Tuesday, November 12, 2013 2:06:09 AM UTC, Rick Johnson wrote: > > > > Justifying Global Variables: > > > > Globals are justified when they

Re: PyMyth: Global variables are evil... WRONG!

On 2013-11-11 20:46, Rick Johnson wrote: > Yes, and i agree. But you cannot "hide" everything. There > will always be a need to share information. You may not be able to (or want to) hide everything, but sharing should at least happen over defined protocols (functions/methods). Otherwise, you wand

Re: PyMyth: Global variables are evil... WRONG!

y code, my responsibility, my business not yours. that does not sound like an interface to me. So if python modules are importable everywhere, and mutable from everywhere, then python modules are merely addresses to a collection of global variables? And they're only interfaces "sup

Re: PyMyth: Global variables are evil... WRONG!

On Tue, Nov 12, 2013 at 3:46 PM, Rick Johnson wrote: > But python modules can't be interfaces because interfaces > should protect internal data, prevent external forces from > meddling with internal state (EXCEPT via the rules of a > predefined "contract"), hide dirty details from the caller, > an

Re: PyMyth: Global variables are evil... WRONG!

modules are importable everywhere, and mutable from everywhere, then python modules are merely addresses to a collection of global variables? And they're only interfaces "superficially"? So that leaves us with Python's current implementation of unofficial "global"

Re: PyMyth: Global variables are evil... WRONG!

On 11/11/2013 08:06 PM, Rick Johnson wrote: Globals are justified when they are used to communicate information between scopes that otherwise were meant to be mutually exclusive. I think this is certainly the use case most people would suggest. But I think you may have missed the real reason

PyMyth: Global variables are evil... WRONG!

PyMyth: Global variables are evil... WRONG! Python's Global Hysteria: How many times have your heard or read the phrase: "Global variables are evil"? Well i

Global variables in a C extension for Python

Hello, I've written a C extension for Python which works so far, but now I've stumbled onto a simple problem for which I just can't find any example on the web, so here I am crying for help ;-) I'll trying to reduce the problem to a minimal example. Let's say I need to call from Python functions

Re: executing a function with feeding its global variables

te that the assert makes sure the HOST variable is indeed present in >> the globals when running the function. When running function.py, I get >> an NameError exception. When I put the func function in the framework >> module and execute framework.py as a script, this works fine,

Re: executing a function with feeding its global variables

> global HOST is available in the func namespace which gets printed. I > tried many combinations of eval() or exec as well as many combinations > for the globals() and locals() mapping fed to eval/exec without > success. Every module has its own global namespace, and a function is l

executing a function with feeding its global variables

Hello, I am writing a small framework where the user which writes a function can expect some global variable to be set in the function namespace. The user has to write a function like this: """ # function.py from framework import, command, run @command def myfunc(): print HOST if __name__==

Re: Global variables problem

Navkirat Singh wrote: On 04-Aug-2010, at 9:46 AM, Daniel da Silva wrote: Please post approximate code that actually works and displays the problem. On Tue, Aug 3, 2010 at 9:00 PM, Navkirat Singh > wrote: Hey guys, I am using a multiprocessing program, w

Re: Global variables problem

Usually, modify global variables in a multi-thread/multi-process scenario is not the right to operate: you better re-implement your solution in a way that the shared resource is either protected with synchronized objects or accessed by a single thread/process (and in this case, it won't

Re: Global variables problem

So, appending a () will make it goto that function, thereby changing the > global variable : ) > > Thanks, > Nav > > > On 04-Aug-2010, at 11:42 AM, Daniel da Silva wrote: > >> Your problem lies somewhere in the use of the Process class, not with global >> vari

Re: Global variables problem

ion, thereby changing the global variable : ) Thanks, Nav On 04-Aug-2010, at 11:42 AM, Daniel da Silva wrote: > Your problem lies somewhere in the use of the Process class, not with global > variables. > > If you replace your "p = ..." and "p.start()" lines with a dire

Re: Global variables problem

Your problem lies somewhere in the use of the Process class, not with global variables. If you replace your "p = ..." and "p.start()" lines with a direct call to self.handle_connection(), your code works as expected. I don't know much about the multiprocessing module, so

Re: Global variables problem

On 04-Aug-2010, at 9:46 AM, Daniel da Silva wrote: > Please post approximate code that actually works and displays the problem. > > On Tue, Aug 3, 2010 at 9:00 PM, Navkirat Singh wrote: > Hey guys, > > I am using a multiprocessing program, where the new process is supposed to > change a vari

Re: Global variables problem

Please post approximate code that actually works and displays the problem. On Tue, Aug 3, 2010 at 9:00 PM, Navkirat Singh wrote: > Hey guys, > > I am using a multiprocessing program, where the new process is supposed to > change a variable in the main class that it branches out from. This is > s

Global variables problem

Hey guys, I am using a multiprocessing program, where the new process is supposed to change a variable in the main class that it branches out from. This is somehow not working, following is an approximate code. Would really appreciate any insight into this matter: var = {} class Something():

Re: Global variables for python applications

On 2010-05-19 07:34:37 -0700, Steven D'Aprano said: # Untested. def verbose_print(arg, level, verbosity=1): if level <= verbosity: print arg def my_function(arg): my_print(arg, level=2) return arg.upper() if __name__ == '__main__': if '--verbose' in sys.argv:

Re: Global variables for python applications

On Wed, 19 May 2010 00:16:56 -0700, TomF wrote: > Let's say you have a bunch of globals, one of which is a verbose flag. > If I understand the difference, using a module gbls.py: > > # in gbls.py > verbose = False > # elsewhere: > import gbls > gbls.verbose = True > > Using a class: > > # In th

Re: Global variables for python applications

On 2010-05-16 12:27:21 -0700, christian schulze said: On 16 Mai, 20:20, James Mills wrote: On Mon, May 17, 2010 at 4:00 AM, Krister Svanlund wrote: On Sun, May 16, 2010 at 7:50 PM, AON LAZIO wrote:    How can I set up global variables for the entire python applications? Like I can call

Re: Global variables for python applications

Steven D'Aprano wrote: > I think it is an abuse of the term constant to allow you to talk about a > mutable object being "constant", since it can vary. Generally, you don't > care about identity, only equality. Making up a syntax on the spot: > > constant pi = [3.1415] > assert pi = 3.1415 > p

Re: Global variables for python applications

On Mon, 17 May 2010 23:54:38 +0100, Rhodri James wrote: > On Mon, 17 May 2010 05:29:20 +0100, Steven D'Aprano > wrote: > >> On Sun, 16 May 2010 18:57:15 -0700, John Nagle wrote: >> >>> James Mills wrote: >>>> The only place global variables a

Re: Global variables for python applications

2010/5/16 Chris Rebert : > On Sun, May 16, 2010 at 10:50 AM, AON LAZIO wrote: >> Hi, >>How can I set up global variables for the entire python applications? >> Like I can call and set this variables in any .py files. >>Think of it as a global variable in a sing

Re: Global variables for python applications

On Mon, 17 May 2010 05:29:20 +0100, Steven D'Aprano wrote: On Sun, 16 May 2010 18:57:15 -0700, John Nagle wrote: James Mills wrote: The only place global variables are considered somewhat "acceptable" are as constants in a module shared as a static value. Python reall

Re: Global variables for python applications

On Mon, 17 May 2010 19:56:15 +1200, Gregory Ewing wrote: > John Nagle wrote: >> Also, more compile-time arithmetic becomes possible. > > But only if their values can be computed at compile time. John said "more", not "everything imaginable can be calculated at compile time" :) Python already d

Re: Global variables for python applications

John Nagle wrote: Also, more compile-time arithmetic becomes possible. But only if their values can be computed at compile time. This leads to a huge can of worms if you want to be able to import named constants from other modules. A large part of what currently happens only at run time would h

Re: Global variables for python applications

On Mon, May 17, 2010 at 2:24 PM, Steven D'Aprano wrote: > In what way are they constant? Can you not modify them and rebind them? It's just style/convention :) Much like _ to denote private variables and methods! --james -- http://mail.python.org/mailman/listinfo/python-list

Re: Global variables for python applications

On Sun, 16 May 2010 18:57:15 -0700, John Nagle wrote: > James Mills wrote: >> The only place global variables are considered somewhat "acceptable" >> are as constants in a module shared as a static value. > > Python really ought to have named constants.

Re: Global variables for python applications

On Mon, 17 May 2010 13:34:57 +1000, James Mills wrote: > On Mon, May 17, 2010 at 11:57 AM, John Nagle wrote: >>   For one thing, it's fine to share constants across threads, while >> sharing globals is generally undesirable.  Also, more compile-time >> arithmetic becomes possible. >> >>   Python

Re: Global variables for python applications

On Mon, May 17, 2010 at 11:57 AM, John Nagle wrote: >   For one thing, it's fine to share constants across threads, while > sharing globals is generally undesirable.  Also, more compile-time > arithmetic becomes possible. > >   Python does have a few built-in named unassignable constants: > "True"

Re: Global variables for python applications

James Mills wrote: The only place global variables are considered somewhat "acceptable" are as constants in a module shared as a static value. Python really ought to have named constants. For one thing, it's fine to share constants across threads, while sharing globa

Re: global variables in imported modules

On 17 mayo, 00:52, Patrick Maupin wrote: > On May 16, 5:38 pm, James Mills wrote: > > > On Mon, May 17, 2010 at 8:26 AM, vsoler wrote: > > > However, can I be 100% sure that,no matter how I access variable > > > 'x' (with config.x or mod.config.x) it is always the same 'x'. I mean > > > that eit

Re: global variables in imported modules

On May 16, 5:38 pm, James Mills wrote: > On Mon, May 17, 2010 at 8:26 AM, vsoler wrote: > > However, can I be 100% sure that,no matter how I access variable > > 'x' (with config.x or mod.config.x) it is always the same 'x'. I mean > > that either reference of 'x' points to the same id(memory posi

Re: global variables in imported modules

On 17 mayo, 00:38, James Mills wrote: > On Mon, May 17, 2010 at 8:26 AM, vsoler wrote: > > However, can I be 100% sure that,no matter how I access variable > > 'x' (with config.x or mod.config.x) it is always the same 'x'. I mean > > that either reference of 'x' points to the same id(memory posit

Re: global variables in imported modules

On Mon, May 17, 2010 at 8:26 AM, vsoler wrote: > However, can I be 100% sure that,no matter how I access variable > 'x' (with config.x or mod.config.x) it is always the same 'x'. I mean > that either reference of 'x' points to the same id(memory position)? Yes it does unless you re-assign it. --

Re: global variables in imported modules

On 17 mayo, 00:05, Patrick Maupin wrote: > On May 16, 4:42 pm, vsoler wrote: > > > > > Taken fromwww.python.org, FAQ 2.3 How do I share global variables > > across modules? > > > config.py: > > > x = 0   # Default value of the 'x' con

Re: global variables in imported modules

On Sun, 16 May 2010 22:42:40 +0100, vsoler wrote: Taken from www.python.org, FAQ 2.3 How do I share global variables across modules? config.py: x = 0 # Default value of the 'x' configuration setting mod.py: import config config.x = 1 main.py: import config # try r

Re: global variables in imported modules

On May 16, 4:42 pm, vsoler wrote: > Taken fromwww.python.org, FAQ 2.3 How do I share global variables > across modules? > > config.py: > > x = 0   # Default value of the 'x' configuration setting > > mod.py: > > import config > config.x = 1 > > m

global variables in imported modules

Taken from www.python.org, FAQ 2.3 How do I share global variables across modules? config.py: x = 0 # Default value of the 'x' configuration setting mod.py: import config config.x = 1 main.py: import config # try removing it import mod print config.x The example, such a

Re: Global variables for python applications

On 16 Mai, 20:20, James Mills wrote: > On Mon, May 17, 2010 at 4:00 AM, Krister Svanlund > > wrote: > > On Sun, May 16, 2010 at 7:50 PM, AON LAZIO wrote: > >>    How can I set up global variables for the entire python applications? > >> Like I can call and se

Re: Global variables for python applications

On Mon, May 17, 2010 at 4:00 AM, Krister Svanlund wrote: > On Sun, May 16, 2010 at 7:50 PM, AON LAZIO wrote: >>    How can I set up global variables for the entire python applications? >> Like I can call and set this variables in any .py files. >>    Think of it as a global

  1   2   3   4   >