Extending Python Syntax with @

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

    #46
    Re: Extending Python Syntax with @

    Richie Hindle <richie@entrian .com> writes:
    [color=blue]
    >[Cameron][color=green]
    >> Whenever you feel like a lambda, define a named function;[/color][/color]
    [color=blue]
    >[Kyler][color=green]
    >> How do you cleanly do that?
    >> foo = range(-10, 10)
    >> my_op = lambda x: float(x) / max(map(abs, foo))
    >> bar = map(my_op, foo)[/color][/color]
    [color=blue]
    >foo = range(-10, 10)
    >def my_op(x):
    > return float(x) / max(map(abs, foo))
    >bar = map(my_op, foo)[/color]
    [color=blue]
    >...did I misunderstand?[/color]

    Well, your solution depends on a global variable. That's going to
    get *really* ugly if we move beyond the trivial example given here.
    There are other problems but they're apparently not obvious with
    that example.

    How 'bout some non-working code to shine some more light on it? (If
    pressed, I should be able to come up with similar code that works!)

    def make_translatio n_function(GCPs , type, invert=False):
    if type == 'LSF' and len(GCPs) < 12:
    # Do lots of time-consuming magic to calculate A, B, ...
    return(
    lambda x, y: (
    x * A + y * B +
    x * y * C +
    ...,
    x * G + y * H +
    x * y * I +
    ...
    )
    )
    elif ... # Repeat lots of times for variations.

    map_im = foo.open('map.t if')
    map_translation = make_translatio n_function(map_ im.get_GCPs, type='LSF')

    path_im = foo.open('path. tif')
    path_translatio n_i = make_translatio n_function(path _im.get_GCPs, type='LSF', invert=True)

    # Mark all points on map that are red in path.
    for (x, y) in all_red_pixels( path_im):
    (lon, lat) = path_translatio n_i(x, y)
    (x, y) = map_translation (lon, lat)
    map_im.putpixel ((x, y), mark_val)

    Now, let's pretend that this is part of a larger program that's doing lots
    of things with, potentially, lots of images, and let's also say that we
    allow user-defined/imported extensions to make_translatio n_function().
    How are you going to make a *clean* solution using named functions?

    --kyler

    Comment

    • David MacQuigg

      #47
      Re: Extending Python Syntax with @

      On Thu, 11 Mar 2004 14:50:57 +0000, Peter Hickman
      <peter@semantic o.com> wrote:
      [color=blue]
      >If what motivates you is the 'ultimate language' and think you can get
      >closer to it by adding special characters then you are going to be very
      >disappointed . The history of computing is littered with 'ultimate
      >languages' that have had much more thought put into them than adding
      >special characters to an existing language (C++ comes to mind) and they
      >all have in common the fact that they failed.[/color]

      Perl seems to be a better example of too much syntax.
      [color=blue]
      >To be fair C++ was never touted as an 'ultimate language' but you get
      >the picture.
      >
      >If you feel python has a significant flaw then say what it is and how
      >you believe it would best be addressed. Using @ as a special character
      >is just adding sugar to the syntax.[/color]

      It's not a single flaw. In fact I can't imagine a single flaw that
      would justify adding a special symbol. It only makes sense if adding
      the symbol *improves* consistency by reducing the number of syntactic
      variations, compared to adding each new feature with a *different*
      syntax or unique keyword.

      If someone new to Python saw a function with '@return' instead of
      'return', it would be pretty easy to remember this has something to do
      with efficiency, just think of it as a normal function until you start
      writing your own code.

      There is an optimum balance between too much syntax and too little. I
      think Python is pretty close to that optimum. There are a few things
      I would eliminate, and a few things I would add. Same with Ruby. I
      like their use of the @ symbol, but I can't see the advantage of their
      cryptic 'code blocks' over a normal Python function. I don't like
      their subtle distinction between single and double-quoted strings.

      Much of this is just personal preference, but in some cases you can
      see a real advantage. I like their simple but powerful string
      methods. You can put a lot on one line without sacrificing clarity.
      See http://userlinux.com/cgi-bin/wiki.pl?RubyPython for details. I
      think we can learn some things from Ruby, which after all, was
      developed after a few years of learning from Python.

      -- Dave

      Comment

      • Peter Maas

        #48
        Re: Extending Python Syntax with @

        David MacQuigg schrieb:[color=blue][color=green]
        >>David MacQuigg schrieb:
        >>Disadvantag es of your proposal:
        >>
        >>- The advantage is also a disadvantage: a lowered barrier for
        >> new semantics could bloat the language definition. Python's
        >> strength is that it has *few* concepts that are usable in *many*
        >> places. This could be compromised by your proposal.[/color]
        >
        >
        > This is actually a separate issue. Adding a few @ mods to selected
        > statements does not mean that users can add their own.[/color]

        I assumed that in my response but also GvR and the Python community
        can do too much with @.
        [color=blue]
        > Readability, in this case, is in the eye of the beholder. 'lambda' to
        > me says 'wavelength', which I know has nothing to do with programming.[/color]

        :-)) OK, of course I was talking about the semantics within the
        language framework. Otherwise you could claim that def says deaf and
        for says four ;-)
        [color=blue]
        > 'yield' is a little closer to the intent, but again, to most new users
        > it probably means something more like 'give way' or 'acquiesce', the
        > opposite of 'resist'. If you had never seen 'yield' used as it is now
        > in Python, and your first encounter with generator functions was when
        > you saw @return, would you not think "Ah yes, a modified return.", and
        > would that not be closer to reality than whatever you might associate
        > with the word 'yield'?[/color]

        Sometimes it's an advantage to be a non-native speaker. I know exactly
        one meaning of yield (something like deliver) and that fits nicely to
        generators. :)

        Mit freundlichen Gruessen,

        Peter Maas

        --
        -------------------------------------------------------------------
        Peter Maas, M+R Infosysteme, D-52070 Aachen, Hubert-Wienen-Str. 24
        Tel +49-241-93878-0 Fax +49-241-93878-20 eMail peter.maas@mplu sr.de
        -------------------------------------------------------------------

        Comment

        • David M. Cooke

          #49
          Re: Extending Python Syntax with @

          At some point, Kyler Laird <Kyler@news.Lai rds.org> wrote:[color=blue]
          > Richie Hindle <richie@entrian .com> writes:[color=green]
          >>[Cameron][color=darkred]
          >>> Whenever you feel like a lambda, define a named function;[/color]
          >>[Kyler][color=darkred]
          >>> How do you cleanly do that?
          >>> foo = range(-10, 10)
          >>> my_op = lambda x: float(x) / max(map(abs, foo))
          >>> bar = map(my_op, foo)[/color][/color]
          >[color=green]
          >>foo = range(-10, 10)
          >>def my_op(x):
          >> return float(x) / max(map(abs, foo))
          >>bar = map(my_op, foo)[/color]
          >[color=green]
          >>...did I misunderstand?[/color]
          >
          > Well, your solution depends on a global variable. That's going to
          > get *really* ugly if we move beyond the trivial example given here.
          > There are other problems but they're apparently not obvious with
          > that example.[/color]

          The lambda depends on a global variable too (or at least, a variable
          up one scope).
          [color=blue]
          > How 'bout some non-working code to shine some more light on it? (If
          > pressed, I should be able to come up with similar code that works!)
          >
          > def make_translatio n_function(GCPs , type, invert=False):
          > if type == 'LSF' and len(GCPs) < 12:
          > # Do lots of time-consuming magic to calculate A, B, ...
          > return(
          > lambda x, y: (
          > x * A + y * B +
          > x * y * C +
          > ...,
          > x * G + y * H +
          > x * y * I +
          > ...
          > )
          > )
          > elif ... # Repeat lots of times for variations.
          >
          > map_im = foo.open('map.t if')
          > map_translation = make_translatio n_function(map_ im.get_GCPs, type='LSF')
          >
          > path_im = foo.open('path. tif')
          > path_translatio n_i = make_translatio n_function(path _im.get_GCPs, type='LSF', invert=True)
          >
          > # Mark all points on map that are red in path.
          > for (x, y) in all_red_pixels( path_im):
          > (lon, lat) = path_translatio n_i(x, y)
          > (x, y) = map_translation (lon, lat)
          > map_im.putpixel ((x, y), mark_val)
          >
          > Now, let's pretend that this is part of a larger program that's doing lots
          > of things with, potentially, lots of images, and let's also say that we
          > allow user-defined/imported extensions to make_translatio n_function().
          > How are you going to make a *clean* solution using named functions?[/color]

          Umm, easily? You don't have to refer to functions by their original
          name; they are first-class objects.

          def make_translatio n_function(GCPs , type, invert=False):
          if type == 'LSF' and len(GCPs) < 12:
          # Do lots of time-consuming magic to calculate A, B, ...
          def LSF_function(x, y):
          xy = x*y
          lon = x*A + y*B + xy*C + ...
          lat = x*G + y*H + xy*I + ...
          return (lon, lat)
          return LSF_function
          elif ... # Repeat lots of times for variations.

          I've even optimized by premultiplying x and y, which couldn't do in
          the lambda, and made the code clearer by breaking up the calculation.

          --
          |>|\/|<
          /--------------------------------------------------------------------------\
          |David M. Cooke
          |cookedm(at)phy sics(dot)mcmast er(dot)ca

          Comment

          • Raymond Hettinger

            #50
            Re: Extending Python Syntax with @

            [David MacQuigg][color=blue]
            > print @(separator = None) x, y, z[/color]

            For this particular example, you might get farther by proposing a
            builtin print function that takes optional keyword arguments:

            def newprint(*args, separator=' ', destination=sys .stdout):
            print >> destination, separator.join( args)

            Guido at one time wished that print was a function instead of a
            statement. Here's your chance to push that idea forward.

            Using a function instead of a statement is inherently more flexible,
            easier to extend, and helps address a couple of micro-warts (i.e. a
            handful of people hate the automatic spacing, and more than a handful
            hate the >> notation).


            Raymond Hettinger

            Comment

            • Paul Rubin

              #51
              Re: Extending Python Syntax with @

              python@rcn.com (Raymond Hettinger) writes:[color=blue]
              > Guido at one time wished that print was a function instead of a
              > statement. Here's your chance to push that idea forward.[/color]

              What about the assert statement? Should that be a function too?

              Comment

              • David MacQuigg

                #52
                Re: Extending Python Syntax with @

                On Thu, 11 Mar 2004 21:42:54 +0100, Peter Maas
                <fpetermaas@net scape.net> wrote:

                Peter Maas:[color=blue][color=green][color=darkred]
                >>>- The advantage is also a disadvantage: a lowered barrier for
                >>> new semantics could bloat the language definition. Python's
                >>> strength is that it has *few* concepts that are usable in *many*
                >>> places. This could be compromised by your proposal.[/color][/color][/color]

                David MacQuigg:[color=blue][color=green]
                >> This is actually a separate issue. Adding a few @ mods to selected
                >> statements does not mean that users can add their own.[/color][/color]

                Peter Maas:[color=blue]
                > I assumed that in my response but also GvR and the Python community
                > can do too much with @.[/color]

                I have enormous faith in GvR and the people working with him. I can't
                imagine them falling into the Perl trap (overuse of symbols in a
                syntax).

                -------

                Peter Maas:
                - Python is a readable language. lambda says "function literal",
                yield says "generator" , @ just says "different" . Python would
                be less readable if this notation would be adopted.

                David MacQuigg:
                Readability, in this case, is in the eye of the beholder. 'lambda' to
                me says 'wavelength', which I know has nothing to do with programming.
                I suspect many users are like me, not enough computer science
                background to know that lambda means 'function literal'.

                Peter Maas:
                :-)) OK, of course I was talking about the semantics within the
                language framework. Otherwise you could claim that def says deaf and
                for says four ;-)

                I really wasn't trying to be clever with words in telling you what
                comes to my mind with 'lambda'. Thinking back on my experience
                learning Python, I can also say that this word, and the mystique
                around "lambda calculus" also conveyed a subtle meaning of "complex",
                or "advanced topic", which caused me to avoid lambdas for a few
                months. I took five years of calculus in college, and I still don't
                see the connection between lambda functions and calculus.

                Let's focus on users of Python, many of whom are technical
                professionals, but not computer scientists. All I'm saying is that
                new keywords like lambda can have the opposite of the intended
                simplifying effect. They can make things *seem* more complex. It all
                depends on users perceptions and their background.

                I was astonished to learn today that GvR himself called for the
                deprecation of lambda, citing "confusing" as one of the reasons.
                The official home of the Python Programming Language

                This guy is a language genious, yet he still understands the ordinary
                users perspective. A *rare* combination.

                -- Dave

                Comment

                • Kyler Laird

                  #53
                  Re: Extending Python Syntax with @

                  cookedm+news@ph ysics.mcmaster. ca (David M. Cooke) writes:
                  [color=blue]
                  >The lambda depends on a global variable too (or at least, a variable
                  >up one scope).[/color]

                  That's quite a significant difference. The *result* of the lambda
                  does not depend on a global variable.
                  [color=blue]
                  >def make_translatio n_function(GCPs , type, invert=False):
                  > if type == 'LSF' and len(GCPs) < 12:
                  > # Do lots of time-consuming magic to calculate A, B, ...
                  > def LSF_function(x, y):
                  > xy = x*y
                  > lon = x*A + y*B + xy*C + ...
                  > lat = x*G + y*H + xy*I + ...
                  > return (lon, lat)
                  > return LSF_function[/color]

                  Ah...*that's* what I needed. I hadn't considered that a defined
                  function could be passed out of the scope like that.

                  Thank you.

                  --kyler

                  Comment

                  • Myles

                    #54
                    Re: Extending Python Syntax with @

                    Kyler Laird <Kyler@news.Lai rds.org> writes:
                    [color=blue]
                    > Richie Hindle <richie@entrian .com> writes:
                    >
                    > [Kyler][color=green][color=darkred]
                    > >> How do you cleanly do that?
                    > >> foo = range(-10, 10)
                    > >> my_op = lambda x: float(x) / max(map(abs, foo))
                    > >> bar = map(my_op, foo)[/color][/color]
                    >[color=green]
                    > >foo = range(-10, 10)
                    > >def my_op(x):
                    > > return float(x) / max(map(abs, foo))
                    > >bar = map(my_op, foo)[/color]
                    >
                    > Well, your solution depends on a global variable.[/color]

                    foo ? my_op ?
                    Doesn't the same apply to the lambda example ?
                    [color=blue]
                    > def make_translatio n_function(GCPs , type, invert=False):
                    > if type == 'LSF' and len(GCPs) < 12:
                    > # Do lots of time-consuming magic to calculate A, B, ...
                    > return(
                    > lambda x, y: (
                    > x * A + y * B +
                    > x * y * C +
                    > ...,
                    > x * G + y * H +
                    > x * y * I +
                    > ...
                    > )
                    > )
                    > elif ... # Repeat lots of times for variations.[/color]

                    Isn't this just a more detailed example of the same thing ?
                    With a similar solution :

                    def make_translatio n_function(GCPs , type, invert=False):
                    if type == 'LSF' and len(GCPs) < 12:
                    # Do lots of time-consuming magic to calculate A, B, ...
                    def translation_fn( x, y):
                    return (
                    x * A + y * B +
                    x * y * C +
                    ...,
                    x * G + y * H +
                    x * y * I +
                    ...
                    )
                    return translation_fn
                    elif ... # Repeat lots of times for variations.

                    Quick variation using working code:

                    def makefn(a, b):
                    A = a*3
                    B = b * 2
                    def my_op(x, y):
                    return (x*A + y*B, (x+A)*(y+B))
                    return my_op

                    x = makefn(1, 1)
                    print x(2, 2)

                    Regards, Myles.

                    Comment

                    • Cameron Laird

                      #55
                      More glossary items (was: Extending Python Syntax with @)

                      In article <i5t1501ljfh9qt ks01o5gc5mtbc0l ooj8n@4ax.com>,
                      David MacQuigg <dmq@gain.com > wrote:

                      Comment

                      • Greg Ewing (using news.cis.dfn.de)

                        #56
                        Re: More glossary items

                        Cameron Laird wrote:[color=blue]
                        > There are other calculi--"quaternion calculus" and "vector
                        > calculus" are two not-too-uncommonly-heard ones.[/color]

                        Indeed, in mathematics the word "calculus" really just
                        means a method of calculating something. It's actually
                        the Latin word for "stone", presumably dating back to
                        the time when people used stones as counters when
                        doing arithmetic.

                        --
                        Greg Ewing, Computer Science Dept,
                        University of Canterbury,
                        Christchurch, New Zealand


                        Comment

                        • Greg Ewing (using news.cis.dfn.de)

                          #57
                          Re: Extending Python Syntax with @

                          Paul Rubin wrote:[color=blue]
                          > What about the assert statement? Should that be a function too?[/color]

                          No, because then the compiler wouldn't be able to optimise
                          it away when asserts are turned off.

                          --
                          Greg Ewing, Computer Science Dept,
                          University of Canterbury,
                          Christchurch, New Zealand


                          Comment

                          • Y2KYZFR1

                            #58
                            Re: Extending Python Syntax with @

                            Ben Finney <bignose-hates-spam@and-benfinney-does-too.id.au> wrote in message news:<slrnc4v69 6.lhs.bignose-hates-spam@iris.polar .local>...[color=blue]
                            > On Wed, 10 Mar 2004 16:50:58 -0500, John Roth wrote:[color=green]
                            > > Someday people will get over their attachment with being able to write
                            > > programs with any old text editor that happens to be lying around, and
                            > > being able to print their programs without needing a special
                            > > formatting program, but that day isn't today, and I doubt if it's
                            > > tomorrow.[/color]
                            >
                            > I doubt it's ever, because such a day would have to be preceded by the
                            > day when programs no longer need to be inspected, maintained or
                            > transferred between systems not specifically set up as developer
                            > workstations.[/color]

                            funny thing is VB has survived this long just because you HAVE to have
                            the IDE to edit the code. That is one of the biggest selling points of
                            VB.

                            It should not be an issue, just make all the IDE's cross platform.

                            All the worth while Java IDE's are cross platform. Intellij IDEA and
                            Together.
                            Maybe Eclipse but it is pretty buggy compared to the commerical
                            offerings.

                            That is what Python is missing is an quality IDE that is cross
                            platform. All the ones out now suck when compared to something like
                            IDEA or Together.

                            anyone that thinks about following up this post with anything about vi
                            or emacs can just stop right now and go back to their hole.

                            Comment

                            • Peter Hickman

                              #59
                              Re: Extending Python Syntax with @

                              Cameron Laird wrote:[color=blue]
                              > Forth. Lisp. Tcl.[/color]

                              I was thinking of even less than that. Just define a few flow control
                              things and get everything out of the objects. I expect it would look
                              either like lisp or smalltalk.

                              There would only be one built in datatype, the message, and all the
                              objects would chuck messages around. Thus the language as such would
                              have a very limited syntax.

                              load Object.class;
                              load Stream.class;

                              x = new Object;
                              s = new Stream;

                              s.print x.to_string;

                              So we have declare variables, load classes and pass messages.

                              Comment

                              • Max M

                                #60
                                Re: Extending Python Syntax with @

                                Y2KYZFR1 wrote:
                                [color=blue]
                                > That is what Python is missing is an quality IDE that is cross
                                > platform. All the ones out now suck when compared to something like
                                > IDEA or Together.
                                >
                                > anyone that thinks about following up this post with anything about vi
                                > or emacs can just stop right now and go back to their hole.[/color]

                                An IDE isn't worth much in many use cases. I see the reason in it when
                                developing gui apps. But for my work I honestly don't see any use for it.

                                Basically a good tabbed editor suits my needs.

                                The only two things I really miss is:

                                1) A good refactoring tool. Search and replace can be a bit hit'n miss
                                sometime.

                                2) A context aware class browser, that would show the classes with the
                                methods & defined attributes they have in the current context. So that I
                                could do a little less grep'ing and manual backtracking of ancestor objects.

                                So maybe I *do* ned a good IDE anyway :-)


                                regards Max M

                                Comment

                                Working...