Python's annoyance.

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • caroundw5h

    #1

    Python's annoyance.

    Code:
    PEP 292 adds a Template class to the string module that uses "$" to
    indicate a substitution. Template is a subclass of the built-in
    Unicode type, so the result is always a Unicode string:
    [color=blue][color=green][color=darkred]
    >>> import string
    >>> t = string.Template('$page: $title')
    >>> t.substitute({'page':2, 'title': 'The Best of Times'})[/color][/color][/color]
    u'2: The Best of Times'
    
    If a key is missing from the dictionary, the substitute method will
    raise a KeyError. There's also a safe_substitute method that ignores
    missing keys:
    [color=blue][color=green][color=darkred]
    >>> t = string.SafeTemplate('$page: $title')
    >>> t.safe_substitute({'page':3})[/color][/color][/color]
    u'3: $title'

    Code:
    As a slightly more realistic example, the following decorator
    checks that the supplied argument is an integer:
    
    def require_int (func):
    def wrapper (arg):
    assert isinstance(arg, int)
    return func(arg)
    
    return wrapper
    
    @require_int
    def p1 (arg):
    print arg
    
    @require_int
    def p2(arg):
    print arg*2


    Serioulsy, one of python's main selling points is its elegant syntax,
    non perl like, non C like. If it can't live up to it. I guess i might
    as well use perl or ruby or server side javascript.

    how annoying.
  • Steven Bethard

    #2
    Re: Python's annoyance.

    caroundw5h wrote:[color=blue]
    > Serioulsy, one of python's main selling points is its elegant syntax,
    > non perl like, non C like. If it can't live up to it. I guess i might
    > as well use perl or ruby or server side javascript.[/color]

    While I'm not a fan of the decorator syntax or the $syntax in
    string.Template , you're not forced to use either of these:

    Standard Python formatting vs string.Template formatting:
    ------------------------------------------------------------[color=blue][color=green][color=darkred]
    >>> string.Template ('$page: $title').substi tute(dict(page= 2, title='The[/color][/color][/color]
    Best of Times'))
    '2: The Best of Times'[color=blue][color=green][color=darkred]
    >>> '%(page)s: %(title)s' % dict(page=2, title='The Best of Times')[/color][/color][/color]
    '2: The Best of Times'

    Post-function syntax vs. decorator syntax:
    ------------------------------------------------------------[color=blue][color=green][color=darkred]
    >>> def require_int(fun c):[/color][/color][/color]
    .... def wrapper(arg):
    .... assert isinstance(arg, int)
    .... return func(arg)
    .... return wrapper
    ....[color=blue][color=green][color=darkred]
    >>> @require_int[/color][/color][/color]
    .... def p1(arg):
    .... print arg
    ....[color=blue][color=green][color=darkred]
    >>> def p2(arg):[/color][/color][/color]
    .... print arg
    ....[color=blue][color=green][color=darkred]
    >>> p2 = require_int(p2)
    >>> p1(1)[/color][/color][/color]
    1[color=blue][color=green][color=darkred]
    >>> p1('1')[/color][/color][/color]
    Traceback (most recent call last):
    File "<interacti ve input>", line 1, in ?
    File "<interacti ve input>", line 3, in wrapper
    AssertionError[color=blue][color=green][color=darkred]
    >>> p2(1)[/color][/color][/color]
    1[color=blue][color=green][color=darkred]
    >>> p2('1')[/color][/color][/color]
    Traceback (most recent call last):
    File "<interacti ve input>", line 1, in ?
    File "<interacti ve input>", line 3, in wrapper
    AssertionError


    Personally, I never saw the gain of the string.Template class -- in most
    of my uses I can write code that's just as clear and concise using
    %-style formatting. I do however make use of the decorator syntax --
    it's nice to have things like classmethod indicated at the top of the
    function instead of at the bottom.

    Steve

    Comment

    • Doug Holton

      #3
      Re: Python's annoyance.

      caroundw5h wrote:[color=blue]
      > Serioulsy, one of python's main selling points is its elegant syntax,
      > non perl like, non C like. If it can't live up to it. I guess i might
      > as well use perl or ruby or server side javascript.[/color]

      I think it's still better than perl or ruby, but anyway,
      here are your two examples in boo: http://boo.codehaus.org/

      1.
      t = "${page}: ${title}"

      2.
      def p2(arg as int):
      print arg*2

      Probably you'll be able to do similar things in Python 3.0, too, but
      that is years away.

      Comment

      • Jeremy Bowers

        #4
        Re: Python's annoyance.

        On Wed, 24 Nov 2004 10:47:11 -0800, caroundw5h wrote:[color=blue]
        > Serioulsy, one of python's main selling points is its elegant syntax, non
        > perl like, non C like. If it can't live up to it. I guess i might as well
        > use perl or ruby or server side javascript.[/color]

        There's a rather large difference between

        @require_int
        @dynamic_dispat ch('add', int)
        @author("Steven Q. Dude")
        @whack_a_hacka_ ding_dong(with_ fruit=True, sledgehammer=5)
        @register(zodb & mysql_storage)
        def increment(i):
        return i + 1

        and

        @require_int
        def advanceCounter( index):
        objToAdvance = objStorageArray[index]
        obj.prep(prepTy pe = ADVANCE)
        try:
        obj.advance(1)
        except IOError:
        obj.lazyAdvance (1)

        return obj

        One guess which is the more common case.

        I can make any language look bad by focusing on the nasty cases. I mean,
        why not complain about

        p=lambda n,s=2,np=lambda s,f:reduce(lamb da x,y:x and y,map(lambda
        x,y:x%y,[s+1]*(s/2),range(2,s/2+2)))and s+1or f(s+1,f
        ):n>0and[s]+p(n-1,np(s,np))or[]

        (http://groups.google.com/groups?hl=e...99%40tim#link3)

        Obviously, any language that allows that isn't clean.

        You have to take the gestalt of real code written in the language, not
        contrive cases focusing on the worst part of the language. Python's near
        the top of the heap. Javascript would fare better if so many inexperienced
        programmers weren't bashing away in it, and if so many extant programs in
        it weren't bogged down by browser checking code brought on by wildly
        divergent DOMs.

        If you insist on using such faulty metrics, though, hie thee hence to
        Perl, that epitome of elegant syntax and more power to you. I leave you
        with this closing benediction in honor of the might syntactical
        cleanliness of Perl:

        @==sort@$=map$_ .shift@=,@@for@ @=/\pL|,/g;$_=@$[$_]

        (http://perlgolf.sourceforge.net/cgi-...rtem.cgi?id=11)
        (http://perlgolf.sourceforge.net/TPR/0/6/)

        Comment

        • Michel Claveau - abstraction méta-galactique non t

          #5
          Re: Python's annoyance.

          Hi !

          Just for fun (?) :

          A qsort in "J-programming-language" :

          qsort =: ]`(($:@:((}.<:{. )#}.)),{.,($:@: ((}.>{.)#}.)))@ .(*@#)



          More infos here : http://en.wikipedia.org/wiki/J_programming_language




          Comment

          • Giovanni Bajo

            #6
            Re: Python's annoyance.

            caroundw5h wrote:
            [color=blue]
            > Serioulsy, one of python's main selling points is its elegant syntax,
            > non perl like, non C like. If it can't live up to it. I guess i might
            > as well use perl or ruby or server side javascript.
            > how annoying.[/color]

            In fact, I find the decorator syntax awful. But I know this was already
            discussed to a large extent, so there must be a very good reason to use @.
            Which I totally miss, but hey.
            --
            Giovanni Bajo


            Comment

            • Michele Simionato

              #7
              Re: Python's annoyance.

              "Giovanni Bajo" <noway@sorry.co m> wrote in message news:<iBcpd.506 87$Es2.1096718@ twister2.libero .it>...[color=blue]
              > In fact, I find the decorator syntax awful. But I know this was already
              > discussed to a large extent, so there must be a very good reason to use @.
              > Which I totally miss, but hey.[/color]

              Well, there is very good reason: Guido likes it!

              <no further comments ...>

              Michele Simionato

              Comment

              • Christopher Koppler

                #8
                Re: Python's annoyance.

                On Wed, 24 Nov 2004 23:02:01 +0100, Michel Claveau - abstraction
                méta-galactique non triviale en fuite perpétuelle. wrote:
                [color=blue]
                > Hi !
                >
                > Just for fun (?) :
                >
                > A qsort in "J-programming-language" :
                >
                > qsort =: ]`(($:@:((}.<:{. )#}.)),{.,($:@: ((}.>{.)#}.)))@ .(*@#)
                >
                >
                >
                > More infos here : http://en.wikipedia.org/wiki/J_programming_language[/color]


                Well, as J is mostly APL dressed up in ASCII, it's bound to be readable...
                I've found it convenient for some numerical problems though. And getting
                my head around it definitely broadened my perspective - so much in fact,
                that I mostly run screaming from most APL-like languages since I found
                Python :-)

                --
                Christopher

                Comment

                • Giovanni Bajo

                  #9
                  Re: Python's annoyance.

                  Michele Simionato <michele.simion ato@gmail.com> wrote:

                  [color=blue][color=green]
                  >> In fact, I find the decorator syntax awful. But I know this was
                  >> already
                  >> discussed to a large extent, so there must be a very good reason to
                  >> use @.
                  >> Which I totally miss, but hey.[/color]
                  >
                  > Well, there is very good reason: Guido likes it!
                  >
                  > <no further comments ...>[/color]


                  Right.

                  Giovanni Bajo


                  Comment

                  Working...