Re: [Python-Dev] Unable to build regex module against Python 3.5 32-bit
On 26 May 2015 23:25, "Paul Moore" wrote: > > On 26 May 2015 at 13:55, Steve Dower wrote: > > The builds I am responsible for include it because someone reported an issue > > and was persistent and helpful enough that I fixed it for them. > > > > That said, until MinGW agrees on a stable branch/version/fork, there seems > > to be a good chance that the shipped lib won't work for some people. If this > > is what's happened here, I see it as a good enough reason to stop shipping > > the lib and to add instructions on generating it instead (the gendef/dlltool > > dance). > > Agreed. If shipping it helps, then great. If it's going to cause bug > reports, let's go back to the status quo of not having it. The > instructions for generating it were in the old distutils docs, now > removed in the cleanup / redirection to packaging.python.org. I'm > inclined to just leave it undocumented - the people who need it know > how to do it or can find it, whereas documenting the process implies a > level of support that we're not yet really able to provide. The old distutils docs aren't gone, the top level links just moved to the distutils package docs: https://docs.python.org/3/library/distutils.html I kept them (with the same deep link URLs) because I know there's stuff in there that isn't currently documented anywhere else. I moved them to a more obscure location because there's also stuff in there that's thoroughly outdated, and it's a non-trivial task to figure out which is which and move the still useful stuff to a more appropriate home :) Cheers, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On Mon, 25 May 2015 17:30:02 -0700 Larry Hastings wrote: > > So, in all three cases it's work that's been under development for a > while. These people did this work out of the kindness of their hearts, > to make Python better. As a community we want to encourage that and > make sure these developers know we appreciate their efforts. These > people would be happier if the work shipped in 3.5 as opposed to 3.6 so > it got into user's hands sooner. I second that sentiment. But it strikes me that we're doing this because our release frequency is completely inadapted. If we had feature releases, say, every 6 or 9 months, the problem wouldn't really exist in the first place. Exceptions granted by the RM only tackle a very small portion of the problem, because the long delay before an accepted patch being in an official release *still* frustrates everyone, and the unpredictability of exceptions only makes things *more* frustrating for most players. Of course, it was pretty much shut down before: https://mail.python.org/pipermail/python-dev/2012-January/115619.html Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unable to build regex module against Python 3.5 32-bit
On 27 May 2015 at 09:10, Nick Coghlan wrote: > The old distutils docs aren't gone, the top level links just moved to the > distutils package docs: https://docs.python.org/3/library/distutils.html > > I kept them (with the same deep link URLs) because I know there's stuff in > there that isn't currently documented anywhere else. I moved them to a more > obscure location because there's also stuff in there that's thoroughly > outdated, and it's a non-trivial task to figure out which is which and move > the still useful stuff to a more appropriate home :) Thanks. Your plan worked perfectly, because I never knew they were there :-) https://docs.python.org/3/install/index.html#older-versions-of-python-and-mingw implies that the libpythonXY.a files are only needed in older versions of Python/mingw. I don't know how true that is, although I do know that mingw should be able to link directly to a DLL without needing a lib file. It would be interesting to know if MRAB's build process can use the DLL, rather than requiring a lib file (or for that matter if distutils works without the lib file!) Paul ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On 27 May 2015 18:18, "Antoine Pitrou" wrote: > > On Mon, 25 May 2015 17:30:02 -0700 > Larry Hastings wrote: > > > > So, in all three cases it's work that's been under development for a > > while. These people did this work out of the kindness of their hearts, > > to make Python better. As a community we want to encourage that and > > make sure these developers know we appreciate their efforts. These > > people would be happier if the work shipped in 3.5 as opposed to 3.6 so > > it got into user's hands sooner. > > I second that sentiment. But it strikes me that we're doing this > because our release frequency is completely inadapted. If we had > feature releases, say, every 6 or 9 months, the problem wouldn't really > exist in the first place. Exceptions granted by the RM only tackle a > very small portion of the problem, because the long delay before an > accepted patch being in an official release *still* frustrates everyone, > and the unpredictability of exceptions only makes things *more* > frustrating for most players. I'd actually like to pursue a more nuanced view of what's permitted in maintenance releases, based on a combination of the language moratorium PEP, and an approach inspired by PEP 466, requiring that every feature added in a maintenance release be detectable through an attribute check on a module (with corresponding support in dependency checking tools). The problem with simply speeding up the release cycle without constraining the interim releases in some way is that it creates significant pain for alternate implementations and for downstream redistributors (many of whom are still dealing with the fallout of the Python 3 transition). Cheers, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On Wed, 27 May 2015 18:34:29 +1000 Nick Coghlan wrote: > > I'd actually like to pursue a more nuanced view of what's permitted in > maintenance releases, based on a combination of the language moratorium > PEP, and an approach inspired by PEP 466, requiring that every feature > added in a maintenance release be detectable through an attribute check on > a module (with corresponding support in dependency checking tools). I think this will only complicate the rules and make contributing a specialists' game. Every time you complicate the rules, you add uncertainty, cognitive overhead, opportunities for lengthy discussions, controversies (for an extreme example, think of the Wikipedia process). There is enough boilerplate to care about right now when integrating a patch. > The problem with simply speeding up the release cycle without constraining > the interim releases in some way is that it creates significant pain for > alternate implementations and for downstream redistributors (many of whom > are still dealing with the fallout of the Python 3 transition). At some point, we should recognize our pain is more important than others' when it comes to the fitness of *our* community. I don't see those other people caring about our pain, and proposing e.g. to offload some of the maintenance burden (for example the 2.7 LTS maintenance burden, the maintenance of security branches). For some reason it sounds like we should be altruistic towards people who are not :-) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On 27 May 2015 at 19:02, Antoine Pitrou wrote: > At some point, we should recognize our pain is more important than > others' when it comes to the fitness of *our* community. I don't see > those other people caring about our pain, and proposing e.g. to offload > some of the maintenance burden (for example the 2.7 LTS maintenance > burden, the maintenance of security branches). Sure we care, corporate politics and business cases are just complex beasts to wrangle when it comes to justifying funding of upstream contributions. The main problem I personally have pushing for increased direct upstream investment at the moment is that we're still trying to get folks off Python *2.6*, provide a smoother transition plan for the Python 2.7 network security fixes, and similarly get ready to help customers handle the Python 3 migration, so it's hard for me to make the case that upstream maintenance is the task most in need of immediate investment. (We also don't have a well established culture of Python users reporting Python bugs to the commercial redistributor providing their copy of Python, which breaks one of the key metrics we rely on as redistributors for getting upstream contributions funded appropriately funded: "only files bugs and feature requests directly with the upstream project" and "doesn't use the project at all" unfortunately looks identical from a vendor perspective) Even with those sorts of challenges, Red Hat still covered implementing the extension module importing improvements in 3.5 (as well as making it possible for me to take the time for reviewing the async/await changes, amongst other things), and HP have now taken over from Rackspace as the primary funder of pypi.python.org development (and a lot of PyPA development as well). The Red Hat sponsored CentOS QA infrastructure is also the back end powering the pre-merge patch testing Kushal set up. Red Hat and Canonical have also been major drivers of Python 3 porting efforts for various projects as they've aimed to migrate both Ubuntu and Fedora to using Python 3 as the system Python. Longer term, the best way I know of to get corporations to pick up the tab for things like 2.7 maintenance is to measure it and publish the results (as well as better publicising who is releasing products that depend on it). Paying customers get nervous when open source foundations are publishing contribution metrics that call into question a vendor's ability to support their software (even if the relevant foundation is too polite to point it out explicitly themselves, just making this kind of data available means that competing vendors inevitably use it to snipe at each other). The OpenStack Foundation's stackalytics.openstack.com is a master class in doing this well, with the Linux Foundation's annual kernel development report a close second, so I'd actually like to get the PSF to fund regular contribution metrics for CPython. Setting that up unfortunately hasn't made it to the top of my todo list yet (obviously, given it hasn't been done), but I'm cautiously optimistic about being able to get to it at some point this year. > For some reason it > sounds like we should be altruistic towards people who are not :-) Nope, if we're doing things for the benefit of corporations, we should demand they pay for it if they want it done (or at least be happy that the value of the free software, services and contributions they're making available to the community are sufficient to earn them a fair hearing). However, even if we personally happen to be sceptical of the contributions particular corporations have made to the open source community (or choose to discount any contributions that consist specifically of bug fix commits to the CPython repo), we don't get to ignore their *users* so cavalierly, and we've ended up in a situation where the majority of Python users are 5-7 years behind the progress of core development at this point. Donald's PyPI statistics (https://caremad.io/2015/04/a-year-of-pypi-downloads/) suggest to me that Linux distributions may need to shoulder a lot of the blame for that, and assuming I'm right about that, fixing it involves changing the way Linux distributions work in general, rather than being a Python-specific problem (hence proposals like https://fedoraproject.org/wiki/Env_and_Stacks/Projects/UserLevelPackageManagement and new ways of approaching building Linux distributions, like CoreOS and Project Atomic). However, the fact that 2.6 currently still has a larger share of PyPI downloads than Python 3, and that 2.7 is still by far the single most popular version is a problem that we need to be worried about upstream as well. That doesn't point towards "we should make the entire standard library move faster" for me: it points me towards leveraging PyPI to further decouple the rate of evolution of the ecosystem from the rate of evolution of the core interpreter and standard library. If attribute level granularity sounds too complex (a
Re: [Python-Dev] Preserving the definition order of class namespaces.
On May 27, 2015, at 06:34 PM, Nick Coghlan wrote: >I'd actually like to pursue a more nuanced view of what's permitted in >maintenance releases, based on a combination of the language moratorium >PEP, and an approach inspired by PEP 466, requiring that every feature >added in a maintenance release be detectable through an attribute check on >a module (with corresponding support in dependency checking tools). PEP 466 and Python 2.7 are a special case. I wouldn't want to adopt such tactics in normal Python 3 releases. Imagine the nightmare of some poor library author who wants to make sure their package works with Python 3.6. They're faced with a source release of 3.6.5, but 3.6.3 in Ubuntu, 3.6.4 in Fedora, 3.6.2 in Debian, and users of all stripes of patch releases on Windows and OS X. Now they have to pepper their code with attribute tests just to support "Python 3.6". In fact, claiming support for Python 3.6 actually doesn't convey enough information to their users. Sure, we can limit this to new features, but even new features introduce risk. We've decided to accept this risk for Python 2.7 for good and important reasons, but we shouldn't do the same for ongoing normal releases. >The problem with simply speeding up the release cycle without constraining >the interim releases in some way is that it creates significant pain for >alternate implementations and for downstream redistributors (many of whom >are still dealing with the fallout of the Python 3 transition). I'm not convinced that relaxing the maintenance release constraints lessens the pain for anybody. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On May 27, 2015 at 4:18:11 AM, Antoine Pitrou (solip...@pitrou.net) wrote: On Mon, 25 May 2015 17:30:02 -0700 Larry Hastings wrote: > > So, in all three cases it's work that's been under development for a > while. These people did this work out of the kindness of their hearts, > to make Python better. As a community we want to encourage that and > make sure these developers know we appreciate their efforts. These > people would be happier if the work shipped in 3.5 as opposed to 3.6 so > it got into user's hands sooner. I second that sentiment. But it strikes me that we're doing this because our release frequency is completely inadapted. If we had feature releases, say, every 6 or 9 months, the problem wouldn't really exist in the first place. Exceptions granted by the RM only tackle a very small portion of the problem, because the long delay before an accepted patch being in an official release *still* frustrates everyone, and the unpredictability of exceptions only makes things *more* frustrating for most players. Of course, it was pretty much shut down before: https://mail.python.org/pipermail/python-dev/2012-January/115619.html Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/donald%40stufft.io I’m in favor of releasing more often as well. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On May 27, 2015 at 10:32:47 AM, Barry Warsaw (ba...@python.org) wrote: > On May 27, 2015, at 06:34 PM, Nick Coghlan wrote: > > >I'd actually like to pursue a more nuanced view of what's permitted in > >maintenance releases, based on a combination of the language moratorium > >PEP, and an approach inspired by PEP 466, requiring that every feature > >added in a maintenance release be detectable through an attribute check on > >a module (with corresponding support in dependency checking tools). > > PEP 466 and Python 2.7 are a special case. I wouldn't want to adopt such > tactics in normal Python 3 releases. > > Imagine the nightmare of some poor library author who wants to make sure their > package works with Python 3.6. They're faced with a source release of 3.6.5, > but 3.6.3 in Ubuntu, 3.6.4 in Fedora, 3.6.2 in Debian, and users of all > stripes of patch releases on Windows and OS X. Now they have to pepper their > code with attribute tests just to support "Python 3.6". In fact, claiming > support for Python 3.6 actually doesn't convey enough information to their > users. > > Sure, we can limit this to new features, but even new features introduce risk. > We've decided to accept this risk for Python 2.7 for good and important > reasons, but we shouldn't do the same for ongoing normal releases. > > >The problem with simply speeding up the release cycle without constraining > >the interim releases in some way is that it creates significant pain for > >alternate implementations and for downstream redistributors (many of whom > >are still dealing with the fallout of the Python 3 transition). > > I'm not convinced that relaxing the maintenance release constraints lessens > the pain for anybody. > > Cheers, > -Barry > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io > I think it increases the pain for everyone TBH. I find the backport we did to Python 2.7 pretty crummy, but I think the only thing worse than backporting to a random patch release of 2.7 was not making it available to the 2.x line at all. I think that it would have been better to release it as a 2.8, however that was a hill I felt like dying on personally. Going forward I think we should either stick to the slower release schedule and just say it is what it is or release more often. The inbetween is killer. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
Antoine Pitrou writes: > For some reason it sounds like we should be altruistic towards > people who are not :-) There's always a question of how far to go, of course, but one of the things I like about this community is the attention the developers give to others' pain. In that sense, I'm definitely +1 on altruism. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Embedded Python. Debug Version and _ctypes
Hi! I'm trying to use embedding of Python in my program. Simple C-program, compiled in Debug, that uses py-script that just imports "ctypes" gives me an error about "no module named "_ctypes". How to compile python lib in Visual Studio statically with ctypes support? Or how to use shared ctypes lib in debug mode? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Embedded Python. Debug Version and _ctypes
This mailing list is for the development *of *Python, not *with* it. The best place to ask this would be on python-l...@python.org. On Wed, May 27, 2015 at 1:08 PM Uladzimir Kryvian wrote: > Hi! > I'm trying to use embedding of Python in my program. > > Simple C-program, compiled in Debug, that uses py-script that just > imports "ctypes" gives me an error about "no module named "_ctypes". > > How to compile python lib in Visual Studio statically with ctypes > support? Or how to use shared ctypes lib in debug mode? > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/brett%40python.org > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On 5/27/2015 4:16 AM, Antoine Pitrou wrote: I second that sentiment. But it strikes me that we're doing this because our release frequency is completely inadapted. If we had feature releases, say, every 6 or 9 months, the problem wouldn't really exist in the first place. How about a feature release once a year, on a schedule we choose as best for us. For instance, aim for end of May, with a bugfix release and alpha of the next version mid to late Sept after summer vacations. Encourage linux distributions to include the new version in their fall and spring releases. Features that miss a beta1 deadline would then be available to early adopters 4 months later. In general, I think alpha releases have usually been about as good as bugfix releases. High test coverage and green buildbots help. With more frequent releases, there should be fewer major new features and perhaps fewer alpha and beta releases needed. Exceptions granted by the RM only tackle a very small portion of the problem, because the long delay before an accepted patch being in an official release *still* frustrates everyone, and the unpredictability of exceptions only makes things *more* frustrating for most players. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] time-based releases (was Re: Preserving the definition order of class namespaces.)
On May 27, 2015, at 05:15 PM, Terry Reedy wrote: >How about a feature release once a year, on a schedule we choose as best for >us. We discussed timed releases ages ago and they were rejected by the majority. Time-based releases can make a lot of sense, especially if the interval is short enough. If a feature doesn't make it into the May 2015 release, oh well, there will be another one in X months. Ubuntu has had a lot of success with X=6 time-based releases. That's not to say there aren't plenty of logistics to work out, or that they are a panacea, or even that they would work with an all-volunteer developer community. But time-based releases do have advantages too, and maybe those would outweigh the disadvantages for Python at this point. Cheers, -Barry ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] time-based releases (was Re: Preserving the definition order of class namespaces.)
On Wed, May 27, 2015 at 2:34 PM, Barry Warsaw wrote: > On May 27, 2015, at 05:15 PM, Terry Reedy wrote: > > >How about a feature release once a year, on a schedule we choose as best > for > >us. > > We discussed timed releases ages ago and they were rejected by the > majority. > Time-based releases can make a lot of sense, especially if the interval is > short enough. If a feature doesn't make it into the May 2015 release, oh > well, there will be another one in X months. > > Ubuntu has had a lot of success with X=6 time-based releases. That's not > to > say there aren't plenty of logistics to work out, or that they are a > panacea, > or even that they would work with an all-volunteer developer community. > But > time-based releases do have advantages too, and maybe those would outweigh > the > disadvantages for Python at this point. > This favors developers (who want to see their feature launched) and early adopters (who want to try out shiny new features). The current system (release every 18-24 months) was established when users who were decidedly not early adopters started complaining about the breakneck pace of Python releases. It's quite possible that the current crop of Python users are less averse to change (although the conversion rate to Python 3 seems to indicate otherwise). But it's also hard to compare Ubuntu (which is a roll-up of thousands of different open-source projects, with a large variety of different release schedules) to Python (which is a single, centrally-controlled code base). What do other projects that are at most 1 order of magnitude smaller or larger than Python do? E.g. the Linux kernel, or Mysql, or Qt? -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Preserving the definition order of class namespaces.
On Wed, 27 May 2015 17:15:39 -0400 Terry Reedy wrote: > On 5/27/2015 4:16 AM, Antoine Pitrou wrote: > > > I second that sentiment. But it strikes me that we're doing this > > because our release frequency is completely inadapted. If we had > > feature releases, say, every 6 or 9 months, the problem wouldn't really > > exist in the first place. > > How about a feature release once a year, on a schedule we choose as best > for us. For instance, aim for end of May, with a bugfix release and > alpha of the next version mid to late Sept after summer vacations. > Encourage linux distributions to include the new version in their fall > and spring releases. > > Features that miss a beta1 deadline would then be available to early > adopters 4 months later. In general, I think alpha releases have > usually been about as good as bugfix releases. I don't believe alpha releases are attractive for most users. People don't want to risk losing time over bugs that may be caused by regressions in Python. Regardless of their *actual* stability or quality, releases labelled "alpha" are perceived as high-risk. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] time-based releases (was Re: Preserving the definition order of class namespaces.)
On 28 May 2015 07:48, "Guido van Rossum" wrote: > > On Wed, May 27, 2015 at 2:34 PM, Barry Warsaw wrote: >> >> On May 27, 2015, at 05:15 PM, Terry Reedy wrote: >> >> >How about a feature release once a year, on a schedule we choose as best for >> >us. >> >> We discussed timed releases ages ago and they were rejected by the majority. >> Time-based releases can make a lot of sense, especially if the interval is >> short enough. If a feature doesn't make it into the May 2015 release, oh >> well, there will be another one in X months. >> >> Ubuntu has had a lot of success with X=6 time-based releases. That's not to >> say there aren't plenty of logistics to work out, or that they are a panacea, >> or even that they would work with an all-volunteer developer community. But >> time-based releases do have advantages too, and maybe those would outweigh the >> disadvantages for Python at this point. > > > This favors developers (who want to see their feature launched) and early adopters (who want to try out shiny new features). > > The current system (release every 18-24 months) was established when users who were decidedly not early adopters started complaining about the breakneck pace of Python releases. > > It's quite possible that the current crop of Python users are less averse to change (although the conversion rate to Python 3 seems to indicate otherwise). But it's also hard to compare Ubuntu (which is a roll-up of thousands of different open-source projects, with a large variety of different release schedules) to Python (which is a single, centrally-controlled code base). > > What do other projects that are at most 1 order of magnitude smaller or larger than Python do? E.g. the Linux kernel, or Mysql, or Qt? The Linux kernel iterates fairly rapidly, with redistributors agreeing on which versions to target for long term support. Decent overview here: https://ltsi.linuxfoundation.org/what-is-ltsi I don't think the comparison really works though, because it's not just redistributors that are affected, it's alternate implementations of the language specification, as well as educational materials. If we got to merge gating on trunk, such that it was feasible to release 3.6dev1 within 6 months of the 3.5 release, then that might be a way of satisfying both crowds, since it would be a matter of speeding up the pre-release cycle and increasing the stability expectations for pre-releases, minimising the ripple effects on other parts of the ecosystem. Regards, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] time-based releases (was Re: Preserving the definition order of class namespaces.)
On 28 May 2015 08:31, "Nick Coghlan" wrote: > > > On 28 May 2015 07:48, "Guido van Rossum" wrote: > > > > On Wed, May 27, 2015 at 2:34 PM, Barry Warsaw wrote: > >> > >> On May 27, 2015, at 05:15 PM, Terry Reedy wrote: > >> > >> >How about a feature release once a year, on a schedule we choose as best for > >> >us. > >> > >> We discussed timed releases ages ago and they were rejected by the majority. > >> Time-based releases can make a lot of sense, especially if the interval is > >> short enough. If a feature doesn't make it into the May 2015 release, oh > >> well, there will be another one in X months. > >> > >> Ubuntu has had a lot of success with X=6 time-based releases. That's not to > >> say there aren't plenty of logistics to work out, or that they are a panacea, > >> or even that they would work with an all-volunteer developer community. But > >> time-based releases do have advantages too, and maybe those would outweigh the > >> disadvantages for Python at this point. > > > > > > This favors developers (who want to see their feature launched) and early adopters (who want to try out shiny new features). > > > > The current system (release every 18-24 months) was established when users who were decidedly not early adopters started complaining about the breakneck pace of Python releases. > > > > It's quite possible that the current crop of Python users are less averse to change (although the conversion rate to Python 3 seems to indicate otherwise). But it's also hard to compare Ubuntu (which is a roll-up of thousands of different open-source projects, with a large variety of different release schedules) to Python (which is a single, centrally-controlled code base). > > > > What do other projects that are at most 1 order of magnitude smaller or larger than Python do? E.g. the Linux kernel, or Mysql, or Qt? > > The Linux kernel iterates fairly rapidly, with redistributors agreeing on which versions to target for long term support. > > Decent overview here: https://ltsi.linuxfoundation.org/what-is-ltsi > > I don't think the comparison really works though, because it's not just redistributors that are affected, it's alternate implementations of the language specification, as well as educational materials. > > If we got to merge gating on trunk, such that it was feasible to release 3.6dev1 within 6 months of the 3.5 release, then that might be a way of satisfying both crowds, since it would be a matter of speeding up the pre-release cycle and increasing the stability expectations for pre-releases, minimising the ripple effects on other parts of the ecosystem. I just remembered one of the biggest causes of pain: Windows binaries for projects that aren't using the stable ABI. It used to regularly take 6+ months for the Windows ecosystem to catch up after each 2.x release. Since community project version compatibility time spans tend to be on the order of 3 years (exceptional cases like 2.6 & 2.7 aside), we need to consider: * are we happy increasing that support matrix from 2 versions to 6? * if we tell third party community projects to only test against and provide prebuilt binaries for the less frequent LTS releases, how useful would they really be over switching from the current alpha/beta/rc pre-release cycle to a time based merge gated dev release cycle followed by a beta/rc cycle? After all, the real difference between the alphas and the final releases isn't about anything *we* do, it's about the testing *other people* do that picks up gaps in our test coverage. A gated trunk makes it more feasible for other projects to do continuous integration against it. Cheers, Nick. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Computed Goto dispatch for Python 2
On 28 May 2015 at 10:17, Parasa, Srinivas Vamsi < srinivas.vamsi.par...@intel.com> wrote: > Hi All, > > > > This is Vamsi from Server Scripting Languages Optimization team at Intel > Corporation. > > > > Would like to submit a request to enable the computed goto based dispatch > in Python 2.x (which happens to be enabled by default in Python 3 given its > performance benefits on a wide range of workloads). We talked about this > patch with Guido and he encouraged us to submit a request on Python-dev > (email conversation with Guido shown at the bottom of this email). > +1 from me, for basically the same reasons Guido gives: Python 2.7 is going to be with us for a long time, and this particular change shouldn't have any externally visible impacts at either an ABI or API level. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Computed Goto dispatch for Python 2
> On May 27, 2015, at 6:31 PM, Nick Coghlan wrote: > > On 28 May 2015 at 10:17, Parasa, Srinivas Vamsi > wrote: > Hi All, > > > > This is Vamsi from Server Scripting Languages Optimization team at Intel > Corporation. > > > > Would like to submit a request to enable the computed goto based dispatch in > Python 2.x (which happens to be enabled by default in Python 3 given its > performance benefits on a wide range of workloads). We talked about this > patch with Guido and he encouraged us to submit a request on Python-dev > (email conversation with Guido shown at the bottom of this email). > > > +1 from me, for basically the same reasons Guido gives: Python 2.7 is going > to be with us for a long time, and this particular change shouldn't have any > externally visible impacts at either an ABI or API level. +1 from me a well. We probably should have done this long ago. Raymond Hettinger ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Issue 24285: regression for importing extensions in packages
This issue has been fixed, but a day or two late for 3.5b1. It prevents loading the coverage.py extension. It'd be great to get a new beta release soon. :) --Ned. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 24285: regression for importing extensions in packages
On 28 May 2015 at 12:51, Ned Batchelder wrote: > This issue has been fixed, but a day or two late for 3.5b1. Aye, we only found out about the missing test case via feedback *on* the beta. We had never needed to worry about it before, but it turns out all our extension modules in the standard library are top level modules and we didn't previously have an explicit test for the submodule case :( > It prevents > loading the coverage.py extension. It'd be great to get a new beta release > soon. :) Until your email, I hadn't fully thought through the consequences, but the bug is actually going to block a *lot* of potential testing of the beta release - anything that requires a C extension module that isn't a top level module isn't going to work with 3.5b1. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 24285: regression for importing extensions in packages
On 2015-05-27 11:02 PM, Nick Coghlan wrote: >It prevents >loading the coverage.py extension. It'd be great to get a new beta release >soon. :) Until your email, I hadn't fully thought through the consequences, but the bug is actually going to block a*lot* of potential testing of the beta release - anything that requires a C extension module that isn't a top level module isn't going to work with 3.5b1. It would also be great to release the new beta shortly with the new OrderedDict implemented in C and math.isclose(). Yury ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 24285: regression for importing extensions in packages
Nick Coghlan schrieb am 28.05.2015 um 05:02: > On 28 May 2015 at 12:51, Ned Batchelder wrote: >> This issue has been fixed, but a day or two late for 3.5b1. > > Aye, we only found out about the missing test case via feedback *on* > the beta. We had never needed to worry about it before, but it turns > out all our extension modules in the standard library are top level > modules and we didn't previously have an explicit test for the > submodule case :( > >> It prevents >> loading the coverage.py extension. It'd be great to get a new beta release >> soon. :) > > Until your email, I hadn't fully thought through the consequences, but > the bug is actually going to block a *lot* of potential testing of the > beta release - anything that requires a C extension module that isn't > a top level module isn't going to work with 3.5b1. +1 for a quick beta 2 from me, too (obviously). I've already seen a bug report because a Cython compiled package doesn't work in Py3.5. Having to tell them to wait a while for beta 2 is annoying and discouraging for early testers. Stefan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 24285: regression for importing extensions in packages
On 05/27/2015 07:51 PM, Ned Batchelder wrote: This issue has been fixed, but a day or two late for 3.5b1. It prevents loading the coverage.py extension. It'd be great to get a new beta release soon. :) http://legacy.python.org/dev/peps/pep-0478/ //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 24285: regression for importing extensions in packages
On 28 May 2015 at 14:30, Larry Hastings wrote: > On 05/27/2015 07:51 PM, Ned Batchelder wrote: > > This issue has been fixed, but a day or two late for 3.5b1. It prevents > loading the coverage.py extension. It'd be great to get a new beta release > soon. :) > > > http://legacy.python.org/dev/peps/pep-0478/ Aye, it's the long gap from May 24 (3.5b1) to July 5 (3.5b2) that we were hoping to see shortened if it was possible to get the release team together. The fact folks can't currently import extension modules that aren't at top level is unfortunately going to limit the amount of 3.5b1 testing the community can do in those 6 weeks :( Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Computed Goto dispatch for Python 2
On 5/27/2015 9:31 PM, Nick Coghlan wrote: +1 from me, for basically the same reasons Guido gives: Python 2.7 is going to be with us for a long time, and this particular change shouldn't have any externally visible impacts at either an ABI or API level. Immediately after a release, giving the patch plenty of time to be be tested, seems like a good time. -- Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 24285: regression for importing extensions in packages
On Wed, May 27, 2015 at 9:54 PM, Nick Coghlan wrote: > > On 28 May 2015 at 14:30, Larry Hastings wrote: > > On 05/27/2015 07:51 PM, Ned Batchelder wrote: > > > > This issue has been fixed, but a day or two late for 3.5b1. It prevents > > loading the coverage.py extension. It'd be great to get a new beta release > > soon. :) > > > > > > http://legacy.python.org/dev/peps/pep-0478/ > > Aye, it's the long gap from May 24 (3.5b1) to July 5 (3.5b2) that we > were hoping to see shortened if it was possible to get the release > team together. > > The fact folks can't currently import extension modules that aren't at > top level is unfortunately going to limit the amount of 3.5b1 testing > the community can do in those 6 weeks :( Just chiming in to confirm that yep, numpy (and thus the whole numerical stack) are also missing on 3.5b1. Of course this was filed as a bug report on numpy :-): https://github.com/numpy/numpy/issues/5915 I guess the good news is that people are in fact testing the beta, but it sounds like pretty much the only code running on b1 is pure Python code whose entire dependency chain is also pure Python code. On the upside, compatibility between PyPy and CPython has improved greatly ;-). -n -- Nathaniel J. Smith -- http://vorpus.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 24285: regression for importing extensions in packages
On 05/27/2015 08:02 PM, Nick Coghlan wrote: On 28 May 2015 at 12:51, Ned Batchelder wrote: This issue has been fixed, but a day or two late for 3.5b1. Aye, we only found out about the missing test case via feedback *on* the beta. We had never needed to worry about it before, but it turns out all our extension modules in the standard library are top level modules and we didn't previously have an explicit test for the submodule case :( Well, certainly this sounds like something that needs to go into the regression test suite. Can someone create the issue? ... and the patch? //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Computed Goto dispatch for Python 2
Why now? We intentionally decided not to do this for 2.7 in the past because it was too late for the release cutoff. Has anyone benchmarked compiling python in profile-opt mode vs having the computed goto patch? I'd *expect* the benefits to be the roughly the same. Has this been compared to that? (Anyone not compiling their Python interpreter in profile-opt mode is doing themselves a major disservice.) Does it shows noteworthy improvements even when used with a profile-opt build using a PROFILE_TASK of regrtest.py with the same test exclusion list as the debian python2.7 package? Could you please rerun benchmarks including the profile-opt build with and without the patch for comparsion. -gps PS I recommend attaching the up to date patch against 2.7.10 to issue4753. That is where anyone will go looking for it, not buried in a mailing list archive. On Wed, May 27, 2015 at 10:01 PM Terry Reedy wrote: > On 5/27/2015 9:31 PM, Nick Coghlan wrote: > > > +1 from me, for basically the same reasons Guido gives: Python 2.7 is > > going to be with us for a long time, and this particular change > > shouldn't have any externally visible impacts at either an ABI or API > level. > > Immediately after a release, giving the patch plenty of time to be be > tested, seems like a good time. > > -- > Terry Jan Reedy > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/greg%40krypto.org > ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Issue 24285: regression for importing extensions in packages
On 05/27/2015 10:35 PM, Larry Hastings wrote: Well, certainly this sounds like something that needs to go into the regression test suite. Can someone create the issue? ... and the patch? NM, the existing fix already added a test to the regression test suite. I should have read the issue first! //arry/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
