1.5.2 / standard modules / lib-old/lockfile.py Why?

Jeff Blaine jblaine at shell2.shore.net
Fri May 14 10:07:35 EDT 1999


I'm a little distressed by lockfile.py being moved out of the standard
module library, and then I'm also confused as to WHY it was moved out.

Could someone shed some light on this topic, please?  Is it JUST because
the 'fcntl' module now 'exports' the proper FCNTL constants and the
FCNTL module no longer needs to be imported?  Is that even right?  IF
that's the case, is that not just a little bit lazy (why not take the
20 seconds to update lockfile.py instead of shoving it aside) ?

This all makes me very concerned about the state of the things I depend
on because they're installed as part of 'make install'.

There's a HUGE difference in

    a) "if you want to use Python 1.new you will need to change
        your calls to SOMELIB.connect() in the somelib module because
        of reason X Y Z that was unavoidable"

and

    b) "Note: somelib is in lib-old now, you're on your own"

Maybe I'm naive or being weird about this whole topic, but it just seems
to me that people consider 'Python' everything they get from a 'make
install', anything else added by hand is done at the person's risk.  Removing
core features (yes, I consider standard library modules part of the 'core'
in this sense) should be done (IMO) at major revision releases, and should
be well announced ahead of time.  By "well announced ahead of time", I mean
that in the documentation and in the module itself, it should be mentioned
several minor revisions prior to removal that the module should no longer
be depended on and solid plans are underway to remove the module entirely.

Could someone either set me straight or chime in about this?  I'm curious
whether I need to adjust my expectations or if I'm being reasonable here.




More information about the Python-list mailing list