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