[PD] pd extended development
hans at eds.org
Thu Apr 17 01:48:23 CEST 2008
On Apr 16, 2008, at 6:27 PM, Luke Iannini (pd) wrote:
> 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]). 
> "from list-abs import list-map", makes it possible to just type
> 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.
Those sound reasonable, but a lot more work to implement. For the
next release, there should be
- [list-abs/list-split] (like python without needed the "import list-
abs" statement). I am not sure I see the reason to have to import a
lib in order to use it with the lib prefix.
- [import list-abs] which is the same as "from list-abs import *",
for better or worse. It's what Pd people are used to, so...
- I think it should be possible to do [import list-abs/list-split]
but I haven't looked at it too much yet.
> 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
This sounds like a write-only feature, it makes the code much harder
for others to read. If you don't recognize a library name, then you
have to check both whether it is an alias, and if it is a library.
From what I have seen, aliases cause more harm than good in
> 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:
>>> marius schebella hat gesagt: // marius schebella wrote:
>>>> Frank Barknecht wrote:
>>>>> 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
>>>>> is, when two objects have the same name registered in Pd but act
>>>>> differently. Folders are a way to organize files in a filesystem
>>>>>> 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
>>> 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
>>> 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
>>>> 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
>>> 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
>> 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
>> 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/
You can't steal a gift. Bird gave the world his music, and if you can
hear it, you can have it. - Dizzy Gillespie
More information about the Pd-list