We need PIGs :)

[Martin Marcher]

Hello,

On 30 Aug 2007 07:14:25 GMT, Marc 'BlackJack' Rintsch <bj_666 at gmx.net> 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