Re: We need PIGs :)
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: We need PIGs :)
On 9/16/07, Colin J. Williams <[EMAIL PROTECTED]> wrote: > > Marc 'BlackJack' Rintsch wrote: > > On Thu, 06 Sep 2007 09:00:02 +0200, Stefan Arentz wrote: > > > >> What I find really frustrating in Python (combined with usually bad > >> documentation) is that many people have different styles. The most > >> frustratinng being getFoo() vs .foo, vs get_foo(). > > > > `getFoo()` is discouraged by PEP 8. You don't have the choice between > > `.foo` and `.get_foo()` in Java because Java has no properties and > people > > are trained to write getters and setters for everything. I like that > > choice in Python because I can write shorter code that is not cluttered > > with very simple getters and setters. > > > > Ciao, > > Marc 'BlackJack' Rintsch > Perhaps PEP 8 needs rethinking. I prefer getFoo(). > Similarly, I feel that the standard indent of 4 increases the > likelihood of running off the end of a line. An indent of 1 isn't > quite clear visually, but 2 is. The point with a style guide is not to cater for everyones preferences, but to set a common compromise. If you find yourself going off the right margin a lot, perhaps you should consider restructuring and refactoring your application, rather than reducing your indentation. Colin W. > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://mail.python.org/mailman/listinfo/python-list
Re: We need PIGs :)
Marc 'BlackJack' Rintsch wrote: > On Thu, 06 Sep 2007 09:00:02 +0200, Stefan Arentz wrote: > >> What I find really frustrating in Python (combined with usually bad >> documentation) is that many people have different styles. The most >> frustratinng being getFoo() vs .foo, vs get_foo(). > > `getFoo()` is discouraged by PEP 8. You don't have the choice between > `.foo` and `.get_foo()` in Java because Java has no properties and people > are trained to write getters and setters for everything. I like that > choice in Python because I can write shorter code that is not cluttered > with very simple getters and setters. > > Ciao, > Marc 'BlackJack' Rintsch Perhaps PEP 8 needs rethinking. I prefer getFoo(). Similarly, I feel that the standard indent of 4 increases the likelihood of running off the end of a line. An indent of 1 isn't quite clear visually, but 2 is. Colin W. -- http://mail.python.org/mailman/listinfo/python-list
Re: We need PIGs :)
Stefan Arentz a écrit : > Bruno Desthuilliers <[EMAIL PROTECTED]> writes: > > ... > >> 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. -- http://mail.python.org/mailman/listinfo/python-list
Re: We need PIGs :)
Marc 'BlackJack' Rintsch <[EMAIL PROTECTED]> writes: > On Thu, 06 Sep 2007 09:00:02 +0200, Stefan Arentz wrote: > > > What I find really frustrating in Python (combined with usually bad > > documentation) is that many people have different styles. The most > > frustratinng being getFoo() vs .foo, vs get_foo(). > > `getFoo()` is discouraged by PEP 8. You don't have the choice between > `.foo` and `.get_foo()` in Java because Java has no properties and people > are trained to write getters and setters for everything. I like that > choice in Python because I can write shorter code that is not cluttered > with very simple getters and setters. I like that too, but unfortunately not everybody is doing it. Unpredictable code (apis) is in my opinion the biggest productivity killer. S. -- http://mail.python.org/mailman/listinfo/python-list
Re: We need PIGs :)
On Thu, 06 Sep 2007 09:00:02 +0200, Stefan Arentz wrote: > What I find really frustrating in Python (combined with usually bad > documentation) is that many people have different styles. The most > frustratinng being getFoo() vs .foo, vs get_foo(). `getFoo()` is discouraged by PEP 8. You don't have the choice between `.foo` and `.get_foo()` in Java because Java has no properties and people are trained to write getters and setters for everything. I like that choice in Python because I can write shorter code that is not cluttered with very simple getters and setters. Ciao, Marc 'BlackJack' Rintsch -- http://mail.python.org/mailman/listinfo/python-list
Re: We need PIGs :)
Bruno Desthuilliers <[EMAIL PROTECTED]> writes: ... > 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. Java has pretty strict rules for style and API design, which basically all modern code follows pretty well. I think this is mostly the result of a strict JSR regime. What I find really frustrating in Python (combined with usually bad documentation) is that many people have different styles. The most frustratinng being getFoo() vs .foo, vs get_foo(). S. -- http://mail.python.org/mailman/listinfo/python-list
Re: We need PIGs :)
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/viewpost.jsp?thread=155123 HTH -- http://mail.python.org/mailman/listinfo/python-list
Re: We need PIGs :)
On Aug 30, 12:10 am, "Martin Marcher" <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: We need PIGs :)
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
Re: We need PIGs :)
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: We need PIGs :)
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 -- http://mail.python.org/mailman/listinfo/python-list
