Taro writes:
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 or from MODULE import STRINGCONVERTER with readsyntax TYPE or 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 compiler) 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 class Decimal: ... def string_to_Decimal (astring): ... # Decimal constants pi = 3.1415926... ### decimal.py ends here Other comments: 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 question above. (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.