[Twisted-Python] twisted.python.dist as a public API
Hi, Why is twisted.python.dist3.py a public module? Are there any external projects which need to get the list of the modules ported to Python3? ------------------ Why is twisted.python.dist a public module? The docstring starts with `Don't use this outside of Twisted.' but why not named it twisted.python._dist or twisted.python._setup to make it clear that it is private ? ------- I am trying to clean up the setup.py code as I feel that having the setup() definition split between setup.py and dist.py is not ideal ---------- Can I rename twisted.python.dist and remove unused code from twisted.python.dist without a deprecation dance? -------------- The dedicated ticket is here https://twistedmatrix.com/trac/ticket/8622 and is in the review queue Regards, -- Adi Roiban
On Aug 6, 2016, at 16:31, Adi Roiban
wrote: Hi,
Why is twisted.python.dist3.py http://twisted.python.dist3.py/ a public module?
Negligence on the part of a code reviewer :).
Are there any external projects which need to get the list of the modules ported to Python3?
No. This info should be private.
Why is twisted.python.dist a public module?
Similarly; this code was just accidentally made public without much thought. This is why twisted.python._release exists, and contains much more code;
The docstring starts with `Don't use this outside of Twisted.' but why not named it twisted.python._dist or twisted.python._setup to make it clear that it is private ?
Again; just a mistake.
I am trying to clean up the setup.py code as I feel that having the setup() definition split between setup.py and dist.py is not ideal
The purpose of putting stuff in dist.py was just to be able to unit test it. If you have some alternate strategy for testing, that might be better.
Can I rename twisted.python.dist and remove unused code from twisted.python.dist without a deprecation dance?
You always have to follow the compatibility process - if it's not a security bug, we would have to change the process first :-). But if you want to follow the exception path rather than the deprecation path (this message doesn't qualify, because the subject is incorrectly formatted) I certainly don't have any objection. -glyph
On 7 August 2016 at 00:50, Glyph Lefkowitz
You always have to follow the compatibility process - if it's not a security bug, we would have to change the process first :-). But if you want to follow the exception path rather than the deprecation path (this message doesn't qualify, because the subject is incorrectly formatted) I certainly don't have any objection.
As pointed by Craig in the PR, dist3.py is used by https://github.com/habnabit/twisted-depgraph. I will revert the dist3 change. With this email, I just wanted to get an initial feedback and try to understand why we have code split between setup.py and dist.py I will come back with an email following the compatibility process. Thanks! -- Adi Roiban
On Aug 7, 2016, at 4:03 AM, Adi Roiban
wrote: On 7 August 2016 at 00:50, Glyph Lefkowitz
mailto:glyph@twistedmatrix.com> wrote: [snip]
You always have to follow the compatibility process - if it's not a security bug, we would have to change the process first :-). But if you want to follow the exception path rather than the deprecation path (this message doesn't qualify, because the subject is incorrectly formatted) I certainly don't have any objection.
As pointed by Craig in the PR, dist3.py is used by https://github.com/habnabit/twisted-depgraph https://github.com/habnabit/twisted-depgraph. I will revert the dist3 change.
I should point out that the entire point of twisted-depgraph is to help Twisted developers - basically, you and Craig - understand the dependencies remaining and port more things to py3. So I'm pretty sure Aaron would not mind at all if he had to update it :). It's not really a user-facing application, just a core developer tool.
With this email, I just wanted to get an initial feedback and try to understand why we have code split between setup.py and dist.py
I will come back with an email following the compatibility process.
Thanks!
No problem! I have a little tool that imports dist3 myself, and it is _super_ encouraging to see the percentages of ported code these days. -g
participants (2)
-
Adi Roiban
-
Glyph Lefkowitz