[Python-Dev] Python 3000 PEP: Postfix type declarations
PEP: XXX
Title: Postfix type declarations
Version: $Revision: $
Last-Modified: $Date: $
Author: Georg Brandl [EMAIL PROTECTED]
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 01-Apr-2007
Python-Version: 3.0
Abstract
This PEP proposes the addition of a postfix type declaration syntax to
Python. It also specifies a new ``typedef`` statement which is used to create
new mappings between types and declarators.
Its acceptance will greatly enhance the Python user experience as well as
eliminate one of the warts that deter users of other programming languages from
switching to Python.
Rationale
=
Python has long suffered from the lack of explicit type declarations. Being one
of the few aspects in which the language deviates from its Zen, this wart has
sparked many a discussion between Python heretics and members of the PSU (for
a few examples, see [EX1]_, [EX2]_ or [EX3]_), and it also made it a large-scale
enterprise success unlikely.
However, if one wants to put an end to this misery, a decent Pythonic syntax
must be found. In almost all languages that have them, type declarations lack
this quality: they are verbose, often needing *multiple words* for a single
type, or they are hard to comprehend (e.g., a certain language uses completely
unrelated [#]_ adjectives like ``dim`` for type declaration).
Therefore, this PEP combines the move to type declarations with another bold
move that will once again prove that Python is not only future-proof but
future-embracing: the introduction of Unicode characters as an integral
constituent of source code.
Unicode makes it possible to express much more with much less characters, which
is in accordance with the Zen (Readability counts.) [ZEN]_. Additionally, it
eliminates the need for a separate type declaration statement, and last but not
least, it makes Python measure up to Perl 6, which already uses Unicode for its
operators. [#]_
Specification
=
When the type declaration mode is in operation, the grammar is changed so that
each ``NAME`` must consist of two parts: a name and a type declarator, which is
exactly one Unicode character.
The declarator uniquely specifies the type of the name, and if it occurs on the
left hand side of an expression, this type is enforced: an ``InquisitionError``
exception is raised if the returned type doesn't match the declared type. [#]_
Also, function call result types have to be specified. If the result of the call
does not have the declared type, an ``InquisitionError`` is raised. Caution:
the
declarator for the result should not be confused with the declarator for the
function object (see the example below).
Type declarators after names that are only read, not assigned to, are not
strictly
necessary but enforced anyway (see the Python Zen: Explicit is better than
implicit.).
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.
Unicode replacement units
=
Since even in our modern, globalized world there are still some old-fashioned
rebels who can't or don't want to use Unicode in their source code, and since
Python is a forgiving language, a fallback is provided for those:
Instead of the single Unicode character, they can type ``name${UNICODE NAME OF
THE DECLARATOR}$``. For example, these two function definitions are equivalent::
def fooƛ(xℂ):
return None
and ::
def foo${LATIN SMALL LETTER LAMBDA WITH STROKE}$(x${DOUBLE-STRUCK CAPITAL
C}$):
return None${ZERO WIDTH NO-BREAK SPACE}$
This is still easy to read and makes the full power of type-annotated Python
Re: [Python-Dev] Python 3000 PEP: Postfix type declarations
Brilliant!
On 4/1/07, Georg Brandl [EMAIL PROTECTED] wrote:
def foo${LATIN SMALL LETTER LAMBDA WITH STROKE}$(x${DOUBLE-STRUCK
CAPITAL C}$):
return None${ZERO WIDTH NO-BREAK SPACE}$
This is still easy to read and makes the full power of type-annotated Python
available to ASCII believers.
+1
J
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3000 PEP: Postfix type declarations
On 4/1/07, Georg Brandl [EMAIL PROTECTED] wrote:
[...]
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.
Is this supposed to be a joke? Please tell me this isn't a real PEP.
While I'm all for allowing unicode identifiers in Python, postfix type
annotations make Python look like Perl. And how can you claim this code is
more readable? It certainly is _less_ readable, not more.
I agree that Python should support type annotations, but they should be
optional and only present at the function interfaces, i.e. specify the type
in the function parameter lists, like in plain old C.
+1 from me for allowing unicode identifiers.
-MAXVOTE for type annotations in identifiers.
--
Gustavo J. A. M. Carneiro
The universe is always one step beyond logic.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3000 PEP: Postfix type declarations
On 4/1/07, Gustavo Carneiro [EMAIL PROTECTED] wrote:
On 4/1/07, Georg Brandl [EMAIL PROTECTED] wrote:
[...]
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.
Is this supposed to be a joke?
/me ashamed for not having noticed the date of this PEP... :P
--
Gustavo J. A. M. Carneiro
The universe is always one step beyond logic.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3000 PEP: Postfix type declarations
Johann C. Rocholl wrote:
Brilliant!
On 4/1/07, Georg Brandl [EMAIL PROTECTED] wrote:
def foo${LATIN SMALL LETTER LAMBDA WITH STROKE}$(x${DOUBLE-STRUCK
CAPITAL C}$):
return None${ZERO WIDTH NO-BREAK SPACE}$
This is still easy to read and makes the full power of type-annotated Python
available to ASCII believers.
+1
J
This also has the advantage that any good editor with auto correct and
completion can convert from one form to the other as you type. A feature I
love in my word processor because it *always* does *exactly* what I want
and saves me much typing.
+1ℕ
;-)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] proposed which.py replacement
on 31.03.2007 22:39 Guido van Rossum said the following: If you ask me, having it hosted by Trent is probably more helpful for its popularity than putting it in the Python source distro; the Tools directory is mostly a poorly-maintained collection of trivia I wrote many years ago that is now quietly gathering dust. Some time ago, I posted a `feature request`_ about which.py including the proposal to put it into the std-lib as ``which`` or ``os.which`` to allow programmatic use and:: python -m which ... This should take care of the visibility problem. ;-) However, there are several todos_, including tests and docs, before this can even be considered. I am afraid I did not have any time to work on it yet. cheers, stefan .. _feature request: http://sourceforge.net/tracker/index.php?func=detailaid=1509798group_id=5470atid=355470 .. _todos: http://trentm.com/projects/which/TODO.txt (Not all of it, of course; there's some useful stuff there that I *didn't* write, which ended up there because it is either *used* by the distro (e.g. the compiler package support) or because the author needed a channel that guaranteed open source status (e.g. world and pynche). But Trent's which.py doesn't seem to fall in either category.) --Guido On 3/31/07, Shane Geiger [EMAIL PROTECTED] wrote: Trent Mick has a module called which.py that might make a nice platform-independent replacement for python2.5/Tools/scripts/which.py. http://www.trentm.com/projects/which/ Why which.py? |which.py| is a small GNU-which replacement. It has the following features: * it is portable (Windows, Linux, Mac OS X, Un*x); * it understands PATHEXT and App Paths registration on Windows (i.e. it will find everything that |start| does from the command shell); * it can print all matches on the PATH; * it can note near misses on the PATH (e.g. files that match but may not, say, have execute permissions); and * it can be used as a Python module. I also would be happy to have this be a replacement for the |which.py| in the Python CVS tree at |dist/src/Tools/scripts/which.py| which is Unix-specific and not usable as a module; and perhaps for inclusion in the stdlib. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] BaseException pickle issue
Eric Huss wrote: Some subclasses of Exception are no longer pickleable in Python 2.5. An example: [snip] Does anyone have any thoughts about this? Is it a bug? I can imagine one could argue that exceptions should call the base __init__ method to properly set args, but there are so many exceptions out there that do not do this that it would be very difficult to track them all down. I removed the __reduce__ and __setstate__ methods from BaseException and everything seems to just work. Pickling/unpickling works for all protocols whether or not you set self.args. Is this an appropriate solution? I'm not sure what the motivation for having these methods is. I think that this is a bug, but removing those methods is not the right solution. The __reduce__ method is needed because builtin exceptions don't store their attributes in the __dict__ anymore; if you remove it, then those attributes will be lost during pickling. The __setstate__ method was added to help with unpickling old exceptions, which did store all their attributes in the __dict__. See this patch for details: http://www.python.org/sf/1498571 A better solution would be to move the initial args attribute assignment to BaseException.__new__. See this patch: http://www.python.org/sf/1692335 Could you check if that fixes your problem? Ziga ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] proposed which.py replacement
It's out of character for the standard library, since (regardless of whether it's implemented in Python or part of the standard library) it's a stand-alone utility. I don't see much use for this as a library module. On 4/1/07, Stefan Rank [EMAIL PROTECTED] wrote: on 31.03.2007 22:39 Guido van Rossum said the following: If you ask me, having it hosted by Trent is probably more helpful for its popularity than putting it in the Python source distro; the Tools directory is mostly a poorly-maintained collection of trivia I wrote many years ago that is now quietly gathering dust. Some time ago, I posted a `feature request`_ about which.py including the proposal to put it into the std-lib as ``which`` or ``os.which`` to allow programmatic use and:: python -m which ... This should take care of the visibility problem. ;-) However, there are several todos_, including tests and docs, before this can even be considered. I am afraid I did not have any time to work on it yet. cheers, stefan .. _feature request: http://sourceforge.net/tracker/index.php?func=detailaid=1509798group_id=5470atid=355470 .. _todos: http://trentm.com/projects/which/TODO.txt (Not all of it, of course; there's some useful stuff there that I *didn't* write, which ended up there because it is either *used* by the distro (e.g. the compiler package support) or because the author needed a channel that guaranteed open source status (e.g. world and pynche). But Trent's which.py doesn't seem to fall in either category.) --Guido On 3/31/07, Shane Geiger [EMAIL PROTECTED] wrote: Trent Mick has a module called which.py that might make a nice platform-independent replacement for python2.5/Tools/scripts/which.py. http://www.trentm.com/projects/which/ Why which.py? |which.py| is a small GNU-which replacement. It has the following features: * it is portable (Windows, Linux, Mac OS X, Un*x); * it understands PATHEXT and App Paths registration on Windows (i.e. it will find everything that |start| does from the command shell); * it can print all matches on the PATH; * it can note near misses on the PATH (e.g. files that match but may not, say, have execute permissions); and * it can be used as a Python module. I also would be happy to have this be a replacement for the |which.py| in the Python CVS tree at |dist/src/Tools/scripts/which.py| which is Unix-specific and not usable as a module; and perhaps for inclusion in the stdlib. ___ Python-Dev mailing list Python-Dev@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/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python Documentation Problem Example
Python Doc Problem Example: os.path.split() Xah Lee, 20050918 Quote from: http://www.python.org/doc/2.4.1/lib/module-os.path.html « split(path) Split the pathname path into a pair, (head, tail) where tail is the last pathname component and head is everything leading up to that. The tail part will never contain a slash; if path ends in a slash, tail will be empty. If there is no slash in path, head will be empty. If path is empty, both head and tail are empty. Trailing slashes are stripped from head unless it is the root (one or more slashes only). In nearly all cases, join(head, tail) equals path (the only exception being when there were multiple slashes separating head from tail). » This confusive verbiage is a result of the author's pretention in a austere style and his failure to think clearly before writing. Suggested rewrite: « split(path) returns a pair (dirname,filename), where dirname is the part of path up to the last slash, and filename is the rest of the string after the last slash. Exceptional cases are: • if path is a single slash (or repeated), then path == dirname and filename is empty. • If the last slash is repeated, they are treated as one single slash. » I was working on a program where i needed to split a path into dirname, corename, and suffix. I came to this page and took me a while to understand what split() is about. There are other path related functions splitext(), splitdrive (), basename(), dirname(). User has to scan the whole page and read painfully each one to fully understand how to choose and use them for the task at hand. As i have explained before (see references at bottom), documentation should be organized oriented towards programer's tasks, not alphabetically, compiler view, or computer sciency scheme. On this os.path module, split(), splittext(), dirname(), basename() should all be under one section. This way, their usefulness and each's fitness becomes clearer, and also easier to document as a collective. Other functions that test files or get info about files should be grouped together. Don't be afraid of having functions that won't fit into some grouping scheme. For exapmle, the walk() and supports_unicode_filenames() can be lumped at the bottom as Other. The need to present materials in some aloof, computer sciency, academic, technically precise way is a major usability problem of the Python doc. (the Pythoners's need to present materials in a formal style is a backlash of the happy-go-lucky sloppiness of unix/perl community. However, they being pretty much the same crowd without significant critical thinking and writing skills, cannot do better by hiding in formality.) Also, at the top we see: Warning: On Windows, many of these functions do not properly support UNC pathnames. splitunc() and ismount() do handle them correctly. As indicated before, this is a exhibition of tech geeking and jargonizing. If this warning is necessary, place it at the bottom of the page as a footnote. Also, spell out UNC, and provide a link to its proper spec. Tech geekers are very pretentious and cryptic in their tech docs. They are afraid, as if spelling out UNC would make them unprofessional, that their peers would deem them inferior. There are a myriad of technical standards that any programer could only be familiar with a fraction, confined to his area of expertise. Standards and its acronyms come and go, and each with varying degrees of precision, actual relevance, and they are intermingled with de facto practices in the commercial world that may not even have official names. The tech geekers are clouded by their tech-expertise. The purpose of documentation is not some cold academic presentation. Vast majority who came to use os.path wouldn't know what UNC is nor do they need to know. Spell things out when in doubt. UNC here, isn't really a significant “standard”. This warning should be left out. Suggestions: * Regroup path manipulating functions together, file info functions together, etc. * After regrouping the functions, much of the writing can be simplified since these functions are doing similar tasks. Writing can focus on their differences. Rewrite them with a focus on what users needs to do. Add examples in intricate situations. Avoid the computer science thesis writing style. * Remove the UNC warning at the top. - Here are a few other Python doc problems i've written in the past years: Python doc problem example: os.system() http://xahlee.org/perl-python/python_doc_os.html Python Doc Problem Example: os.path.split() http://xahlee.org/perl-python/python_doc_os_path_split.html Python Doc Problem Example: sort() http://xahlee.org/perl-python/python_doc_sort.html Python Doc Problem Example: gzip module http://xahlee.org/perl-python/python_doc_gzip.html Xah [EMAIL PROTECTED] ∑
Re: [Python-Dev] Python 3000 PEP: Postfix type declarations
+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 [EMAIL PROTECTED] wrote:
On 4/1/07, Georg Brandl [EMAIL PROTECTED] 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
Re: [Python-Dev] Python+XUL
Has anyone heard the Python+XUL community cry I'm not dead yet! or are they really dead? I haven't seen mentions of new work in these areas lately. XUL in general seems to have died (so many broken links on XUL pages). Was this just a fad? If not, and if there's some really useful of it (especially if in Python) please point it out. This work is still ongoing. The primary docs are at http://developer.mozilla.org/en/docs/PyXPCOM, and the #pyxpcom channel on irc.mozilla.org does sometimes see some action. The mozilla trunk has Python in XUL working, and is being used by at least a few people. The ongoing work is fairly sporadic, but is currently aimed at closer integration of Javascript and Python with the DOM - notably enabling native attributes on DOM objects to be accessed by other languages. Mark ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
