Yes, Marius got exactly what I meant, this is how I usually make the
not-so-pluggable stuff pluggable :)
About the fact to release it out of zope.schema, it's also to be able
to make it live a bit and prove itself.
Then, including it and changing the API can be easily justified. I'm
not afraid of the changes in zope.schema.
z3c.form is not the only form option, I'll probably use it in
dolmen.forms that came from zeam.form.
So, whatever you decide, we'll try to make it easy for you to contribute.
It tends to get tooooo complicated to do anything in zope, lately :)

2012/1/26 Marius Gedminas <>:
> On Thu, Jan 26, 2012 at 04:02:54PM +0200, Jan-Carel Brand wrote:
>> On Wed, 2012-01-25 at 18:56 +0100, Souheil CHELFOUH wrote:
>> > A quick note :
>> >
>> > This quite an advanced vocabulary, why not make another package with a
>> > dependency on zope.schema ?
>> > I don't quite see the point to have that in the "core".
>> Ok, Charlie also expressed his reservations. I'll put it in a different
>> package then.
>> I'm not too sure what to name it though. For example, under what
>> namespace? zope or z3c?
> My gut feeling says "z3c".
> OTOH I don't think a single class warrants a whole separate PyPI
> package.  Especially if it's going to be used with z3c.form (hint, hint
> ;) or that collective.forgotthenamealready you mentioned upthread.
>> I'm guessing zope.vocabulary, or rather zope.treevocabulary?
> (Or z3c.treevocabulary)
> But I'd rather see this in zope.schema.
> Incidentally, since this would be a new feature, it would need a minor
> version bump in (4.0.2dev -> 4.1dev).
>> > Furthermore, for the dict class in use in the vocabulary, you could
>> > add a "factory" class that can be overriden easily.
>> > That would allow people with OrderDict capabilities to use them
>> > without having to re-sort later on.
>> Could you please elaborate on what you mean?
> I think he meant something like
>    class TreeVocabulary(object):
>        # you can subclass and use OrderedDictionary instead
>        dict_factory = dict
> This would mean that you can't subclass dict and would instead have to
> delegate __getitem__, __iter__, __len__, keys, values, items and all the
> rest by hand.
> I'm actually feeling a bit guilty about raising this question.  As I
> said, I don't have a use-case for ordered TreeVocabularies myself.  (Or
> unordered ones either, for that matter ;)  The only reason for hashing
> this out now is to avoid painful API changes if we ever decide that we
> need those.  Feel free to cry YAGNI at any time.  It's already hard
> enough to contribute to zope3-or-is-it-bluebream-or-is-it-ztk-aaaugh as
> it is, without us adding extra barriers in place.
>> If I create a factory class to create TreeVocabulary instances, how will
>> overriding that factory (without creating a separate
>> SortableTreeVocabulary) allow people to use OrderedDict?
>> Incidentally, I came upon this:
>> which provides the OrderedDict to Python 2.4 to 2.7
> Oh, neat.  I've used in the past, but
> it doesn't have the blessing of stdlib'ness.
>> I think it might make sense to just subclass OrderedDict and implement
>> an ordered tree from the start.
>> > By the way, good work on that, it's something that is often needed in
>> > advanced forms. I'll make sure to try it.
>> > Thank you for the effort.
>> Thanks! Much appreciated.
> Thanks!
> Marius Gedminas
> --
> -- Zope 3/BlueBream consulting and development
> _______________________________________________
> Zope-Dev maillist  -
> **  No cross posts or HTML encoding!  **
> (Related lists -
> )
Zope-Dev maillist  -
**  No cross posts or HTML encoding!  **
(Related lists - )

Reply via email to