Re: [Python-Dev] Unable to build regex module against Python 3.5 32-bit

2015-05-27 Thread Nick Coghlan
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/v

Re: [Python-Dev] Preserving the definition order of class namespaces.

2015-05-27 Thread Antoine Pitrou
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 d

Re: [Python-Dev] Unable to build regex module against Python 3.5 32-bit

2015-05-27 Thread Paul Moore
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 curr

Re: [Python-Dev] Preserving the definition order of class namespaces.

2015-05-27 Thread Nick Coghlan
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 co

Re: [Python-Dev] Preserving the definition order of class namespaces.

2015-05-27 Thread Antoine Pitrou
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 mainten

Re: [Python-Dev] Preserving the definition order of class namespaces.

2015-05-27 Thread Nick Coghlan
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

Re: [Python-Dev] Preserving the definition order of class namespaces.

2015-05-27 Thread Barry Warsaw
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

Re: [Python-Dev] Preserving the definition order of class namespaces.

2015-05-27 Thread Donald Stufft
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

Re: [Python-Dev] Preserving the definition order of class namespaces.

2015-05-27 Thread Donald Stufft
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 approac

Re: [Python-Dev] Preserving the definition order of class namespaces.

2015-05-27 Thread Stephen J. Turnbull
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 def

[Python-Dev] Embedded Python. Debug Version and _ctypes

2015-05-27 Thread Uladzimir Kryvian
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 l

Re: [Python-Dev] Embedded Python. Debug Version and _ctypes

2015-05-27 Thread Brett Cannon
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

Re: [Python-Dev] Preserving the definition order of class namespaces.

2015-05-27 Thread Terry Reedy
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 re

[Python-Dev] time-based releases (was Re: Preserving the definition order of class namespaces.)

2015-05-27 Thread Barry Warsaw
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.

Re: [Python-Dev] time-based releases (was Re: Preserving the definition order of class namespaces.)

2015-05-27 Thread Guido van Rossum
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 releas

Re: [Python-Dev] Preserving the definition order of class namespaces.

2015-05-27 Thread Antoine Pitrou
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 probl

Re: [Python-Dev] time-based releases (was Re: Preserving the definition order of class namespaces.)

2015-05-27 Thread Nick Coghlan
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 an

Re: [Python-Dev] time-based releases (was Re: Preserving the definition order of class namespaces.)

2015-05-27 Thread Nick Coghlan
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

Re: [Python-Dev] Computed Goto dispatch for Python 2

2015-05-27 Thread Nick Coghlan
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 (wh

Re: [Python-Dev] Computed Goto dispatch for Python 2

2015-05-27 Thread Raymond Hettinger
> 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

[Python-Dev] Issue 24285: regression for importing extensions in packages

2015-05-27 Thread Ned Batchelder
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/list

Re: [Python-Dev] Issue 24285: regression for importing extensions in packages

2015-05-27 Thread Nick Coghlan
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 libr

Re: [Python-Dev] Issue 24285: regression for importing extensions in packages

2015-05-27 Thread Yury Selivanov
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 relea

Re: [Python-Dev] Issue 24285: regression for importing extensions in packages

2015-05-27 Thread Stefan Behnel
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 tur

Re: [Python-Dev] Issue 24285: regression for importing extensions in packages

2015-05-27 Thread Larry Hastings
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/

Re: [Python-Dev] Issue 24285: regression for importing extensions in packages

2015-05-27 Thread Nick Coghlan
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/pe

Re: [Python-Dev] Computed Goto dispatch for Python 2

2015-05-27 Thread Terry Reedy
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 p

Re: [Python-Dev] Issue 24285: regression for importing extensions in packages

2015-05-27 Thread Nathaniel Smith
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

Re: [Python-Dev] Issue 24285: regression for importing extensions in packages

2015-05-27 Thread Larry Hastings
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 a

Re: [Python-Dev] Computed Goto dispatch for Python 2

2015-05-27 Thread Gregory P. Smith
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

Re: [Python-Dev] Issue 24285: regression for importing extensions in packages

2015-05-27 Thread Larry Hastings
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 fi