[Python-Dev] Python 3000 PEP: Postfix type declarations

[Guido van Rossum]

+18446744073709551616 from me too.

This also fits nicely in with my plan to abandon the python-dev and
python-3000 mailing lists. Mailing lists are so 20th century! I
propose that from now on, all Python development should be carried out
on blogs, so that readers can use customized RSS feeds to read only
those contributions they are interested in. I note that all the key
developers already have a blog, e.g.:

Aahz - http://www.artima.com/weblogs/index.jsp?blogger=aahz
Neal Norwitz - http://nnorwitz.blogspot.com/
Fredrik Lundh - http://effbot.org/pyref/blog.htm
Jeremy Hylton - http://www.python.org/~jeremy/weblog/
Anthony Baxter - http://codingweasel.blogspot.com/
Phillip Eby - http://dirtsimple.org/programming/index.html
Talin - http://www.advogato.org/person/Talin/diary.html
David Ascher - http://ascher.ca/blog/
Fred Drake - http://www.advogato.org/person/fdrake/diary.html

(and myself, of course - http://www.artima.com/weblogs/index.jsp?blogger=guido)

--Guido

On 4/1/07, Collin Winter <collinw at gmail.com> wrote:
> On 4/1/07, Georg Brandl <g.brandl at gmx.net> wrote:
> [snip several pages of excellent ideas]
> >
> > The mapping between types and declarators is not static. It can be completely
> > customized by the programmer, but for convenience there are some predefined
> > mappings for some built-in types:
> >
> > =========================  ===================================================
> > Type                       Declarator
> > =========================  ===================================================
> > ``object``                 � (REPLACEMENT CHARACTER)
> > ``int``                    ℕ (DOUBLE-STRUCK CAPITAL N)
> > ``float``                  ℮ (ESTIMATED SYMBOL)
> > ``bool``                   ✓ (CHECK MARK)
> > ``complex``                ℂ (DOUBLE-STRUCK CAPITAL C)
> > ``str``                    ✎ (LOWER RIGHT PENCIL)
> > ``unicode``                ✒ (BLACK NIB)
> > ``tuple``                  ⒯ (PARENTHESIZED LATIN SMALL LETTER T)
> > ``list``                   ♨ (HOT SPRINGS)
> > ``dict``                   ⧟ (DOUBLE-ENDED MULTIMAP)
> > ``set``                    ∅ (EMPTY SET) (*Note:* this is also for full sets)
> > ``frozenset``              ☃ (SNOWMAN)
> > ``datetime``               ⌚ (WATCH)
> > ``function``               ƛ (LATIN SMALL LETTER LAMBDA WITH STROKE)
> > ``generator``              ⚛ (ATOM SYMBOL)
> > ``Exception``              ⌁ (ELECTRIC ARROW)
> > =========================  ===================================================
> >
> > The declarator for the ``None`` type is a zero-width space.
> >
> > These characters should be obvious and easy to remember and type for every
> > programmer.
> >
> [snip]
> >
> > Example
> > =======
> >
> > This is the standard ``os.path.normpath`` function, converted to type declaration
> > syntax::
> >
> >      def normpathƛ(path✎)✎:
> >          """Normalize path, eliminating double slashes, etc."""
> >          if path✎ == '':
> >              return '.'
> >          initial_slashes✓ = path✎.startswithƛ('/')✓
> >          # POSIX allows one or two initial slashes, but treats three or more
> >          # as single slash.
> >          if (initial_slashes✓ and
> >              path✎.startswithƛ('//')✓ and not path✎.startswithƛ('///')✓)✓:
> >              initial_slashesℕ = 2
> >          comps♨ = path✎.splitƛ('/')♨
> >          new_comps♨ = []♨
> >          for comp✎ in comps♨:
> >              if comp✎ in ('', '.')⒯:
> >                  continue
> >              if (comp✎ != '..' or (not initial_slashesℕ and not new_comps♨)✓ or
> >                   (new_comps♨ and new_comps♨[-1]✎ == '..')✓)✓:
> >                  new_comps♨.appendƛ(comp✎)
> >              elif new_comps♨:
> >                  new_comps♨.popƛ()✎
> >          comps♨ = new_comps♨
> >          path✎ = '/'.join(comps♨)✎
> >          if initial_slashesℕ:
> >              path✎ = '/'*initial_slashesℕ + path✎
> >          return path✎ or '.'
> >
> > As you can clearly see, the type declarations add expressiveness, while at the
> > same time they make the code look much more professional.
>
> My only concern is that this doesn't go far enough. While knowing that
> some object is a ⒯ is a good start, it would be so much more helpful
> to know that it's a ⒯ of ✎s. I think something like ✎✎✎3⒯ to indicate
> a 3-⒯ of ✎s would be nice. This would change the line in the above
> from "if comp✎ in ('', '.')⒯:" to "if comp✎ in ('', '.')✎✎2⒯:", which
> I think is a nice win in terms of readability, EIBTI and all that.
>
> (Sidebar: I think the PEP should feature a section on how these new
> type declarations will cut down on mailing list volume and
> documentation size.)
>
> In light of this PEP, PEP 3107's function annotations should be
> rejected. All that hippie feel-good crap about "user-defined
> annotations" and "open-ended semantics" and "no rules, man" was just
> going to get us into trouble. This PEP's more modern conception of
> type annotations give the language a power and expressiveness that my
> PEP could never hope to match.
>
> This is clearly a move in the right direction. +4 billion.
>
> Collin Winter
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
>


-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)