Menu
▾
▴
visualpython-users
|
From: Guy K. K. <g....@ma...> - 2010-10-08 23:07:41
|
On Sat, 09 Oct 2010 10:44:29 Bruce Sherwood wrote: > This proposal assumed that the "libvisual" file was in the visual > folder, in which case I thought that relative imports were now > favored, for various reasons. As I understand it, the main issue is > that there could be a module named "foo" at a higher level in the > search path, in which case "import foo" might not pick up our foo, but > someone else's foo. Have I misunderstood something? Well, not really. It's just that the use of relative imports is mainly intended for corner cases, but it's discouraged to be used on a general basis. Of course, things could break if there's a clash between two "foo" modules. This is called "shadowing". One common case is for example when people call a variable "file" and therefore are shadowing the built-in "file" type. In other cases, this behaviour is exactly desired, so for example when people *want* to use a specific implementation as a drop-in replacement for an otherwise used package. This is for example quite common with the XML parser through the ElementTree API. Many APIs are designed to be compatible with each other, another one of those are the ones of the threading/processing modules. So a user can choose which one to use (for various reasons). So what it boils down to is to commonly use absolute imports rather than relative ones, unless something demands a relative import for specific reasons. From the Python documentation [1]: "Relative imports can lead to a module being initialized twice, leading to confusing bugs. See PEP 328 [2] for details." You can read up more on this and related issues more on [1], [2] and [3]. Guy [1] http://docs.python.org/faq/programming.html#what-are-the-best-practices- for-using-import-in-a-module [2] http://docs.python.org/release/2.5/whatsnew/pep-328.html [3] http://bugs.python.org/issue10031 Guy -- Guy K. Kloss Institute of Information and Mathematical Sciences Te Kura Pūtaiao o Mōhiohio me Pāngarau Massey University, Albany (North Shore City, Auckland) 473 State Highway 17, Gate 1, Mailroom, Quad B Building voice: +64 9 414-0800 ext. 9266 fax: +64 9 441-8181 G....@ma... http://www.massey.ac.nz/~gkloss |
|
From: Bruce S. <bas...@nc...> - 2010-10-09 00:11:51
|
I think and hope we're in agreement. My point was a narrow technical one, that in the matplotlib case the simplified import could be handled with a single file (pylab.py) whereas we need a folder named visual due to the existence of visual.graph and visual.factorial and possible imports by someone of other files currently in the visual folder. Bruce Sherwood On Fri, Oct 8, 2010 at 4:40 PM, Guy K. Kloss <g....@ma...> wrote: > On Sat, 09 Oct 2010 10:41:35 Bruce Sherwood wrote: >> Are you saying that there should be two copies of key components in >> the two folders (which I'll call "visual" and "vpython" for now)? I >> would be nervous about the maintenance issues, although I guess >> installers be built to put copies of files in two places. > > No no no. Absolutely not. The code is there only *once*, but as you're > "mirroring in" parts of the NumPy and math name spaces, you'd be "mirroring > in" all the stuff into the "visual" package from the "vpython" packages. So > the "visual" package/module does not really contain any (significant) > implementations, but just imports/aggregates the stuff from "around the > house". > >> My intention >> is that if the actual implementation is done right it should make no >> difference whatsoever where the components are physically located, >> that importing from the vpython folder will be completely clean, >> independent of where the files are. > > Exactly, that's the way I (and probably the others putting up their votes for > better Python cleanliness) have envisioned it. > > Guy > > -- > Guy K. Kloss > Institute of Information and Mathematical Sciences > Te Kura Pūtaiao o Mōhiohio me Pāngarau > Massey University, Albany (North Shore City, Auckland) > 473 State Highway 17, Gate 1, Mailroom, Quad B Building > voice: +64 9 414-0800 ext. 9266 fax: +64 9 441-8181 > G....@ma... http://www.massey.ac.nz/~gkloss |
|
From: C A. R. <an...@ex...> - 2010-10-09 00:44:10
|
On Fri, Oct 8, 2010 at 7:11 PM, Bruce Sherwood <bas...@nc...> wrote: > > I think and hope we're in agreement. My point was a narrow technical > one, that in the matplotlib case the simplified import could be > handled with a single file (pylab.py) whereas we need a folder named > visual due to the existence of visual.graph and visual.factorial and > possible imports by someone of other files currently in the visual > folder. Nothing new to add, I just wanted to briefly chime about a few things (from older messages too): ) +3, 2, 1 for either "vpython", "vispy", or "visuallib", respectively as the clean package name, for consistency with related projects (libvisual looks nice to me, but it does give the impression of a shared object i suppose) ) clean package should _definitely_ be it's own package/top-level, and not in the visual namespace ) clean package should have _all_ the functionality, "visual" should just pull from it like it does from numpy and friends; anything in "visual" is specific to the backwards compat requirement or convenience As for the visual.graph etc. problems... "visual" may indeed need to remain a package, and visual.graph can pull from the clean package like anything else within the "visual" package. I'm looking into it now if there is a way to make a module "pretend" to be a package, then dynamically create additional modules/etc. within it's namespace; then maybe we could have a single file called "visual.py"... not sure yet, I don't know if the import machinery will allow it. C Anthony |
|
From: Guy K. K. <g....@ma...> - 2010-10-09 00:49:43
|
On Sat, 09 Oct 2010 13:11:44 Bruce Sherwood wrote: > I think and hope we're in agreement. My point was a narrow technical > one, that in the matplotlib case the simplified import could be > handled with a single file (pylab.py) whereas we need a folder named > visual due to the existence of visual.graph and visual.factorial and > possible imports by someone of other files currently in the visual > folder. Wouldn't it make sense to have "vpython" (or any other name) as a package (folder/directory), which contains then the modules graph and factorial? Then visual would just need to be a module (visual.py) to import the stuff from vpython, vpython.graph, vpython.factorial, ... Guy -- Guy K. Kloss Institute of Information and Mathematical Sciences Te Kura Pūtaiao o Mōhiohio me Pāngarau Massey University, Albany (North Shore City, Auckland) 473 State Highway 17, Gate 1, Mailroom, Quad B Building voice: +64 9 414-0800 ext. 9266 fax: +64 9 441-8181 G....@ma... http://www.massey.ac.nz/~gkloss |
|
From: C A. R. <an...@ex...> - 2010-10-09 03:05:29
|
On Fri, Oct 8, 2010 at 7:47 PM, Guy K. Kloss <g....@ma...> wrote: > On Sat, 09 Oct 2010 13:11:44 Bruce Sherwood wrote: >> I think and hope we're in agreement. My point was a narrow technical >> one, that in the matplotlib case the simplified import could be >> handled with a single file (pylab.py) whereas we need a folder named >> visual due to the existence of visual.graph and visual.factorial and >> possible imports by someone of other files currently in the visual >> folder. > > Wouldn't it make sense to have "vpython" (or any other name) as a package > (folder/directory), which contains then the modules graph and factorial? I 100% agree here... and a bit of reiteration, but the clean module *must* have all the guts, "visual" becomes a "meeting ground"/facade of "vpython", numpy, etc., along with some convenience stuff. "visual" package should do nothing significant. > Then visual would just need to be a module (visual.py) to import the stuff > from vpython, vpython.graph, vpython.factorial, ... After some research I really don't think this is possible; it would only work if importing "visual" directly, ie. `import visual`. The standard import machinery directly translates the dotted package name to a directory hierarchy... the only way I see around this is by using sys.meta_path, or possibly some tweaking from a C module, but the latter is beyond my knowledge. So, it may have to remain a package for compatibility, but that doesn't mean it needs to implement anything significant; it can still import what it needs from "vpython". C Anthony |
|
From: Guy K. K. <g....@ma...> - 2010-10-09 03:11:17
|
On Sat, 09 Oct 2010 16:05:22 C Anthony Risinger wrote: > So, it may have to remain a package for compatibility, but that > doesn't mean it needs to implement anything significant; it can still > import what it needs from "vpython". It could be an empty package, that only contains a __init__.py, which does all the import magic. Guy -- Guy K. Kloss Institute of Information and Mathematical Sciences Te Kura Pūtaiao o Mōhiohio me Pāngarau Massey University, Albany (North Shore City, Auckland) 473 State Highway 17, Gate 1, Mailroom, Quad B Building voice: +64 9 414-0800 ext. 9266 fax: +64 9 441-8181 G....@ma... http://www.massey.ac.nz/~gkloss |
|
From: C A. R. <an...@ex...> - 2010-10-09 15:52:16
|
On Fri, Oct 8, 2010 at 10:09 PM, Guy K. Kloss <g....@ma...> wrote: > On Sat, 09 Oct 2010 16:05:22 C Anthony Risinger wrote: >> So, it may have to remain a package for compatibility, but that >> doesn't mean it needs to implement anything significant; it can still >> import what it needs from "vpython". > > It could be an empty package, that only contains a __init__.py, which does all > the import magic. That's what I meant :-) I was trying to see if it was possible to do it with only a file, visual.py like pylab, but I just don't think that will work. __init__.py can append a finder to sys.meta_path, which will then be used to properly build the namespace/"virtual" package contents. Some brief tests looked fine, but I'll try to make something more concrete later today. C Anthony |
|
From: Bruce S. <bas...@nc...> - 2010-10-09 15:08:39
|
I had read those same documents about imports and reached the opposite conclusions! The full context in your reference [1] is this: "Never use relative package imports. If you’re writing code that’s in the package.sub.m1 module and want to import package.sub.m2, do not just write import m2, even though it’s legal. Write from package.sub import m2 instead. Relative imports can lead to a module being initialized twice, leading to confusing bugs. See PEP 328 for details." By "relative import" here they mean "import m2" inside a package, which has the danger of importing some module named m2 that is outside the package. As I read the documents, the new dot notation is designed to make it possible for packages to be real packages, which can even be moved to a different folder and still work under the new package name. An example of the power of the dot notation is that for Python 3 I was able to make experimental versions of IDLE and VIDLE that except for one single very special statement don't refer to either "idlelib" or "vidle" and have mostly the same code inside the idlelib or vidle folder. If I've fundamentally misunderstood the point, perhaps a very specific example would help me see the error of my ways. Bruce Sherwood On Fri, Oct 8, 2010 at 5:05 PM, Guy K. Kloss <g....@ma...> wrote: > On Sat, 09 Oct 2010 10:44:29 Bruce Sherwood wrote: >> This proposal assumed that the "libvisual" file was in the visual >> folder, in which case I thought that relative imports were now >> favored, for various reasons. As I understand it, the main issue is >> that there could be a module named "foo" at a higher level in the >> search path, in which case "import foo" might not pick up our foo, but >> someone else's foo. Have I misunderstood something? > > Well, not really. It's just that the use of relative imports is mainly > intended for corner cases, but it's discouraged to be used on a general basis. > Of course, things could break if there's a clash between two "foo" modules. > This is called "shadowing". One common case is for example when people call a > variable "file" and therefore are shadowing the built-in "file" type. > > In other cases, this behaviour is exactly desired, so for example when people > *want* to use a specific implementation as a drop-in replacement for an > otherwise used package. This is for example quite common with the XML parser > through the ElementTree API. Many APIs are designed to be compatible with each > other, another one of those are the ones of the threading/processing modules. > So a user can choose which one to use (for various reasons). > > So what it boils down to is to commonly use absolute imports rather than > relative ones, unless something demands a relative import for specific > reasons. From the Python documentation [1]: "Relative imports can lead to a > module being initialized twice, leading to confusing bugs. See PEP 328 [2] for > details." > > You can read up more on this and related issues more on [1], [2] and [3]. > > Guy > > > [1] http://docs.python.org/faq/programming.html#what-are-the-best-practices- > for-using-import-in-a-module > > [2] http://docs.python.org/release/2.5/whatsnew/pep-328.html > > [3] http://bugs.python.org/issue10031 > > Guy > |
|
From: Bruce S. <bas...@nc...> - 2010-10-10 20:02:34
|
Maybe I'm using the word "relative" incorrectly. I'll try to be more clear: Suppose in the site-packages/visual folder the file __init__.py has "from visual.ui import display". That's clearly an absolute import; the full path visual.ui is given. In the past, you could instead say "from ui import display", and this was called a "relative" import. It had the problem of ambiguity with some possible module named ui, outside the visual module, and so this form was deprecated (and I think maybe it won't even work in Python 3). Though I only became aware of this recently, since at least Python 2.6 you can say "from .ui import display", where the dot makes this an absolute import, with the dot standing for "visual.". In this conversation I incorrectly called the dot form a "relative" import, because it is relative to the current directory. But it is really an absolute import, one that has the advantage that changing the name of the surrounding directory doesn't require any changes to the files. Bruce Sherwood On Sat, Oct 9, 2010 at 9:08 AM, Bruce Sherwood <bas...@nc...> wrote: > I had read those same documents about imports and reached the opposite > conclusions! > > The full context in your reference [1] is this: > > "Never use relative package imports. If you’re writing code that’s in > the package.sub.m1 module and want to import package.sub.m2, do not > just write import m2, even though it’s legal. Write from package.sub > import m2 instead. Relative imports can lead to a module being > initialized twice, leading to confusing bugs. See PEP 328 for > details." > > By "relative import" here they mean "import m2" inside a package, > which has the danger of importing some module named m2 that is outside > the package. As I read the documents, the new dot notation is designed > to make it possible for packages to be real packages, which can even > be moved to a different folder and still work under the new package > name. > > An example of the power of the dot notation is that for Python 3 I was > able to make experimental versions of IDLE and VIDLE that except for > one single very special statement don't refer to either "idlelib" or > "vidle" and have mostly the same code inside the idlelib or vidle > folder. > > If I've fundamentally misunderstood the point, perhaps a very specific > example would help me see the error of my ways. > > Bruce Sherwood > > On Fri, Oct 8, 2010 at 5:05 PM, Guy K. Kloss <g....@ma...> wrote: >> On Sat, 09 Oct 2010 10:44:29 Bruce Sherwood wrote: >>> This proposal assumed that the "libvisual" file was in the visual >>> folder, in which case I thought that relative imports were now >>> favored, for various reasons. As I understand it, the main issue is >>> that there could be a module named "foo" at a higher level in the >>> search path, in which case "import foo" might not pick up our foo, but >>> someone else's foo. Have I misunderstood something? >> >> Well, not really. It's just that the use of relative imports is mainly >> intended for corner cases, but it's discouraged to be used on a general basis. >> Of course, things could break if there's a clash between two "foo" modules. >> This is called "shadowing". One common case is for example when people call a >> variable "file" and therefore are shadowing the built-in "file" type. >> >> In other cases, this behaviour is exactly desired, so for example when people >> *want* to use a specific implementation as a drop-in replacement for an >> otherwise used package. This is for example quite common with the XML parser >> through the ElementTree API. Many APIs are designed to be compatible with each >> other, another one of those are the ones of the threading/processing modules. >> So a user can choose which one to use (for various reasons). >> >> So what it boils down to is to commonly use absolute imports rather than >> relative ones, unless something demands a relative import for specific >> reasons. From the Python documentation [1]: "Relative imports can lead to a >> module being initialized twice, leading to confusing bugs. See PEP 328 [2] for >> details." >> >> You can read up more on this and related issues more on [1], [2] and [3]. >> >> Guy >> >> >> [1] http://docs.python.org/faq/programming.html#what-are-the-best-practices- >> for-using-import-in-a-module >> >> [2] http://docs.python.org/release/2.5/whatsnew/pep-328.html >> >> [3] http://bugs.python.org/issue10031 >> >> Guy >> > |
|
From: C A. R. <an...@ex...> - 2010-10-10 22:09:34
|
On Sun, Oct 10, 2010 at 3:01 PM, Bruce Sherwood <bas...@nc...> wrote: > Maybe I'm using the word "relative" incorrectly. I'll try to be more clear: > > Suppose in the site-packages/visual folder the file __init__.py has > "from visual.ui import display". That's clearly an absolute import; > the full path visual.ui is given. > > In the past, you could instead say "from ui import display", and this > was called a "relative" import. It had the problem of ambiguity with > some possible module named ui, outside the visual module, and so this > form was deprecated (and I think maybe it won't even work in Python > 3). > > Though I only became aware of this recently, since at least Python 2.6 > you can say "from .ui import display", where the dot makes this an > absolute import, with the dot standing for "visual.". In this > conversation I incorrectly called the dot form a "relative" import, > because it is relative to the current directory. But it is really an > absolute import, one that has the advantage that changing the name of > the surrounding directory doesn't require any changes to the files. No, you are using it correctly: http://www.python.org/dev/peps/pep-0328/#guido-s-decision The syntax was introduced to remove the ambiguity, because the old form was being removed at the same time. It's still a relative import, since the meaning of the import can change as folders are shuffled around. C Anthony |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X