>>> That doesn't fix the multiple versions problem.
>>
>> This is a big issue that the core Pythonistas don't seem to be
>> interested in addressing. It's odd, because I think it's a no-brainer
>> that python modules need to be versioned, and there needs to be a way
>> to have multiple versions co-existing and user (that is code)
>> selectable.
has> Agree completely. I think the reason folk are reluctant to address
has> it isn't that it's an inherently hard problem, but that to solve it
has> now requires either 1. hard political decisions to achieve an easy
has> technical solution (i.e. a solution that's not backwards-compatible
has> with previous versions of Python and would require big changes to
has> the way that module-related tools and community operate), or
has> 2. difficult and costly technical solutions to obtain a politically
has> expedient answer.
There's more to it than that:
1. Most people simply don't need it. My first brush with versioning
Python modules occurred in the past few months at my current job, and
that was mostly so our SWIG'd modules could be released in step with
our locally written C++ libraries. I used Python for ten years
before that without ever feeling the need for versioning.
2. I think it will be challenging to come up with a versioning scheme
that works for everyone. To do versioning at work we had to solve
issues related to module naming, directory structure, source code
control and local build environment tools to make it work.
has> Alas, that's weird and wobbly and completely paradoxical world of
has> software for you.... Oh well, maybe in Python 3000... ;)
Write a PEP and put it out for review. I don't recall seeing this raised in
the Python community before. I certainly don't think it's something the
core developers worry about, so maybe more "real world" input is necessary
to get it to fly.
Skip
_______________________________________________
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
