(I’m not sure this belongs here, or that it’s really a plea for help…)
I am randomly plucking module documentation out of the libref manual to proofread and perhaps tweak. Today, my random documentation selector dropped the
sched module in my lap. It’s not a new module by any means. Though almost nothing remains untouched from its earliest origins, I see that Guido defined the class name in 1991. Was the opportunity to capitalize the class name to
Scheduler just a miss way back in the early 3.x days when this sort of renaming was common?
Does it make sense to rename
class scheduler to
class Scheduler, then aliasing the former to the latter (and adding the relevant deprecation details)?
scheduler = Scheduler
warnings.warn("'scheduler' is deprecated as of 3.12. Use 'Scheduler'",
I don’t see the
sched module on any obvious list of deprecated modules (and I’m not suggesting it should be).
Naming conventions for classes are messy.
On the one hand, classes for “fundamental” data types like list, int, str, dict, complex etc are lowercased (but there are exceptions like Decimal etc). There’s no hard definition of a fundamental data type, but surely a scheduler isn’t one no matter how you look at it.
On the other hand, PEP 8 suggests SnakeCase names for classes, and this would be a good example of a class that (in hindsight) should be named with an initial capital.
But on the gripping hand, it seems a bit of a waste of time and energy for everyone involved to bother going through the depreciation process for
scheduler. We don’t often make purely cosmetic changes of this sort.
(If we did, I wish we would rename
Object to make it easier to distinguish between generic objects versus actual
The downsides of an alias are relatively small:
- somebody (you?) has to make a PR, including documentation changes;
- somebody else has to approve it;
- then we’ll be dealing forever with people asking "what’s the difference between
- and depreciation carries its own costs, often carried by end-users who aren’t in a position to stop the annoying depreciation message.
My personal feeling is that creating a PEP 8 alias is harmless but we probably shouldn’t bother depreciating the old name.
But I fully expect that many people will say don’t bother.
I’d say don’t bother. I think the downside of aliases is much higher than ‘relatively small’. We just got rid of the unittest assert… aliases. Besides, we have been inconsistent elsewhere. Why does collections have OrderedDict, UserDict, and defautdict?
Thanks folks. I was mostly wondering how so much attention was paid to some modules (
threading comes to mind), while others were ignored. I guess there was no concerted effort to adjust capitalization across Lib.
There’s a general feeling that global “normalisation” or “tidying up” exercises are disruptive (and therefore bad). But fixing details like this “while work is going on in that area” is a more acceptable thing to do. While there’s been a slow but ongoing trickle of changes to the
sched module, there’s not been anything big enough to warrant a “tidy things up while we’re here” exercise.
Quoting PEP 8:
“In particular: do not break backwards compatibility just to comply with this PEP!”
The least appreciated aspect of PEP8
(apologies for the delay responding - been away from the keyboard)
Note though that I wasn’t suggesting just breaking things, but going through the normal deprecation process.
Still, I’m not as focused on this specific change as on why there wasn’t a wholesale effort to make these sorts of changes in the 2.x->3.x transition, where (as I recall) there was “one chance to fix things.” These would have been pretty trivial fixes for
Given the overall pain involved in the move to Python 3.x, it seems that would have been the perfect time to make these simple breaking changes.
From what I recall of the transition, the “big” changes took enough energy that a lot of the smaller things like this simply got missed, or everyone decided they weren’t worth the risk of triggering an unexpected debate.