Feedback on my python framework I'm building.

Discussion in 'Python' started by nbvfour@gmail.com, Oct 13, 2012.

  1. Guest

    http://giotto.readthedocs.org/en/latest/tutorial.html

    Can someone give me some feedback on what they think of this framework? I came up with the idea of this framework a few months ago. I gave a talk at alocal python user group regarding these ideas, but no one seemed to think I was onto anything special or useful.

    Basically its a framework that forces the developer(s) to strictly separatethe model from the view and controller. You can 'hook up' multiple controllers to a project. The model layer can be completely mocked out so front end designers don't have to bother setting up Postgres/rabbitmq/whatever.

    Does anyone have any throughts or feedback?
    , Oct 13, 2012
    #1
    1. Advertising

  2. On Fri, 12 Oct 2012 21:49:55 -0700 (PDT)
    wrote:

    > http://giotto.readthedocs.org/en/latest/tutorial.html
    >
    > Can someone give me some feedback on what they think of this framework? I came up with the idea of this framework a few months ago. I gave a talk at a local python user group regarding these ideas, but no one seemed to think I was onto anything special or useful.
    >
    > Basically its a framework that forces the developer(s) to strictly separate the model from the view and controller. You can 'hook up' multiple controllers to a project. The model layer can be completely mocked out so front end designers don't have to bother setting up Postgres/rabbitmq/whatever.
    >
    > Does anyone have any throughts or feedback?



    Docs are useless for developers with an quarter of imagination. :)

    --
    Etienne Robillard
    Green Tea Hackers Club
    Fine Software Carpentry For The Rest Of Us!
    http://gthc.org/
    Etienne Robillard, Oct 13, 2012
    #2
    1. Advertising

  3. On Sat, Oct 13, 2012 at 3:49 PM, <> wrote:
    > Basically its a framework that forces the developer(s) to strictly separate the model from the view and controller. You can 'hook up' multiple controllers to a project. The model layer can be completely mocked out so front end designers don't have to bother setting up Postgres/rabbitmq/whatever.


    I don't like frameworks that force too much. Actually, I guess that
    means I don't like frameworks at all, I like toolsets. Let the
    programmer decide what he wants to do.

    That said, though, there are times when a good framework can do 90% of
    your work for you. The trouble comes when you want to do something the
    author didn't think of - you might well end up either fighting against
    the system, or modifying the framework to suit your task (and that
    works only if you created it yourself). Thin frameworks are usually
    immune to this, but on the flip side, they're less likely to be doing
    most of your work for you.

    It's really easy to demo something and show how awesome it is. How
    easily can it be turned to a task it was never built for?

    ChrisA
    Chris Angelico, Oct 13, 2012
    #3
  4. On Sun, 14 Oct 2012 01:12:30 +1100
    Chris Angelico <> wrote:

    > On Sat, Oct 13, 2012 at 3:49 PM, <> wrote:
    > > Basically its a framework that forces the developer(s) to strictly separate the model from the view and controller. You can 'hook up' multiple controllers to a project. The model layer can be completely mocked out so front end designers don't have to bother setting up Postgres/rabbitmq/whatever.

    >
    > I don't like frameworks that force too much. Actually, I guess that
    > means I don't like frameworks at all, I like toolsets. Let the
    > programmer decide what he wants to do.
    >
    > That said, though, there are times when a good framework can do 90% of
    > your work for you. The trouble comes when you want to do something the
    > author didn't think of - you might well end up either fighting against
    > the system, or modifying the framework to suit your task (and that
    > works only if you created it yourself). Thin frameworks are usually
    > immune to this, but on the flip side, they're less likely to be doing
    > most of your work for you.
    >
    > It's really easy to demo something and show how awesome it is. How
    > easily can it be turned to a task it was never built for?


    Perhaps we deserve such lame/mediocre web frameworks after all, as Imagination is for those who
    deserve the freedom to use it properly.

    > ChrisA
    > --
    > http://mail.python.org/mailman/listinfo/python-list



    --
    Etienne Robillard
    Green Tea Hackers Club
    Fine Software Carpentry For The Rest Of Us!
    http://gthc.org/
    Etienne Robillard, Oct 13, 2012
    #4
  5. Guest

    On Saturday, October 13, 2012 10:13:22 AM UTC-4, Chris Angelico wrote:
    > On Sat, Oct 13, 2012 at 3:49 PM, <> wrote:
    >
    > > Basically its a framework that forces the developer(s) to strictly separate the model from the view and controller. You can 'hook up' multiple controllers to a project. The model layer can be completely mocked out so front end designers don't have to bother setting up Postgres/rabbitmq/whatever.

    >
    >
    >
    > I don't like frameworks that force too much. Actually, I guess that
    >
    > means I don't like frameworks at all, I like toolsets. Let the
    >
    > programmer decide what he wants to do.
    >
    >
    >
    > That said, though, there are times when a good framework can do 90% of
    >
    > your work for you. The trouble comes when you want to do something the
    >
    > author didn't think of - you might well end up either fighting against
    >
    > the system, or modifying the framework to suit your task (and that
    >
    > works only if you created it yourself). Thin frameworks are usually
    >
    > immune to this, but on the flip side, they're less likely to be doing
    >
    > most of your work for you.
    >
    >
    >
    > It's really easy to demo something and show how awesome it is. How
    >
    > easily can it be turned to a task it was never built for?
    >
    >
    >
    > ChrisA


    Do you have an example of a task that giotto can't handle that other frameworks can? One of my goals is to have this framework "turing complete" in the sense that everything that other frameworks can do, giotto should be ableto do. I think my controller -> input_middleware -> model -> cache -> view-> output_middleware pattern pretty much allows for anything. Throughout the development process, I've radically changed the API many times when it was discovered that a certain task would be very hard (for instance authentication)
    , Oct 13, 2012
    #5
  6. Guest

    On Saturday, October 13, 2012 10:13:22 AM UTC-4, Chris Angelico wrote:
    > On Sat, Oct 13, 2012 at 3:49 PM, <> wrote:
    >
    > > Basically its a framework that forces the developer(s) to strictly separate the model from the view and controller. You can 'hook up' multiple controllers to a project. The model layer can be completely mocked out so front end designers don't have to bother setting up Postgres/rabbitmq/whatever.

    >
    >
    >
    > I don't like frameworks that force too much. Actually, I guess that
    >
    > means I don't like frameworks at all, I like toolsets. Let the
    >
    > programmer decide what he wants to do.
    >
    >
    >
    > That said, though, there are times when a good framework can do 90% of
    >
    > your work for you. The trouble comes when you want to do something the
    >
    > author didn't think of - you might well end up either fighting against
    >
    > the system, or modifying the framework to suit your task (and that
    >
    > works only if you created it yourself). Thin frameworks are usually
    >
    > immune to this, but on the flip side, they're less likely to be doing
    >
    > most of your work for you.
    >
    >
    >
    > It's really easy to demo something and show how awesome it is. How
    >
    > easily can it be turned to a task it was never built for?
    >
    >
    >
    > ChrisA


    Do you have an example of a task that giotto can't handle that other frameworks can? One of my goals is to have this framework "turing complete" in the sense that everything that other frameworks can do, giotto should be ableto do. I think my controller -> input_middleware -> model -> cache -> view-> output_middleware pattern pretty much allows for anything. Throughout the development process, I've radically changed the API many times when it was discovered that a certain task would be very hard (for instance authentication)
    , Oct 13, 2012
    #6
  7. On Sat, 13 Oct 2012 08:57:47 -0700 (PDT)
    wrote:


    > Do you have an example of a task that giotto can't handle that other frameworks can? One of my goals is to have this framework "turing complete" in the sense that everything that other frameworks can do, giotto should be able to do. I think my controller -> input_middleware -> model -> cache -> view -> output_middleware pattern pretty much allows for anything. Throughout the development process, I've radically changed the API many times when it was discovered that a certain task would be very hard (for instance authentication)
    > --
    > http://mail.python.org/mailman/listinfo/python-list


    how about eliminating poverty and employment discrimination?

    Or can your script prevent childs to kill themselves on facebook?

    let me know!
    Etienne Robillard, Oct 13, 2012
    #7
  8. On Sun, Oct 14, 2012 at 2:57 AM, <> wrote:
    > Do you have an example of a task that giotto can't handle that other frameworks can? One of my goals is to have this framework "turing complete" in the sense that everything that other frameworks can do, giotto should be able to do. I think my controller -> input_middleware -> model -> cache -> view -> output_middleware pattern pretty much allows for anything.


    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:

    ../grind | tee grind.log | egrep '(2012|tps|@)'

    It'll show me, in real-time, the lines that are of interest to me, but
    it also writes the whole log to disk. But tee can be used in a quite
    different way:

    echo "Hello, world!" | sudo tee /some/file/owned/by/root

    Unix is full of utilities of this nature. They each do one thing and
    do it well, so when someone wants to use them in unusual ways, the
    tools perform as expected.

    On the contrary, Magic: The Gathering Online is designed for one
    purpose: human interaction. There are a number of bot accounts that
    function as shopkeepers, but their owners have to either use GUI level
    monitoring and automation facilities, or hack the existing client
    brutally. These people are trying to use an application in a way that
    it wasn't designed to do, and no matter how reasonable the goal is,
    the program just isn't built with toolchaining in mind.

    > Throughout the development process, I've radically changed the API many times when it was discovered that a certain task would be very hard (for instance authentication)


    This is, in my opinion, not a good thing. If you have to change your
    API radically to support something you just thought of, then something
    you still haven't thought of may require another radical API change.
    That's not too bad if it's a personal system that you don't share with
    anyone (though even then, you have to consider whether you'll be
    spending more time fiddling with the framework than actually getting
    stuff done), but is potentially disastrous in something you publish -
    you can't afford to break everyone else's code, which means that
    you'll be unable to support things you didn't think of.

    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.

    The easiest way to avoid making things very much harder is to have a
    way to ignore the framework - in the same way that most file
    compression formats have a way to mark data as having not been
    compressed (PKZip uses the term "Stored" rather than, eg, "Deflated").
    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. I haven't tested your
    specific case, but what I've seen happen in similar situations is a
    ridiculous set of "pass-through" methods or parameters, getting sent
    up the line and back down the line, carrying opaque information that
    really ought to have been manipulated at a different level in the
    chain. I can't show you demo code as I don't own copyright on it, but
    the git repository at work has, shall we say, a certain amount of
    TheDailyWTF-level code in it...

    But please don't take this post as _entirely_ doom and gloom. For a
    number of reasons, I do not want to start coding within your
    framework; but I would recommend that you DO (continue to) do so.
    You'll learn a lot about what you do and don't like, and that's a good
    thing. You'll quite possibly end up building something that saves you
    a heap of time, and that's also a good thing. And at very worst, it'll
    be an exploration. All programmers benefit from writing more code :)
    But so long as you keep it personal, you're free to change it around
    completely every time you need to. Keep that flexibility and you won't
    feel constrained.

    ChrisA
    Chris Angelico, Oct 13, 2012
    #8
  9. Guest

    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? The 'tee' unix utility and ctypes describes the way giotto goes about it business verywell. Traditional web frameworks (such as django and rails) are too much of a 'magic the gathering' for my taste, which is why I'm writing giotto.

    I'm really not looking for general "why I hate frameworks" criticism. I'm looking for specific criticism of the framework that I am writing.

    > This is, in my opinion, not a good thing. If you have to change your
    > API radically to support something you just thought of, then something
    > you still haven't thought of may require another radical API change.


    Not all api's get it right on the first shot. I'm more interested in getting it right, rather than patching together a bunch of random 'fixes' ala PHP..

    > 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


    You just described what Giotto is trying to do, since Giotto doesn't touch the model at all.

    > 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.
    , Oct 13, 2012
    #9
  10. Guest

    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? The 'tee' unix utility and ctypes describes the way giotto goes about it business verywell. Traditional web frameworks (such as django and rails) are too much of a 'magic the gathering' for my taste, which is why I'm writing giotto.

    I'm really not looking for general "why I hate frameworks" criticism. I'm looking for specific criticism of the framework that I am writing.

    > This is, in my opinion, not a good thing. If you have to change your
    > API radically to support something you just thought of, then something
    > you still haven't thought of may require another radical API change.


    Not all api's get it right on the first shot. I'm more interested in getting it right, rather than patching together a bunch of random 'fixes' ala PHP..

    > 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


    You just described what Giotto is trying to do, since Giotto doesn't touch the model at all.

    > 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.
    , Oct 13, 2012
    #10
  11. On Sun, Oct 14, 2012 at 5:18 AM, <> 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
    Chris Angelico, Oct 13, 2012
    #11
  12. Guest

    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.
    , Oct 13, 2012
    #12
  13. Guest

    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.
    , Oct 13, 2012
    #13
  14. On Sun, Oct 14, 2012 at 9:24 AM, <> 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
    Chris Angelico, Oct 14, 2012
    #14
  15. On 13 October 2012 17:48, Chris Angelico <> 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.
    Oscar Benjamin, Oct 14, 2012
    #15
  16. 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
    Steven D'Aprano, Oct 14, 2012
    #16
  17. Tim Chase Guest

    Re: one obvious parser (was "Feedback on my python framework I'mbuilding.")

    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/
    Tim Chase, Oct 14, 2012
    #17
  18. MRAB Guest

    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".
    MRAB, Oct 14, 2012
    #18
  19. 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-is-not-python-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
    Steven D'Aprano, Oct 14, 2012
    #19
  20. On Sun, Oct 14, 2012 at 2:37 PM, Steven D'Aprano
    <> 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
    Chris Angelico, Oct 14, 2012
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?a2F0ZQ==?=
    Replies:
    0
    Views:
    441
    =?Utf-8?B?a2F0ZQ==?=
    Aug 25, 2005
  2. Lucas Tam

    Building an Extensible Web Framework

    Lucas Tam, Oct 12, 2005, in forum: ASP .Net
    Replies:
    2
    Views:
    363
    Lucas Tam
    Oct 13, 2005
  3. Ajay
    Replies:
    1
    Views:
    438
    =?Utf-8?B?UGV0ZXIgQnJvbWJlcmcgW0MjIE1WUF0=?=
    Jan 8, 2006
  4. Midex
    Replies:
    24
    Views:
    874
  5. Bruno Desthuilliers
    Replies:
    24
    Views:
    4,020
    Bruno Desthuilliers
    Oct 20, 2008
Loading...

Share This Page