Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Feedback on my python framework I'm building.

Reply
Thread Tools

Feedback on my python framework I'm building.

 
 
Chris Angelico
Guest
Posts: n/a
 
      10-13-2012
On Sun, Oct 14, 2012 at 5:18 AM, <(E-Mail Removed)> wrote:
> On Saturday, October 13, 2012 12:48:23 PM UTC-4, Chris Angelico wrote:
>> No, I don't, because I haven't tried to use it. But allow me to give
>> two examples, one on each side of the argument.
>>
>> The 'tee' utility is primarily for writing a pipe to disk AND to
>> further pipelining, for instance:

>
> Could you please spent 10 minutes to read through the tutorial?


A fair criticism, and I am duly chastised. Okay. Now reading through
your web site... alright, I'm back.

>> This is why I say it's likely not a good thing that your framework
>> *forces* the separation of model/view/controller. You make it
>> impossible to temporarily ignore the framework.

>
> Exactly. When you 'break out of the framework' you pile on technical debt.. I want to force developers to not do that.


Philosophy point 2: Giotto does force users to do things the “Giotto
way”. In other words, convention over configuration

Nice theory, but this is the bit that I fundamentally disagree with.
Forcing programmers to work in one particular style is usually not the
job of the language/framework/library. That should be up to the
programmer, or at least the local style guide. I do like your plan of
having identical interfaces to the same functionality (your example of
web-based and command-line is particularly appealing to my personal
tastes), but the same can usually be achieved with a well-built
library. In fact, all you need to do is have your model as a simple
Python module, and then the view and controller call on its functions.

What does your framework offer over a basic system like that?

ChrisA
 
Reply With Quote
 
 
 
 
nbvfour@gmail.com
Guest
Posts: n/a
 
      10-13-2012
On Saturday, October 13, 2012 2:33:43 PM UTC-4, Chris Angelico wrote:
>
> Nice theory, but this is the bit that I fundamentally disagree with.
> Forcing programmers to work in one particular style is usually not the
> job of the language/framework/library. That should be up to the
> programmer, or at least the local style guide.


Have you ever read the zen of python? "Theres only one way to do it" is a core motto of the python language. In my opinion, this is the most importantaspect of python and is what makes python so much better than PHP and perland all the other "do it however you want, the more convoluted and obfuscated the better!" languages.

> I do like your plan of
> having identical interfaces to the same functionality (your example of
> web-based and command-line is particularly appealing to my personal
> tastes), but the same can usually be achieved with a well-built
> library. In fact, all you need to do is have your model as a simple
> Python module, and then the view and controller call on its functions.
>
> What does your framework offer over a basic system like that?


This "well built library" you mention basically describes my framework. Youwrite a model method/function that takes data and then returns data. All giotto does is extract that data from the controller, pass it on to the model, then take the output of the model and pass it in to the view. You write the view, you write the model. Giotto provides the API for making al this happen. Giotto doesn't care if your model calls Postgres or Mysql or Redis or RabbitMQ, thats not of any concern to the framework.

The advantage of this is that the framework can 'mock' out the model layer very easily. For instance, your front end designers can work on the HTML without needing to run postgres, and the backend developers can work on the backend through the command line.
 
Reply With Quote
 
 
 
 
nbvfour@gmail.com
Guest
Posts: n/a
 
      10-13-2012
On Saturday, October 13, 2012 2:33:43 PM UTC-4, Chris Angelico wrote:
>
> Nice theory, but this is the bit that I fundamentally disagree with.
> Forcing programmers to work in one particular style is usually not the
> job of the language/framework/library. That should be up to the
> programmer, or at least the local style guide.


Have you ever read the zen of python? "Theres only one way to do it" is a core motto of the python language. In my opinion, this is the most importantaspect of python and is what makes python so much better than PHP and perland all the other "do it however you want, the more convoluted and obfuscated the better!" languages.

> I do like your plan of
> having identical interfaces to the same functionality (your example of
> web-based and command-line is particularly appealing to my personal
> tastes), but the same can usually be achieved with a well-built
> library. In fact, all you need to do is have your model as a simple
> Python module, and then the view and controller call on its functions.
>
> What does your framework offer over a basic system like that?


This "well built library" you mention basically describes my framework. Youwrite a model method/function that takes data and then returns data. All giotto does is extract that data from the controller, pass it on to the model, then take the output of the model and pass it in to the view. You write the view, you write the model. Giotto provides the API for making al this happen. Giotto doesn't care if your model calls Postgres or Mysql or Redis or RabbitMQ, thats not of any concern to the framework.

The advantage of this is that the framework can 'mock' out the model layer very easily. For instance, your front end designers can work on the HTML without needing to run postgres, and the backend developers can work on the backend through the command line.
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      10-13-2012
On Sun, Oct 14, 2012 at 9:24 AM, <(E-Mail Removed)> wrote:
> On Saturday, October 13, 2012 2:33:43 PM UTC-4, Chris Angelico wrote:
>>
>> Nice theory, but this is the bit that I fundamentally disagree with.
>> Forcing programmers to work in one particular style is usually not the
>> job of the language/framework/library. That should be up to the
>> programmer, or at least the local style guide.

>
> Have you ever read the zen of python? "Theres only one way to do it" is acore motto of the python language. In my opinion, this is the most important aspect of python and is what makes python so much better than PHP and perl and all the other "do it however you want, the more convoluted and obfuscated the better!" languages.


Many times, but 'import this' doesn't translate into a language rule
that all classes have an uppercase first letter and all non-classes
don't; nor does it require that it be impossible to combine two simple
statements onto one line (because it's equally "obvious" to put them
onto two lines). Some things are questions of style, and are and
should be both implemented.

ChrisA
 
Reply With Quote
 
Oscar Benjamin
Guest
Posts: n/a
 
      10-14-2012
On 13 October 2012 17:48, Chris Angelico <(E-Mail Removed)> wrote:
>
> The only way to support *absolutely everything* is to do nothing - to
> be a framework so thin you're invisible. (That's not to say you're
> useless; there are bridge modules that do exactly this - ctypes can
> call on any library function from Python; it must therefore abstract
> away nothing. But that's a very specific sort of case.) Anything else
> must by nature make some things easier and some things harder.


Without further ado I announce the release of my new library that
simultaneously does everything and nothing. It can be installed with:

pip install ''

That's right: the library's name is the empty string (as it's source
and documentation). Don't be fooled by the error message from pip: the
library was correctly installed before you ran the command!

Other libraries have failed by imposing restrictions on usage in an
attempt to better serve a mere finite number of use cases. This
library is *equally optimal* for an uncountably infinite number of
purposes and comes with the strong guarantee that it will never
decrease your productivity in any situation whatsoever!


Oscar

P.S. I also have not taken 10 minutes to read the documentation for
giotto as I get the impression that is not relevant to any of my own
use cases.
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      10-14-2012
On Sat, 13 Oct 2012 15:24:04 -0700, nbvfour wrote:

> On Saturday, October 13, 2012 2:33:43 PM UTC-4, Chris Angelico wrote:
>>
>> Nice theory, but this is the bit that I fundamentally disagree with.
>> Forcing programmers to work in one particular style is usually not the
>> job of the language/framework/library. That should be up to the
>> programmer, or at least the local style guide.

>
> Have you ever read the zen of python? "Theres only one way to do it" is
> a core motto of the python language.


Have *you* ever read the Zen of Python? The line from the Zen is:

"There should be one-- and preferably only one --obvious way to do it."

Paraphrasing for emphasis:

There SHOULD be one (or more, but one is best) OBVIOUS way to do it.

as opposed to languages where there are no obvious ways to things, or
thirty.

Don't believe me that the emphasis is on *obvious* rather than "only"?
The very next line of the Zen tells you:

"Although that way may not be OBVIOUS at first unless you're Dutch."

[emphasis added]

Not being Dutch, I don't know whether the obvious way to do command line
argument handling is the getopt module or argparse. But there certainly
isn't *only one way* to do command line argument handling.

It is a gross canard, mostly spread by Perl programmers, that Python is
"limited" to "only one way to do it" and therefore isn't as good as Perl
which gives you "more freedom" (to write unreadable, unmaintainable code).

It simply isn't true that Python only gives you "only one way". The
acronym OOWTDI stands for *one obvious way to do it*.


--
Steven
 
Reply With Quote
 
Tim Chase
Guest
Posts: n/a
 
      10-14-2012
On 10/13/12 21:25, Steven D'Aprano wrote:
> Not being Dutch, I don't know whether the obvious way to do command line
> argument handling is the getopt module or argparse. But there certainly
> isn't *only one way* to do command line argument handling.


As an aside, I just watched a fascinating video[1] on docopt[2]
which seems like an amazingly simple way to build command-line UIs.
I haven't toyed with it yet, but I just wanted to share my "wow,
that's slick" experience with the list.

-tkc


[1]
http://www.youtube.com/watch?v=pXhcPJK5cMc

[2]
http://docopt.org/





 
Reply With Quote
 
MRAB
Guest
Posts: n/a
 
      10-14-2012
On 2012-10-14 03:25, Steven D'Aprano wrote:
> On Sat, 13 Oct 2012 15:24:04 -0700, nbvfour wrote:
>
>> On Saturday, October 13, 2012 2:33:43 PM UTC-4, Chris Angelico wrote:
>>>
>>> Nice theory, but this is the bit that I fundamentally disagree with.
>>> Forcing programmers to work in one particular style is usually not the
>>> job of the language/framework/library. That should be up to the
>>> programmer, or at least the local style guide.

>>
>> Have you ever read the zen of python? "Theres only one way to do it" is
>> a core motto of the python language.

>
> Have *you* ever read the Zen of Python? The line from the Zen is:
>
> "There should be one-- and preferably only one --obvious way to do it."
>
> Paraphrasing for emphasis:
>
> There SHOULD be one (or more, but one is best) OBVIOUS way to do it.
>
> as opposed to languages where there are no obvious ways to things, or
> thirty.
>
> Don't believe me that the emphasis is on *obvious* rather than "only"?
> The very next line of the Zen tells you:
>
> "Although that way may not be OBVIOUS at first unless you're Dutch."
>
> [emphasis added]
>
> Not being Dutch, I don't know whether the obvious way to do command line
> argument handling is the getopt module or argparse. But there certainly
> isn't *only one way* to do command line argument handling.
>
> It is a gross canard, mostly spread by Perl programmers, that Python is
> "limited" to "only one way to do it" and therefore isn't as good as Perl
> which gives you "more freedom" (to write unreadable, unmaintainable code).
>
> It simply isn't true that Python only gives you "only one way". The
> acronym OOWTDI stands for *one obvious way to do it*.
>

I think it's the "Paradox of Choice".

The more choices there are, the more time you'll spend trying to decide
which one is "best".

 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      10-14-2012
On Sun, 14 Oct 2012 05:33:40 +1100, Chris Angelico wrote:

> Forcing programmers to work in one particular style is usually not the
> job of the language/framework/library.


Have you actually programmed before?

*grin*

I've never come across a language/framework/library that DOESN'T force
programmers to work in a particular style, at least to some degree.

Every language encourages certain styles, discourages others, and makes
some impossible. Remember using PEEK and POKE commands with BASIC back in
1978? Pretty much impossible in Python. Perl probably has a way to do it
*wink* but few others do, and thank goodness we've moved on.

The sort of code you'll write in Fortran77 will be significantly
different from that you'll write in Lisp or Java or Forth or Ocaml.
Languages don't just differ in syntax, they differ in what they consider
good idioms, or even *possible* idioms. Hence:

http://dirtsimple.org/2004/12/python-is-not-java.html
http://dirtsimple.org/2004/12/java-i...on-either.html

Can you write "Java in Python"? Well, to some degree you can. Any Turing
complete language can be written in any other Turing complete language,
with sufficient layers of indirection, modulo things which are completely
impossible. You simply cannot do C-style pointer manipulations in Python,
not without breaking out of Python (e.g. with ctypes).

Libraries and frameworks are in a similar boat. Can you write CherryPy in
Django? Not easily. Generally the way to ignore a framework or library
and write in a different style is to, well, ignore the framework or
library and write in a different style

You can always step outside the bounds of the framework or library and
write something in the programming language level. Just because numpy
doesn't have some function I want, doesn't mean that I can't write it in
Python -- and just because numpy wants to work with arrays doesn't mean I
can't insist in using XML for my data, provided I convert it into an
array each time I pass it to a numpy function and back to XML when it
returns.

(For my next trick, watch as I eat three pounds of high-level radioactive
waste!)

Now clearly some frameworks are lighter than others, some impose their
style on your code like a big heavy weight on a rubber sheet, distorting
everything for miles around. Others not so much. But I really don't see
the problem here: if you don't like the "Twisted style" that it imposes,
don't use Twisted, use another framework, or no framework at all.

I think it is a *good* thing that different languages/frameworks/
libraries have their own styles. The alternative isn't "many styles" but
"one style": an unstylish mess.



--
Steven
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      10-14-2012
On Sun, Oct 14, 2012 at 2:37 PM, Steven D'Aprano
<(E-Mail Removed)> wrote:
> On Sun, 14 Oct 2012 05:33:40 +1100, Chris Angelico wrote:
>
>> Forcing programmers to work in one particular style is usually not the
>> job of the language/framework/library.

>
> Have you actually programmed before?
>
> *grin*
>
> I've never come across a language/framework/library that DOESN'T force
> programmers to work in a particular style, at least to some degree.


Style and technique aren't quite the same thing, though. Where you
draw the line between aspects the language should enforce and aspects
that should be up to the programmer is a tricky question. A language's
standard library certainly encourages a particular naming style, but
nothing enforces it.

Of course the language has to enforce something. I just don't think
that the MVC model should be part of what's enforced. What next?
Require that one file be one class and have nothing else in it?

ChrisA
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Feedback from feedback on MCP questions Matt Adamson Microsoft Certification 0 04-27-2009 11:13 AM
Emacs users: feedback on diffs between python-mode.el and python.el? Bruno Desthuilliers Python 24 10-20-2008 08:02 AM
Installing 1.1 Framework and 2.0 Framework on the same web server Mark ASP .Net 4 11-17-2005 03:30 PM
microsoft.public.dotnet.faqs,microsoft.public.dotnet.framework,microsoft.public.dotnet.framework.windowsforms,microsoft.public.dotnet.general,microsoft.public.dotnet.languages.vb Charles A. Lackman ASP .Net 1 12-08-2004 07:08 PM
COMInterop does not work in Framework 1.1 without Framework 1.0 Anatoly Volodko ASP .Net 1 08-14-2003 08:11 PM



Advertisments