Python's namespacing has these features that I haven't seen discussed yet: There are three common ways to import: "import list-abs", which just makes list-abs available for use, but you still need to type "list-abs.list-map" (the Python equivalent of [list-abs/list-map]). [1]
"from list-abs import list-map", makes it possible to just type "list-map". And finally "from list-abs import *", makes it possible to type any of the functions in list-abs without a prefix. The 3rd option is widely discouraged, because it makes it very unclear where a function comes from, or which one is in use. I greatly appreciate this arrangement, and I think it would be wise to follow. A 4th feature that reduces verbosity is the ability to write "import list-abs as l". And of course once things actually work, [list-map] could be renamed to just "map" to give [l/map], which I think is great. Cheers Luke On Wed, Apr 16, 2008 at 2:55 PM, Hans-Christoph Steiner <[EMAIL PROTECTED]> wrote: > > > On Apr 16, 2008, at 2:58 PM, Frank Barknecht wrote: > > Hallo, > > marius schebella hat gesagt: // marius schebella wrote: > > > >> Frank Barknecht wrote: > >>> Hallo, > >>> marius schebella hat gesagt: // marius schebella wrote: > >>> > >>>> sorry, I still don't know exactly what you mean. I think it is > >>>> the only > >>>> solution to keep libraries in subfolders if we want to solve > >>>> nameclashes. but even if in subfolders, they should be > >>>> accessible as > >>>> list-abs and not list-abs/list-abs. > >>> > >>> Huh? Nameclashes have nothing to do with subfolders per se. A > >>> nameclash > >>> is, when two objects have the same name registered in Pd but act > >>> differently. Folders are a way to organize files in a filesystem > >>> (harddisk). > >>> > >>>> the thing that I was complaining so loudly is that pd-extended > >>>> ships all > >>>> these libraries but does not add the paths. > >>> > >>> Yes, that's exactly what I mean: Many people would like every > >>> objectclass to be global. > >> > >> but that is not a problem for pd-extended users (and I want to > >> solve the > >> pd-extended problems here), as long as you can overrule the global > >> namespace with a local namespace. > > > > Not really: Say I use [urn] in Pd-extended. Which [urn] am I using? > > > > As pd-extended by popular demand (and for practical reasons) is > > configured to allow access to one of the [urn]s out of the box, I > > believe not many people are actually using the names [zexy/urn] or > > [maxlib/urn] or [cyclone/urn]. But all of these behave differently. > > So we have a hidden nameclash if you try to use a patch that assumes > > [urn] to be the one from the library, pd-extended loads as the second > > one. Now IIRC Hans' goal is to not load any library or set any path > > out of the box, so that all names would have to be qualified with > > directory prefixes or [declare]d. But when this behavious accidentally > > came into effect because of the change in plist-location on OS-X, > > people complained about missing objects and that their patches were > > broken with the new pd-extended. Note that I don't want to rate if > > they complained for a good reason, I just want to point to a problem. > > > >> pd-extended would provide a default object for every nameclash. > >> If you have old patches that were using objects, that are not the > >> default in pd-extended you would have to add a declare to your > >> patch. or > >> explicitely call them as mynondefaultlib/abs~. > > > > So you see: pd-extended selected a certain set of externals to be the > > default set of available objectclasses in pd-extended. I don't know > > how it was decided which libs should be these defaults, I don't even > > know which ones are the defaults. Probably Hans just chose some > > popular ones, which is a sensible thing to do. > > > > In the long run, this process should become a bit more organized and > > it especially should not be handled along library/author borders. For > > example, I think, zexy (rightfully) has a high loading priority, > > because it's one of the oldest and most widely used library. But > > Cyclone also deserves a high priority because it's generally > > Max-compatible. OTOH zexy is older. What to do? If we only priorize > > complete libraries, we're not able to make finely grained decisions > > about single objects. Maybe zexy's [abs~] is better, while [urn] in > > Cyclone is preferable. > > > > In the end we may be back at square one: a "flatspace" with the > > selected best of the (un)pack objectclasses in a single directory. No > > problems with path settings, all is fine again. > > > > Or what am I missing? ;) > > The flatspace model breaks down when you start adding libraries to Pd- > extended. Then you can have nameclashes again. Say someone writes > their own library with an [urn], then what happens? At best, > confusion ensues. > > If we look at other programming languages, we can see that namespaces > are a very common solution to this problem (C++, Tcl, python, Java, > Smalltalk, etc). I see no reason why it wouldn't work for Pd as well. > > .hc > > > ------------------------------------------------------------------------ > ---- > > There is no way to peace, peace is the way. -A.J. Muste > > > > > > _______________________________________________ > PD-list@iem.at mailing list > UNSUBSCRIBE and account-management -> > http://lists.puredata.info/listinfo/pd-list > _______________________________________________ PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list