<div dir="ltr">On Thursday, March 17, 2016 at 12:25:36 PM UTC-5, Eric Snow wrote:<br><br>> So like Go does packages?  You should be able to do that<br>> using a custom loader and a path-entry finder to provide<br>> that loader.  See the importlib docs for more info.  Just<br>> be careful to only handle your special directories or else<br>> normal packages will break.<br><br>Yes, i had planned to do it in a manner that will exist side<br>by with the existing "official import mechanism". It's not<br>something i plan to do for "every single module". Only those<br>that have become "too large to easily edit". <br><br>> FWIW, there are more idiomatic ways to combine multiple<br>> files into a single module.  For instance, make a package<br>> containing your separate files but make the files private<br>> (leading underscore).  Then put "from XXX import *" for<br>> each of them.  If you want to limit what's exported from<br>> the package, either define __all__ in the sub-files or use<br>> "from XXX import YYY" in the package __init__.py.<br><br>Sure. That will allow me to "spread-out a large module's<br>source code into N smaller files", and then let Python<br>"combine the objects, defined in those multiple files, under<br>one monolithic namespace at run-time"... but i can't define<br>shared state between them *UNTIL* run-time -- at least, not<br>without resorting to "import spider webs" and monkey<br>patching.<br><br>I'm not trying to "define a module from N objects contained<br>in N source files", no, i'm trying to "define a *NAMESPACE*<br>from N source files". "N source files" that would<br>transparently share state just as though all the source<br>existed in the exact same file.<br><br>> As far as sharing a namespace between the sub-files, I'd<br>> recommend against an implicit mechanism (like Go does).<br>> I've found that it makes it harder to discover code.<br><br>Hmm, you're not the only person that has raised this issue.<br><br>I'm unaware of how Go handles namespaces, but i've used<br>other languages that *DO* offer a programmer the option of<br>"explicitly defining module namespace", and after writing<br>code for many years, I have not once encountered the issues<br>that you and others raise.<br><br>I'm speculating here, but it may be because i'm very OCD<br>about creating strong interfaces, and i avoid writing code<br>that rebinds symbols "in the shadows".  Of course, i'm not<br>suggesting that you, or anyone else, is incompetent, I'm<br>merely pondering, because it does sound like a legitimate<br>possibility...<br><br>Hey, i can tell you from personal experience: there is<br>nothing worst than implementing a "grand idea", only to find<br>out later, that it was "fools gold". O:-)<br><br></div>