We need PIGs :)

[Martin Marcher]

Hello,

having worked quite a bit with python in the last months (some Java
before, and some C++ before that) I was very impressed by an idea the
Java people had.

Explanation: the JSRs define how to implement certain services and or
features in Java so that they can be reused. I haven't found such a
thing for python yet.

Say I have the problem of authentication. Now I can implement
authentication against a text file with a "key : value" format.

However someone may find it more suitable to implement a
authentication backend for exactly this app that can use postgres.

Who else can use the authentication for my program created by a third
party in his or her own app/package/module? To my knowledge noone as
there's nothing you could at least theoretically keep to.

My idea was to define "Python Implementation Guidelines" (PIGs) that
specify a problem formalize it enough so that implementations are
interchangeable (in this example create a module that has an
"authenticate(username, password)" method so that one could easily
take that module for any given app and then authenticate against
postgres, and also against my plaintext file (which was the original -
quite useless - implementation).

Does that sound like a good idea or would that be over formalization?

Personally I think that would be great as I could search the PIGs at
(hopefully) python.org find out the number and search at koders.com or
code.google.com for python code that has "PIG: XXX" in the metadata
docstring or wherever - maybe even a __pig__ = XXX variable.

any input is welcome (also point me to the place where that can be
found if it already exists)
martin

[Marc 'BlackJack' Rintsch]

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)?

Is something like the `Python Database API Specification v2.0`_ or `API
for Block Encryption Algorithms v1.0`_ what you are looking for?

... _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/

Ciao,
Marc 'BlackJack' Rintsch

[Carl Banks]

On Thu, 30 Aug 2007 07:10:47 +0200, Martin Marcher wrote:

My idea was to define "Python Implementation Guidelines" (PIGs) that
specify a problem formalize it enough so that implementations are
interchangeable (in this example create a module that has an
"authenticate(username, password)" method so that one could easily take
that module for any given app and then authenticate against postgres,
and also against my plaintext file (which was the original - quite
useless - implementation).

Does that sound like a good idea or would that be over formalization?

The Python community already did something for web applications (WSGI, I
think). Not sure how well that's working out.

Doing this kind of thing is not, of course, something that can be done in
general for all problems. It would only help if there's enough demand
for interoperability that developers make the effort to adhere to the
guidelines (which are rarely ideal for any particular situation).
Although there are some informal standards that Python programmers often
observe (for example, the interface of file-like objects), there isn't
too much demand to standardize them.

I believe the Python language itself makes formal guidelines less
helpful, because its dynamicism (among other things) makes is so good at
interfacing. That is, if you have two pieces of code that don't work
together, it's easy to connect them. Many people often call Python a
good "glue" language for this reason. And when you have a good "glue"
language, formal interface guidelines aren't so important.

Carl Banks

[Martin Marcher]

Hello,

On 30 Aug 2007 07:14:25 GMT, Marc 'BlackJack' Rintsch <bj****@gmx.netwrote:

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_Au...zation_Service
http://en.wikipedia.org/wiki/Content...y_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

[programmer.py]

On Aug 30, 12:10 am, "Martin Marcher" <[e-mail]>
wrote:

[snip!]

>
My idea was to define "Python Implementation Guidelines" (PIGs) that
specify a problem formalize it enough so that implementations are
interchangeable (in this example create a module that has an
"authenticate(username, password)" method so that one could easily
take that module for any given app and then authenticate against
postgres, and also against my plaintext file (which was the original -
quite useless - implementation).

Does that sound like a good idea or would that be over formalization?

This may be over-formalization. For specific problems, there
generally is a pythonic choice. For instance, suppose your problem is
'I need an ORM' - well the pythonic choice is something along the
lines of SQLObject or SQLAlchemy.

Then there are other cases where there are too many choices - "I need
a web framework." -- turbogears, django, pylons, and whatever else you
want to throw into the pot. (Be smart, choose pylons [just kidding,
but I did promote pylons and attach a just kidding disclaimer --
clever, huh?])

Personally I think that would be great as I could search the PIGs at
(hopefully) python.org find out the number and search at koders.com or
code.google.com for python code that has "PIG: XXX" in the metadata
docstring or wherever - maybe even a __pig__ = XXX variable.

I think most of what you're after may be in the python cookbook
(http://aspn.activestate.com/ASPN/Cookbook/Python) or the PyPi (http://
pypi.python.org/pypi).

any input is welcome (also point me to the place where that can be
found if it already exists)
martin

Or maybe I completely misunderstand what you mean.

G' Day!
jw

[Bruno Desthuilliers]

Martin Marcher a écrit :

Hello,

having worked quite a bit with python in the last months (some Java
before, and some C++ before that) I was very impressed by an idea the
Java people had.

Explanation: the JSRs define how to implement certain services and or
features in Java so that they can be reused. I haven't found such a
thing for python yet.

(snip)

My idea was to define "Python Implementation Guidelines" (PIGs) that
specify a problem formalize it enough so that implementations are
interchangeable (in this example create a module that has an
"authenticate(username, password)" method so that one could easily
take that module for any given app and then authenticate against
postgres, and also against my plaintext file (which was the original -
quite useless - implementation).

Does that sound like a good idea or would that be over formalization?

The problem with Java is that it makes it very painfull to bridge two
APIs together, while Python usually makes it a breeze (easy delegation,
no dumb-ass psycho-rigid type system). So Java's solution
(hyper-formalization) isn't necessary here.

Now there's something along this line - just much more useful and
flexible IMHO - in Zope3 and Twisted. You may want to look at Zope's
"Interfaces" for more infos on this, or to read this post by the BDFL:
http://www.artima.com/weblogs/viewpo...?thread=155123

HTH

[Bruno Desthuilliers]

Stefan Arentz a écrit :

Bruno Desthuilliers <bd*****************@free.quelquepart.frwrites:

...

>The problem with Java is that it makes it very painfull to bridge two
APIs together, while Python usually makes it a breeze (easy
delegation, no dumb-ass psycho-rigid type system). So Java's solution
(hyper-formalization) isn't necessary here.

Interesting. I find Java much more predictable with APIs than Python
actually.

I'm not going to debate on this because it's absolutely not what I'm
talking about. My point is that Python has:

- duck typing, so you don't need one class subclassing another just to
satisfy the compiler - as long as the object you send respects the
expected protocol, everything's ok

- good support for delegation (via the __getattr__/__setattr__ magic
methods), so you don't have to go thru the pain of hand-writing all the
delegate methods - only the ones for which there's more to be done than
straightforward delegation.

Java has pretty strict rules for style and API design,

Java has pretty strict rules for almost anything.

[Marc 'BlackJack' Rintsch]

On Sun, 16 Sep 2007 10:17:18 -0400, Colin J. Williams wrote:

Marc 'BlackJack' Rintsch wrote:

>`getFoo()` is discouraged by PEP 8. […]

Perhaps PEP 8 needs rethinking. I prefer getFoo().

Yeah, *your* preference is a very good reason to rethink PEPÂ*8… ;-)

Ciao,
Marc 'BlackJack' Rintsch