p5
p5 copied to clipboard
p5py
Namespace globals?
Question/Feature Request
Is there a good way to wrap all the global variables into a namespace? I think this would be great not just to for namespace's sake, but to allow external editors to use auto-complete and see function/global variable definitions. Alternatively, I wonder if you could generate mappings for all the global variables.
Is there a good way to wrap all the global variables into a namespace?
If I understand this correctly: you could just do: import p5 instead of from p5 import * and then prefix all your commands with p5.. You would then use p5.line(...), p5.circle(...) etc, for instance.
Alternatively, I wonder if you could generate mappings for all the global variables.
What do you mean? Can't you just use:
>>> import p5
>>> dir(p5)
for functions, yes. But other ambiguous global variables, no. For instance... frame_rate. It might work well to add these globals to a separate class. poorly named example:
import p5
# to use framerate
global_setup = GlobalSetup()
global_setup.frame_rate
By doing this, your IDE wouldn't give you hell, and it would point directly to a place in code with doc strings etc...
having this type of namespace will also make other features down the road much easier... ie a frame_buffer to export frames to images
using this test branch this file could be written this way.
Is that something you'd considered, the changes are somewhat huge...
❯ diff namespace.py profiling/arcs.py
1,2c1
< import p5
<
---
> from p5 import *
5c4
< p5.size(720, 400)
---
> size(720, 400)
10,15c9,14
< while x < 2 * p5.PI:
< p5.arc((50.0 + offset, 50.0), 50.0, 50.0, x, 2 * p5.PI)
< p5.arc((50.0 + offset, 100), 50, 50, x, 2 * p5.PI, mode='OPEN')
< p5.arc((50.0 + offset, 150), 50, 50, x, 2 * p5.PI, mode='CHORD')
< p5.arc((50.0 + offset, 200), 50, 50, x, 2 * p5.PI, mode='PIE')
< x += p5.QUARTER_PI
---
> while x < 2 * PI:
> arc((50.0 + offset, 50.0), 50.0, 50.0, x, 2 * PI)
> arc((50.0 + offset, 100), 50, 50, x, 2 * PI, mode='OPEN')
> arc((50.0 + offset, 150), 50, 50, x, 2 * PI, mode='CHORD')
> arc((50.0 + offset, 200), 50, 50, x, 2 * PI, mode='PIE')
> x += QUARTER_PI
19c18
< p5.run()
---
> run()
I encountered also some problems with the lack of namespace for variables Generally speaking, instead of using
from p5 import *
I ask my student to use
import p5
Yes, all function have to be prefixed this way
p5.circle(10,10,10)
...
But this is what I want
What is the problem for me is I expected the variables to act the same way. But P5.frame_count is inexistant. I have to use frame_count
Not very problematic, except for editors work. But more problematic is the use of global variables for width and height. This is clearly polluting the global namespace.
Any chance that variables in p5 will become soon part of p5 namespace ?
No news about this issue. I have to say that there is also width and height that are imported from p5 and "pollute" the global namespace. It's inadequate, because width and height can be used by programmers !
The possible solution to overcome this issue will then expose global variables as p5.width for width while importing as follows from p5 import *
This will not align properly with Processing's API, but we can implement it for p5py if the community needs it.
Thank you for your response. It is not aligned with processing API, but it is correct according to the pythonic way of creating modules and not polluting global namespace Those wanting to do so just use
from p5 import *
indeed ?
I tried fiddling with some code and it's possible to remove the variables from global namespace. We could simply use p5.widthX or the other way if we still want to use global variables and discard the use of builtins, is to inject the variables into the global namespace by appending them to __globals__ (but this hack might haunt many later).
The better approach seems to go with the convention of scoping variables to p5 (even though it's different from what we have in p5.js, but p5py was developed with the aim that we could have the benefits of processing with other python libraries)
I agree that restricting variables to be only visible within the p5 module is much more pythonic than the current approach. Although this change will break backward compatibility, but given that we are still in alpha versions, this probably is acceptable. @tushar5526 Feel free to open a PR on this once you get a chance!
