Hello, On 30 Aug 2007 07:14:25 GMT, Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> wrote: > On Thu, 30 Aug 2007 07:10:47 +0200, Martin Marcher wrote: > > > Does that sound like a good idea or would that be over formalization? > > Sounds like over engineering/formalization to me. > You are aware of the Python Enhancement Proposals (PEPs)?
Yes I am thought I mentioned the wsgi pep in the mail... > Is something like the `Python Database API Specification v2.0`_ or `API > for Block Encryption Algorithms v1.0`_ what you are looking for? http://en.wikipedia.org/wiki/Java_Authentication_and_Authorization_Service http://en.wikipedia.org/wiki/Content_repository_API_for_Java http://jcp.org/en/jsr/all But since python is much more open in these terms these hints should guide developers thru solutions so that they know they can use other modules/classes without any effort if such a specificaton exists. In Java it is more like not implementing any of these things is > > .. _API for Block Encryption Algorithms v1.0: > http://www.python.org/dev/peps/pep-0272/ > .. _Python Database API Specification v2.0: > http://www.python.org/dev/peps/pep-0249/ Indeed i wasn't aware of these (I know the wsgi spec) but I was more thinking about guidelines where you can be quite sure that because of not being able to provide an implementation that is so general that it could be incorporated in the standard library. Think of * object relational mappers (probably a bad example - but would be still nice) * service registries * service repositories * .... that use the same interface so that you can swap them effordlessly. I'm thinking big here so that generalization has to be applied to the problems but also that you can keep to well known interface to implement so that it will work out for the majority of situations in these fields. I do know the WSGI spec but I do think that (otherwise I wouldn't have had the idea) that PEPs are the wrong place for that. To me PEPs are (better should be) about the plain stock standard library and how to work with it (coding guidelines, docstring, iterators, generators - specification of the language) PIGs (given the name is arguable - I just like it it removes a bit of the necessary formal taste it has) should define: * problem * solution * expected behaviour * interface (probably even prepare unit tests if the interface is stabilized) but should by itself not implement anything as for example the DBAPI does. and given the nature of the field (spezialized for a task but still applies to a lot of people) an general purpose implementation wouldn't be useful hope that explains it well enough. I've been in a couple of projects where problems where common to all those projects but the specification made up by individual (project) managers made it impossible to reuse parts of other apps (and I guess with some "official" backup one could point back on proven recipies - that's probably the term that describes it best) greetings (always wondered is that a formal or informal closing part in english letters?) martin -- http://mail.python.org/mailman/listinfo/python-list