[Python-Dev] Re: EnHackathon 2019 - seeking core dev support
On Thu, Oct 31, 2019 at 3:30 PM Lewis Gaul wrote: > I'm happy to set up an EnHackathon channel - is IRC or Zulip preferred in > general? > I prefer Zulip since I can easily participate using my phone, as well as receive email notifications. It also makes searching and following previous discussion trivial, unlike with IRC. It would be reasonable to simply use the existing core/help Zulip stream for this purpose. - Tal ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GGXK2CSOJNXL2YAHXJBCANPJH33GXKOZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Do not fallback to __trunc__ when convert to int
On Fri., 1 Nov. 2019, 8:10 am Guido van Rossum, wrote: > It seems a good idea to add __int__ to Fraction, but if you stop falling > back to __trunc__, won't that cause backwards compatibility issues? I'd say > looking for __trunc__ if the alternative is failing isn't so bad. > Aye, converting a case where code is slower than it needs to be to an outright failure isn't a good trade-off. "Implements __trunc__ but not __int__" could be a good thing for linters to warn about, though. Cheers, Nick. > > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FOD5RWJFN7BWQJOZZGZIDCTY2QLMMMAL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Accepting PEP 602 -- Annual Release Cycle for Python
On Sat., 2 Nov. 2019, 7:05 am Antoine Pitrou, wrote: > > Did you weigh PEP 602 against PEP 605? Is there a summary of the > strong points you found for each and how you decided for the former? > The summary in PEP 607 was accepted as making a convincing case against the status quo. For the comparison between the PEPs, the main problem with PEP 605 was the base 24 month release cycle, as that causes a whole lot of release cycle synchronization problems (a redistributor missing the release train means shipping something 24-30 months old, rather than PEP 602's 12-18 months, or the status quo's 18-24 months), and also increases the temptation to push features into a release before they're ready. The 24 month cycle was also what drove the ABI management complexity in PEP 605's rolling release stream proposal, whereas the 12 month cycle can more readily stick with the familiar alpha/beta/rc sequence. For the points beyond that, there were going to need to be adjustments either way (e.g. many of the issues to be addressed in making annual releases easier for libraries and applications to support are similar to those that would have been needed to make the rolling release stream feasible to support). Cheers, Nick. > Thank you > > Antoine. > > > On Wed, 30 Oct 2019 19:26:35 - > "Brett Cannon" wrote: > > On behalf of the steering council I am happy to announce that as > BDFL-Delegate I am accepting PEP 602 to move us to an annual release > schedule (gated on a planned update; see below). > > > > The steering council thinks that having a consistent schedule every year > when we hit beta, RC, and final it will help the community: > > > > * Know when to start testing the beta to provide feedback > > * Known when the expect the RC so the community can prepare their > projects for the final release > > * Know when the final release will occur to coordinate their own > releases (if necessary) when the final release of Python occurs > > * Allow core developers to more easily plan their work to make sure work > lands in the release they are targeting > > * Make sure that core developers and the community have a shorter amount > of time to wait for new features to be released > > > > The acceptance is gated on Łukasz updating PEP 602 to reflect a planned > shift in scheduling (he's been busy with a release of Black): > > > > * 3 months for betas instead of 2 > > * 2 months for RCs instead of 1 > > > > This was discussed on https://discuss.python.org in order to give the > community enough time to provide feedback in the betas while having enough > time to thoroughly test the RC and to prep for the final release so the > delay from Python's final release to any new project releases is minimal. > It should also fit into the release schedule of Linux distributions like > Fedora better than previously proposed so the distributions can test the RC > when they start preparing for their own October releases. If this turns out > to be a mistake after we try it out for Python 3.9 we can then discuss > going back to longer betas and shorter RCs for the release after that. This > will not change when feature development is cut off relative to PyCon US > nor the core dev sprints happening just before the final release or the > alpha of the next version. > > > > To help people who cannot upgrade on an annual cycle, do note that: > > > > * PEP 602 now says that deprecations will last two releases which is two > years instead of the current 18 months > > * Now that the stable ABI has been cleaned, extension modules should > feel more comfortable targeting the stable ABI which should make supporting > newer versions of Python much easier > > > > As part of the shift to a 2 year deprecation time frame I will be > restarting discussions around PEP 387 as BDFL-Delegate so we can have a > more clear deprecation and backwards-compatibility policy as well for those > that find an annual cycle too fast which will be updated to reflect this > two year time frame (head's up, Benjamin 😉). > > > > Thanks to Łukasz, Nick, and Steve for PEPs 602, 605, and 607 and > everyone else who provided feedback on those PEPs! > > ___ > > Python-Dev mailing list -- python-dev@python.org > > To unsubscribe send an email to python-dev-le...@python.org > > https://mail.python.org/mailman3/lists/python-dev.python.org/ > > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/KE7OS4PZASZMFTW2FP2MWZU5R4Q2QZKU/ > > Code of Conduct: http://python.org/psf/codeofconduct/ > > > ___ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/B2OZTVNI7HFQ5VIFVQWXHSFMR2WDDAK6/ > Code of Conduct: http://python.org/psf/codeofconduct/ > __
[Python-Dev] Re: Do not fallback to __trunc__ when convert to int
01.11.19 00:03, Guido van Rossum пише:
It seems a good idea to add __int__ to Fraction, but if you stop falling
back to __trunc__, won't that cause backwards compatibility issues?
Most numeric types (int, float, Decimal, NumPy types) implement both
__trunc__ and __int__. The only known exception is Fraction. So after
adding __int__ to Fraction and with a deprecation period the possibility
of backwards compatibility issues is pretty low.
I'd say looking for __trunc__ if the alternative is failing isn't so bad.
__trunc__ is looked after __int__ and __index__. But it is looked before
type checks for str, bytes, bytearray and buffer protocol. This slows
down integer parsing. Getting rid of __trunc__ could speed up int('123').
Other possible benefit is that it would allow to check ahead whether the
object can be converted to int. Checking tp_as_number->nb_int and
tp_as_number->nb_index is cheaper than looking up __trunc__ in the type
dict and never executes Python code.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/IR7SXB3TL6RLPJBZ7ZCKISW3GSDSOBCQ/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Do not fallback to __trunc__ when convert to int
On Sat, Nov 2, 2019 at 1:54 PM Nick Coghlan wrote: > > > On Fri., 1 Nov. 2019, 8:10 am Guido van Rossum, wrote: > >> It seems a good idea to add __int__ to Fraction, but if you stop falling >> back to __trunc__, won't that cause backwards compatibility issues? I'd say >> looking for __trunc__ if the alternative is failing isn't so bad. >> > > Aye, converting a case where code is slower than it needs to be to an > outright failure isn't a good trade-off. > I find int() falling back to __trunc__() surprising, actually. Removing it will break backwards-compatibility, but implementing __int__() is an easy fix. Perhaps we could run a code search for classes implementing __trunc__ but not __int__? Speeding up int(str), as well as slightly simplifying the language, are rather good arguments in favor of this. - Tal ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NPUG2SJKNPCX6ECCVJY3W2RC4PXF6MLP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Do not fallback to __trunc__ when convert to int
On Sun., 3 Nov. 2019, 3:29 am Tal Einat, wrote: > On Sat, Nov 2, 2019 at 1:54 PM Nick Coghlan wrote: > >> >> >> On Fri., 1 Nov. 2019, 8:10 am Guido van Rossum, wrote: >> >>> It seems a good idea to add __int__ to Fraction, but if you stop falling >>> back to __trunc__, won't that cause backwards compatibility issues? I'd say >>> looking for __trunc__ if the alternative is failing isn't so bad. >>> >> >> Aye, converting a case where code is slower than it needs to be to an >> outright failure isn't a good trade-off. >> > > I find int() falling back to __trunc__() surprising, actually. > > Removing it will break backwards-compatibility, but implementing __int__() > is an easy fix. > This is exactly the kind of change that prompted Victor to write PEP 608: seeing a compatibility break as our first option rather than as a last resort. Each one is cheap on its own, but collectively they make supporting new CPython versions more painful than it really needs to be. > Perhaps we could run a code search for classes implementing __trunc__ but > not __int__? > > Speeding up int(str), as well as slightly simplifying the language, are > rather good arguments in favor of this. > In this specific case, they're not particularly strong arguments. * For performance, there shouldn't be any problem with making the check for __trunc__ the very last conversion tried. That will still speed up all successful int conversions that currently incur the cost of checking for a non-existent __trunc__ method, and could only cause a compatibility issue for obscure cases where a type that defines __trunc__, but not __int__, gives a different answer when handled via one of the type-specific conversions instead. * For simplification, "versions up to X allow A, versions after X only allow B" is never actually simpler, it's always more complex than just leaving things alone. It's just that the cost is sometimes worth it when the status quo is causing actual code correctness bugs. However, what could genuinely be simpler in this case (as discussed in https://bugs.python.org/issue33039 and https://bugs.python.org/issue20092) is to move the fallback logic to type creation time rather than requiring that it be implemented in every function that accepts Integral types as input. That logic would be: * if __index__ exists, make __int__ and __trunc__ wrappers around that if they don't already exist * if __int__ exists, but not __trunc__ or __index__, make __trunc__ a wrapper around __int__ * if __trunc__ exists, but not __int__ or __index__, make __int__ a wrapper around __trunc__ With that logic in place, consumers could just call whichever API made the most sense for their use case, and trust the type machinery to provide any appropriate fallbacks. Cheers, Nick. > - Tal > ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/UKTMEBPM5HTDKMCBIJYHPILH4X4EEKPQ/ Code of Conduct: http://python.org/psf/codeofconduct/
