[Python-ideas] PEP Post-History
We’ve made a small change to the PEP process which may affect readers of python-list and python-ideas, so I’d like to inform you of it. This change was made to PEP 1 and PEP 12. PEPs must have a Post-History header which records the dates at which the PEP is posted to mailing lists, in order to keep the general Python community in the loop as a PEP moves to final status. Until now, PEPs in development were supposed to be posted at least to python-dev and optionally to python-list[1]. This guideline predated the creation of the python-ideas mailing list. We’ve now changed this guideline so that Post-History will record the dates at which the PEP is posted to python-dev and optionally python-ideas. python-list is dropped from this requirement. python-dev is always the primary mailing list of record for Python development, and PEPs under development should be posted to python-dev as appropriate. python-ideas is the list for discussion of more speculative changes to Python, and it’s often where more complex PEPs, and even proto-PEPs are first raised and their concepts are hashed out. As such, it makes more sense to change the guideline to include python-ideas and/or python-dev. In the effort to keep the forums of record to a manageable number, python-list is dropped. If you have been watching for new PEPs to be posted to python-list, you are invited to follow either python-dev or python-ideas. Cheers, -Barry (on behalf of the Python development community) https://mail.python.org/mailman/listinfo/python-dev https://mail.python.org/mailman/listinfo/python-ideas Both python-dev and python-ideas are available via Gmane. [1] PEPs may have a Discussions-To header which changes the list of forums where the PEP is discussed. In that case, Post-History records the dates that the PEP is posted to those forums. See PEP 1 for details. signature.asc Description: Message signed with OpenPGP ___ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Thread.__init__ should call super()
Since one of the legit use-cases of using the Thread class is subclassing, I think it's __init__ should call super() to support cooperative inheritance. Or perhaps there is a good reason for not doing so? Best Regards, Ilya Kulakov ___ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Thread.__init__ should call super()
You can subclass Thread just fine, you just can't have it in a multiple inheritance hierarchy except at the end of the MRO (before object). That shouldn't stop you from doing anything you want though -- you can define e.g. class MyThread(Thread): def __init__(self, *args, **kwds): Thread.__init__(self, *args, **kwds) super(Thread, self).__init__(*args, **kwds) and use this class instead of Thread everywhere. (You'll have to decide which arguments to pass on and which ones to ignore, but that's not specific to the issue of Thread.) Of course you're probably better off not trying to be so clever. On Fri, Oct 27, 2017 at 1:59 PM, Ilya Kulakov wrote: > Since one of the legit use-cases of using the Thread class is subclassing, > I think it's __init__ should call super() to support cooperative > inheritance. > > Or perhaps there is a good reason for not doing so? > > Best Regards, > Ilya Kulakov > > > ___ > Python-ideas mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-ideas > Code of Conduct: http://python.org/psf/codeofconduct/ > > -- --Guido van Rossum (python.org/~guido) ___ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Thread.__init__ should call super()
On Fri, Oct 27, 2017 at 01:59:01PM -0700, Ilya Kulakov wrote: > Since one of the legit use-cases of using the Thread class is subclassing, > I think it's __init__ should call super() to support cooperative inheritance. > > Or perhaps there is a good reason for not doing so? Are you talking about threading.Thread or some other Thread? If you are talking about threading.Thread, its only superclass is object, so why bother calling super().__init__? To be successful, it would need to strip out all the parameters and just call: super().__init__() with no args, as object.__init__() takes no parameters. And that does nothing, so what's the point? I'm afraid I don't see why you think that threading.Thread needs to call super. Can you explain? -- Steve ___ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
