Recommendations for module hierarchy names for Python parser
Bernie Pope
bjpop at csse.unimelb.edu.au
Sat Jan 17 08:28:09 EST 2009
On 17/01/2009, at 12:18 AM, Duncan Coutts wrote:
> On Fri, 2009-01-16 at 21:53 +1100, Bernie Pope wrote:
>
>> Or would it be better to have something like:
>>
>> Language.Python.Version30
>> Language.Python.Version26
>>
>> In general my strategy has been to follow the structure of
>> Language.C,
>> but they appear to only have one version.
>
> There had been some discussion about variants in Language.C. Currently
> it does GNU C + C99 but if they were split then the suggestion was:
>
> Language.C.GNU
> Language.C.C99
> Language.C.C89
>
> Of course those are the common names of the versions. For Python where
> they are labelled with numbers rather than names then your
> suggestion of
> Language.Python.Version30 or Language.Python.V30 or whatever seems
> fine.
> Do you think it needs both digits? Would V2 and V3 not be enough?
> Surely
> V26 could read code intended for Python-2.4? And similarly a future
> Language.Python.V3 module that was compatible with Python-3.1 should
> still be able to read code for Python-3.0 right?
Good point Duncan.
Yes, I think the single digit is enough.
I'm a bit torn between:
Language.Python.Version3
and
Language.Python.V3
The former is a bit long, but the latter is a bit obscure. I don't
like the compromise of "Ver3"; it is hard to pronounce.
Does anyone have a strong preference for or against the long or short
version? If not, I will go with the long one.
It's a pity module name components can't be just sequences of digits.
Thanks everyone for your advice.
Cheers,
Bernie.
More information about the Libraries
mailing list