Namespace globals? about p5 HOT 11 OPEN

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!

from p5.

I will do this after skia, to avoid hidden bugs due to this.

from p5.

(just sent you a message on reddit about this)

from p5.

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)

from 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

from p5.

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

from p5.

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 ?

from p5.

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 !

from p5.

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.

from p5.

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 ?

from p5.

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)

from p5.