[Python-ideas] non-Pre-PEP: Syntactic replacement of built-in types with user-defined callables (Take 2... fewer newlines!)
Stephen J. Turnbull
stephen at xemacs.org
Tue Jan 29 22:59:53 CET 2008
> User-defined classes are second-class citizens, requiring data to be
> manually converted from a type:
> mydecimal = Decimal("1.00000000000000001")
> myrope = Rope("my rope")
> myblist = BList([1,2,4,8])
> myordereddict = OrderedDict((1,"a"), (2, "b"), (3, "c"))
> myfrozenset = frozenset([1,2,3])
As a matter of presenting the PEP in the best light, this isn't an
issue of "second-class" to me, for one.
ISTM that it's simply a matter of (a) giving syntax to constructions
that are used a lot in control structures, and (b) the historical fact
that other types that have syntax defined for them came first and were
added as built-ins. Some of them possibly shouldn't have syntax. As
a strawman example, many Python programs use floats very rarely, and
we could conceivably -- but not *plausibly* -- demote float and
require "my_approximate_pi = float('3.14')".
> If there's only one or two conversions needed in a file, then such
> conversion is not particularly burdensome, but if one wants to
> consistently use (say) decimals throughout a file then the ability to
> use a literal syntax makes for prettier source.
This is very persuasive, but may not be enough. Jim's suggestion of a
"logging string" was also interesting.
> The syntax for a typedef is:
> from MODULE typedef ADAPTOR as TYPE
I'm sorry, but I hate this term "typedef". This is not a "type
definition" in any Pythonic sense of the word "type", and the
associations with C-style typedefs are painful. How about
from MODULE import STRINGCONVERTER with TYPE readsyntax
from MODULE import STRINGCONVERTER with readsyntax TYPE
from MODULE import STRINGCONVERTER readsyntax TYPE
> a/ definition of adaptors would have to be allowed pre-typedef, which
> would allow them to be buried in code, making them far easier to miss;
I don't see why this is a problem. An adaptor for a scalar TYPE is
just a converter from string to that TYPE. If you have a such a
converter (eg, because you're using Python as the platform for
translating another language), why not just use it here?
Since the way this would work is that each TYPE would have a
string-to-TYPE-value converter, you would just do (inside the
TYPE.stringconverter = STRINGCONVERTER
and if the compiler encountered a literal with an undefined
.stringconverter, it would generate an error to the effect of
Use of TYPE stringconverter 'STRINGCONVERTER' before definition.
I think this would not be a problem in practice (except for typos)
because you'd write decimal.py like this:
### decimal.py --- class Decimal for multiprecision decimal arithmetic
from decimal import string_to_decimal with float readsyntax
def string_to_Decimal (astring):
# Decimal constants
pi = 3.1415926...
### decimal.py ends here
One problem I see with this proposal is that for non-scalar TYPEs, in
general a user may want to take over the whole process of parsing TYPE
literals. What I don't see in your proposal is what restrictions you
want to put on that. It seems like what you have in mind for a MyList
is to convert from a list, but what if in your code you mostly want
floats to be floats, but in MyLists they should be Decimals? This
would mean loss of precision:
string -> list of floats -> MyList of Decimals
Don't take the example too seriously, we can discuss later whether
there would be real use cases like this. What I want to know is how
you see this case working. Take over parsing the whole string? Or
let the list type parse the string, and then convert? In the latter
case, I think EIBTI applies. The former seems rather unlikely to fly
as a PEP.
> I know it's considered polite to provide code, but any implementation
> would have to be in C,
No, there's PyPy.
> so please accept this extremely fake dummy
> implementation which in no way resembles the way things really work as
> a poor substitute:
You might as well omit this; it doesn't really even help answer my
(IANALL but ISTM that) an issue here is at what point does the
compiler learn that a syntactic list is actually a literal, and your
code doesn't help indicate that, or whether it would need to differ
from the current compiler, either.
More information about the Python-ideas