[issue46096] Support PyObject interface for global variables in local scope and debugger

Change by Dmitry : -- keywords: +patch pull_requests: +28359 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30141 ___ Python tracker ___

[issue46096] Support PyObject interface for global variables in local scope and debugger

by PyObject interface. But we faced with an issue: 1) Setting/deleting global variables in local scope are done outside of our control (without using PyObject interface). 2) A debugger (LOAD_NAME tag) does not see global variables in local scope. We would like to fix that issue by adding

[issue44129] zipfile: Add descriptive global variables for general purpose bit flags

Change by Vincent Michel : -- pull_requests: -26670 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue44129] zipfile: Add descriptive global variables for general purpose bit flags

Change by Vincent Michel : -- nosy: +vxgmichel nosy_count: 2.0 -> 3.0 pull_requests: +26670 pull_request: https://github.com/python/cpython/pull/28250 ___ Python tracker ___

[issue44129] zipfile: Add descriptive global variables for general purpose bit flags

Serhiy Storchaka added the comment: Thank you for your contribution Daniel. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.10 ___ Python tracker

[issue44129] zipfile: Add descriptive global variables for general purpose bit flags

Serhiy Storchaka added the comment: New changeset 556d5ad11fb380868c19beeba53d49f89c27f32d by Daniel Hillier in branch 'main': bpo-44129: Add descriptive global variables for general purpose bit flags (GH-26118) https://github.com/python/cpython/commit

[issue44129] zipfile: Add descriptive global variables for general purpose bit flags

Change by Daniel Hillier : -- keywords: +patch pull_requests: +24763 stage: -> patch review pull_request: https://github.com/python/cpython/pull/26118 ___ Python tracker ___

[issue44129] zipfile: Add descriptive global variables for general purpose bit flags

New submission from Daniel Hillier : In the zipfile module, masking of bit flags is done against hex numbers eg. if flags & 0x800... To increase readability I suggest we replace these with global variables named for the purpose of the flag. From the example above: if flags & 0x800

[issue42597] Improve documentation of locals() w.r.t. "free variables" vs. global variables

.org/3/reference/executionmodel.html#binding-of-names): > If a variable is used in a code block but not defined there, it is a free > variable. That definition includes global variables (and builtin ones), but these are not returned by locals(). For example compare the following: ``` x = 1 def

[issue39931] Global variables are not accessible from child processes (multiprocessing.Pool)

Change by Josh Rosenberg : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker ___ ___

[issue39931] Global variables are not accessible from child processes (multiprocessing.Pool)

Ronald Oussoren added the comment: Can this issue be closed? Multiprocessing seems to work as designed. There is a behaviour change between 3.7 and 3.8, but that's documented in What's New. -- ___ Python tracker

[issue39931] Global variables are not accessible from child processes (multiprocessing.Pool)

Change by Ned Deily : -- nosy: +davin, pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39931] Global variables are not accessible from child processes (multiprocessing.Pool)

STINNER Victor added the comment: > Shared memory/pickle cannot send file descriptors FYI Python 3.9 got new socket.send_fds() and socket.recv_fds() functions :-) https://docs.python.org/dev/library/socket.html#socket.socket.send_fds -- nosy: +vstinner

[issue39931] Global variables are not accessible from child processes (multiprocessing.Pool)

agmt added the comment: Shared memory/pickle cannot send file descriptors -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue39931] Global variables are not accessible from child processes (multiprocessing.Pool)

Thomas Grainger added the comment: yeah this is normal. on Python 3.8 mac multiprocessing switched to spawn you have to use https://docs.python.org/3/library/multiprocessing.shared_memory.html to share content between processes or pass it to be pickled in the args of imap_unordered

[issue39931] Global variables are not accessible from child processes (multiprocessing.Pool)

macOS files: test.py messages: 363892 nosy: agmt, ned.deily, ronaldoussoren priority: normal severity: normal status: open title: Global variables are not accessible from child processes (multiprocessing.Pool) type: behavior versions: Python 3.8 Added file: https://bugs.python.org/file48968/test.py __

[issue38331] Exec not recognizing global variables inside function

Terry J. Reedy added the comment: Ronald is correct, and for the reason given. Python functions are lexically scoped, not dynamically scoped, and you are expecting the latter. The exec global and local namespaces are used to resolve identifier in the code you pass. Your first example

[issue38331] Exec not recognizing global variables inside function

Huyston added the comment: Ronald Oussoren, I understand your comment and it makes sense in the module perspective. However, when using 'exec', we are explicitly passing a globals dict (and locals) that the target code should consider. As the documentation states: "If globals and locals

[issue38331] Exec not recognizing global variables inside function

Ronald Oussoren added the comment: I don't think this is a bug. def func(): print(var) This captures the globals at the time of definition, that is "global" references are resolved using the func.__globals__ attribute which is the globals dictionary at the time the function is created

[issue38331] Exec not recognizing global variables inside function

Krishna Oza added the comment: adding self to nosy list. -- nosy: +Krishna Oza ___ Python tracker ___ ___ Python-bugs-list mailing

[issue38331] Exec not recognizing global variables inside function

_globals,my_globals) Result: 14 14 So is this really a bug or is this the expected behavior somehow? -- components: Interpreter Core messages: 353622 nosy: Huyston priority: normal severity: normal status: open title: Exec not recognizing global variables inside function type: behavior versions

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

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'

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

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 In class.p

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 + 1 In c

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 Example:

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

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 > `global` keywo

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 =

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 how should

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 > `global` keywo

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` keyword inside

[issue20922] Global variables

New submission from VIJAY KANSAL: Inside functions: 1. Python allows access to global variables. 2. Python allows creation of local variable with the same name as that of of some of the global variable. Keeping the above two statements in mind, I believe that Python must allow following

[issue20922] Global variables and Local Variables with same name

Changes by VIJAY KANSAL vijaykans...@gmail.com: -- title: Global variables - Global variables and Local Variables with same name ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20922

[issue20922] Global variables and Local Variables with same name

Ezio Melotti added the comment: This is by design, see http://docs.python.org/3/faq/programming.html#why-am-i-getting-an-unboundlocalerror-when-the-variable-has-a-value -- nosy: +ezio.melotti resolution: - invalid stage: - committed/rejected status: open - closed

[issue20775] Modifications to global variables ignored after instantiating multiprocessing.Pool

processor (four cores). Is this expected behavior? Thanks very much, Naftali -- components: Library (Lib) files: reproduces.py messages: 212221 nosy: Naftali.Harris priority: normal severity: normal status: open title: Modifications to global variables ignored after instantiating

[issue20775] Modifications to global variables ignored after instantiating multiprocessing.Pool

Changes by Ned Deily n...@acm.org: -- nosy: +sbt ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue20775 ___ ___ Python-bugs-list mailing list

[issue20775] Modifications to global variables ignored after instantiating multiprocessing.Pool

Tim Peters added the comment: This is expected. global has only to do with the visibility of a name within a module; it has nothing to do with visibility of mutations across processes. On a Linux-y system, executing Pool(3) creates 3 child processes, each of which sees a read-only *copy* of

[issue20775] Modifications to global variables ignored after instantiating multiprocessing.Pool

Naftali Harris added the comment: Oh, ok, that makes a lot of sense. Thanks for the clear and patient explanation, Tim! Sorry to have bothered the Python bug tracker with this. --Naftali -- resolution: - invalid status: open - closed ___ Python

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

-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 spaghetti code of namespacing -- everything is mixed up together in one

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

On Sat, Nov 16, 2013 at 2:26 AM, Tim Daneliuk tun...@tundraware.com 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

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

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 tun...@tundraware.com 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*.

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

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 variables, and another is to limit the scope

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

On Sat, Nov 16, 2013 at 3:01 PM, Rick Johnson rantingrickjohn...@gmail.com 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

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

On Sat, Nov 16, 2013 at 3:01 PM, Rick Johnson rantingrickjohn...@gmail.com 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

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 rantingrickjohn...@gmail.com 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

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

. 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 logical fallacies. Yes, the point is that process-wide global variables are demonstrated by 50+ years of programming experience to be best avoided (in general

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

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 logical fallacies. Yes, the point is that process-wide global variables

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!

On Thu, Nov 14, 2013 at 12:56 PM, Ethan Furman et...@stoneleaf.us 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

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.

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 Fri, Nov 15, 2013 at 7:12 AM, Alister alister.w...@ntlworld.com 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

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 calculations when

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

On Tue, 12 Nov 2013 02:06:09 -, Rick Johnson rantingrickjohn...@gmail.com 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

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 rantingrickjohn...@gmail.com 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

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 Wed, 13 Nov 2013 23:42:24 +, Rhodri James wrote: On Tue, 12 Nov 2013 02:06:09 -, Rick Johnson rantingrickjohn...@gmail.com 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

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 Software Engineering guideline regardless

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 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 details from

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's a CompSciMyth, or to be more accurate

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 accurately

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

On Thu, Nov 14, 2013 at 2:22 PM, Rick Johnson rantingrickjohn...@gmail.com 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.

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!

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!

In article mailman.2580.1384399784.18130.python-l...@python.org, Chris Angelico ros...@gmail.com 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

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!

On Thu, Nov 14, 2013 at 3:33 PM, Roy Smith r...@panix.com wrote: In article mailman.2580.1384399784.18130.python-l...@python.org, Chris Angelico ros...@gmail.com wrote: I have yet to see any language that gives true globals. At very best, they're just process-wide! Honestly. How am I

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

in this thread so far. Yes, the point is that process-wide global variables are demonstrated by 50+ years of programming experience to be best avoided (in general -- there are caveats and exceptions of course). We're talking about probably millions of person-hours of experience leading

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

. Such 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!

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 superficially? So that leaves

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 wander

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 are used to communicate

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 final

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

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's say for example i can change the value of math.pi

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

. Global variables basically don't exist in Python. You have per-module state. And if you start monkey-patching, you're fiddling with someone else's module. It's all fun and games till someone loses a function... sys.stdout.write=None ChrisA -- https://mail.python.org/mailman/listinfo/python

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

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 paraphrase of your last post: Ladder designers act like standing on the top rung

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

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: Globals are justified when they are used to [share] information between scopes that otherwise were meant to be mutually

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 creators)

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 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 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

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 be

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? Perhaps you

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 if you've been

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

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

to a collection of global variables? And they're only interfaces superficially? So that leaves us with Python's current implementation of unofficial global variables implemented as puesdo- interfaces by module objects that are victims waiting to be violated. Interesting. IF IT WALKS LIKE A GLOBAL

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

On Tue, Nov 12, 2013 at 3:46 PM, Rick Johnson rantingrickjohn...@gmail.com 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

[issue14049] execfile() fails on files that use global variables inside functions

Terry J. Reedy tjre...@udel.edu added the comment: Searching on 'exec NameError' shows that this issue is a duplicate of (behavior issue) #1167300 which contained an essentially identical example exec \ ... x = 3 ... def f(): ... print x ... f() ... in {}, {} #1167300 was closed as a

[issue14049] execfile() fails on files that use global variables inside functions

: 153643 nosy: docs@python, techtonik priority: normal severity: normal status: open title: execfile() fails on files that use global variables inside functions versions: Python 2.7 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue14049

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

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

Re: executing a function with feeding its global variables

. 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 looking for global variables in the namespace it is defined in, not the one where

Re: executing a function with feeding its global variables

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 looking for global variables

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 I can't really comment

Re: Global variables problem

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 direct call to self.handle_connection(), your code works

  1   2   3   4   >