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
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
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
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
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
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
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/
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
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
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
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
> 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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
31 matches
Mail list logo
