[PD] pd extended development

Luke Iannini (pd) lukexipd at gmail.com
Thu Apr 17 00:27:35 CEST 2008

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


On Wed, Apr 16, 2008 at 2:55 PM, Hans-Christoph Steiner <hans at eds.org> 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 at iem.at mailing list
>  UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

More information about the Pd-list mailing list