[Python-Dev] Re: Adding a scarier warning to object.__del__?
Hi, On Thu, 2 Jan 2020 at 03:59, Yonatan Zunger wrote: > It is possible (though not recommended!) for the __del__() method to postpone > destruction of the instance by creating a new reference to it. This is called > object resurrection. It is implementation-dependent whether __del__() is > called a second time when a resurrected object is about to be destroyed; the > current CPython implementation only calls it once. "...in most cases." Armin Rigo ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/LHY2EM7PMSSUAMORBOHIUZAYKHILAMJO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Adding a scarier warning to object.__del__?
I would say that the "recommended" weakref.finalize() shares very many limitations of __del__(), that's why hard to buy it. atexit.register() is not a common thing, the recommendation of using atexit for file descriptor closing *in general* looks weird, while it can be a good solution in some particular case. On Thu, Jan 2, 2020 at 1:05 PM Armin Rigo wrote: > > Hi, > > On Thu, 2 Jan 2020 at 03:59, Yonatan Zunger wrote: > > It is possible (though not recommended!) for the __del__() method to > > postpone destruction of the instance by creating a new reference to it. > > This is called object resurrection. It is implementation-dependent whether > > __del__() is called a second time when a resurrected object is about to be > > destroyed; the current CPython implementation only calls it once. > > "...in most cases." > > > Armin Rigo -- Thanks, Andrew Svetlov ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/VY2PX376FVNKR3KGFM557KR4OMRH22VL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Adding a scarier warning to object.__del__?
weakref.finalize always executes during the ordinary Python flow, IIUC -- e.g., it happens before the interpreter is stopping. I guess it does still have the "arbitrary thread" limitation -- which is a good point, I may have some code bugs of my own to fix. But it's a huge difference in terms of predictability of the interpreter state, and in particular both the issues around deleted modules and the ones around threading no longer working don't apply to it. atexit is a pretty corner-case thing -- I agree that it shouldn't be the common thing at all, and the recommendation should be specifically for those use cases where it makes sense. FD's are a classic thing to close with weakref.finalize. On Thu, Jan 2, 2020 at 7:47 AM Andrew Svetlov wrote: > I would say that the "recommended" weakref.finalize() shares very many > limitations of __del__(), that's why hard to buy it. > atexit.register() is not a common thing, the recommendation of using > atexit for file descriptor closing *in general* looks weird, while it > can be a good solution in some particular case. > > On Thu, Jan 2, 2020 at 1:05 PM Armin Rigo wrote: > > > > Hi, > > > > On Thu, 2 Jan 2020 at 03:59, Yonatan Zunger wrote: > > > It is possible (though not recommended!) for the __del__() method to > postpone destruction of the instance by creating a new reference to it. > This is called object resurrection. It is implementation-dependent whether > __del__() is called a second time when a resurrected object is about to be > destroyed; the current CPython implementation only calls it once. > > > > "...in most cases." > > > > > > Armin Rigo > > > > -- > Thanks, > Andrew Svetlov > ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/FIM4PII72PCUZ7WVZBGCPHRNXYRH7WIX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Python Documentation and AIX specifics - how to proceed?
That whole directory is mostly outdated (e.g. those Wing files are two major versions behind and we have ripped out all other editor-specific files in the repo). I think the first question is what do we want for that directory to be? Based on that we can decide if something like AIX build instructions makes sense or if we should just gut the directory. For me personally, I'm torn. While helping out other folks using AIX through that text file might be good due to the work you put in, Michael, while not being an officially supported OS, I'm also fine with emptying that folder out down to the bare minimum. ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/O5KPNXWTFLGRB6XAAS3WXYYYHNFDXVG7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should set objects maintain insertion order too?
The only `OrderedSet` use I have seen in the wild is https://github.com/python-hyper/uritemplate/search?q=orderedset&unscoped_q=orderedset . ___ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/GYIOTCKMKAYK2T6AALEDLZQVWCWLMXQD/ Code of Conduct: http://python.org/psf/codeofconduct/
