Re: [Python-Dev] tp_finalize vs tp_del sematics

[Armin Rigo]

Hi Valentine,

On 24 August 2015 at 20:43, Valentine Sinitsyn
 wrote:
> So you mean that this was to keep things backwards compatible for
> third-party extensions? I haven't thought about it this way, but this makes
> sense. However, the behavior of Python code using objects with __del__ has
> changed nevertheless: they are collectible now, and __del__ is always called
> exactly once, if I understand everything correctly.

Yes, I think so.  There is a *highly obscure* corner case: __del__
will still be called several times if you declare your class with
"__slots__=()".


A bientôt,

Armin.
___
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] tp_finalize vs tp_del sematics

[Armin Rigo]

Hi Valentine,

On 25 August 2015 at 09:56, Valentine Sinitsyn
 wrote:
>> Yes, I think so.  There is a *highly obscure* corner case: __del__
>> will still be called several times if you declare your class with
>> "__slots__=()".
>
> Even on "post-PEP-0442" Python 3.4+? Could you share a link please?

class X(object):
__slots__=() # <= try with and without this
def __del__(self):
global revive
revive = self
print("hi")

X()
revive = None
revive = None
revive = None


--Armin
___
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] Profile Guided Optimization active by-default

[Eric Snow]

On Aug 24, 2015 3:51 PM, "Stewart, David C" 
wrote:
>
> (Sorry about the format here - I honestly just subscribed to Python-dev so
> be gentle ...)

:)

>
> > Date: Sat, 22 Aug 2015 11:25:59 -0600
> > From: Eric Snow 
>
> >On Aug 22, 2015 9:02 AM, "Patrascu, Alecsandru"  >intel.com >
> >wrote:[snip]> For instance, as shown from attached sample performance
> >results from theGrand Unified Python Benchmark, >20% speed up was
> >observed.
> >
> >
>
> Eric ­ I'm the manager of Intel's server scripting language optimization
> team, so I'll answer from that perspective.

Thanks, David!

>
> >Are you referring to the tests in the benchmarks repo? [1] How does the
> >real-world performance improvement compare with otherlanguages you are
> >targeting for optimization?
>
> Yes, we're using [1].
>
> We're seeing up to 10% improvement on Swift (a project in OpenStack) on
> some architectures using the ssbench workload, which is as close to
> real-world as we can get.

Cool.

> Relative to other languages we target, this is
> quite good actually. For example, Java's Hotspot JIT is driven by
> profiling at its core so it's hard to distinguish the value profiling
> alone brings.

Interesting.  So pypy (with it's profiling JIT) would be in a similar boat,
potentially.

> We have seen a nice boost on PHP running Wordpress using
> PGO, but not as impressive as Python and Swift.

Nice.  Presumably this reflects some of the choices we've made on the level
of complexity in the interpreter source.

>
> By the way, I think letting the compiler optimize the code is a good
> strategy. Not the only strategy we want to use, but it seems like one we
> could do more of.
>
> > And thanks for working on this!  I have several more questions: What
> >sorts of future changes in CPython's code might interfere with
> >youroptimizations?
> >
> >
>
> We're also looking at other source-level optimizations, like the CGOTO
> patch Vamsi submitted in June. Some of these may reduce the value of PGO,
> but in general it's nice to let the compiler do some optimization for you.
>
> > What future additions might stand to benefit?
> >
>
> It's a good question. Our intent is to continue to evaluate and measure
> different training workloads for improvement. In other words, as with any
> good open source project, this patch should improve things a lot and
> should be accepted upstream, but we will continue to make it better.
>
> > What changes in existing code might improve optimization opportunities?
> >
> >
>
> We intend to continue to work on source-level optimizations and measuring
> them against GUPB and Swift.

Thanks!  These sorts of contribution has far-reaching positive effects.

>
> > What is the added maintenance burden of the optimizations on CPython,
> >ifany?
> >
> >
>
> I think the answer is none. Our goal was to introduce performance
> improvements without adding to maintenance effort.
>
> >What is the performance impact on non-Intel architectures?  What
> >aboutolder Intel architectures?  ...and future ones?
> >
> >
>
> We should modify the patch to make it for Intel only, since we're not
> evaluating non-Intel architectures. Unfortunately for us, I suspect that
> older Intel CPUs might benefit more than current and future ones. Future
> architectures will benefit from other enabling work we're planning.

That's fine though.  At the least you're setting the stage for future work,
including building a relationship here.  :)

>
> > What is Intel's commitment to supporting these (or other) optimizations
> >inthe future?  How is the practical EOL of the optimizations managed?
> >
> >
>
> As with any corporation's budgeting process, it's hard to know exactly
> what my managers will let me spend money on. :-) But we're definitely
> convinced of the value of dynamic languages for servers and the need to
> work on optimization. As far as I have visibility, it appears to be
> holding true.

Sounds good.

>
> > Finally, +1 on adding an opt-in Makefile target rather than enabling
> >theoptimizations by default.
> >
> >
>
> Frankly since Ubuntu has been running this way for past two years, I think
> it's fine to make it opt-in, but eventually I hope it can be the default
> once we're happy with it.

Given the reaction here that sounds reasonable.

Thanks for answering these questions and to your team for getting involved!

-eric
___
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] Profile Guided Optimization active by-default

[Maciej Fijalkowski]

>
> Interesting.  So pypy (with it's profiling JIT) would be in a similar boat,
> potentially.
>

PGO and what pypy does have pretty much nothing to do with each other.
I'm not sure what do you mean by "similar boat"
___
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] django_v2 benchmark compatibility fix for Python 3.6

[Papa, Florin]

Hi All,

My name is Florin Papa and I work in the Server Languages Optimizations Team at 
Intel Corporation.

I would like to submit a patch that solves compatibility issues of the 
django_v2 benchmark in the Grand Unified Python Benchmark. The django_v2 
benchmark uses inspect.getargspec(), which is deprecated and was removed in 
Python 3.6. Therefore, it crashes with the message "ImportError: cannot import 
name 'getargspec'" when using the latest version of Python on the default 
branch.

The patch modifies the benchmark to use inspect.signature() when Python version 
is 3.6 or above and keep using inspect.getargspec() otherwise.

Regards,
Florin


django_v2_compat_3_6.patch
Description: django_v2_compat_3_6.patch
___
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] tp_finalize vs tp_del sematics

[Valentine Sinitsyn]

Hi Armin,

On 25.08.2015 12:51, Armin Rigo wrote:

Hi Valentine,

On 24 August 2015 at 20:43, Valentine Sinitsyn
 wrote:

So you mean that this was to keep things backwards compatible for
third-party extensions? I haven't thought about it this way, but this makes
sense. However, the behavior of Python code using objects with __del__ has
changed nevertheless: they are collectible now, and __del__ is always called
exactly once, if I understand everything correctly.


Yes, I think so.  There is a *highly obscure* corner case: __del__
will still be called several times if you declare your class with
"__slots__=()".

Even on "post-PEP-0442" Python 3.4+? Could you share a link please?

Thanks,
Valentine
___
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] tp_finalize vs tp_del sematics

[Valentine Sinitsyn]

Hi Armin,

On 25.08.2015 13:00, Armin Rigo wrote:

Hi Valentine,

On 25 August 2015 at 09:56, Valentine Sinitsyn
 wrote:

Yes, I think so.  There is a *highly obscure* corner case: __del__
will still be called several times if you declare your class with
"__slots__=()".


Even on "post-PEP-0442" Python 3.4+? Could you share a link please?


class X(object):
 __slots__=() # <= try with and without this
 def __del__(self):
 global revive
 revive = self
 print("hi")

X()
revive = None
revive = None
revive = None

Indeed, that's very strange. Looks like a bug IMHO. Thanks for pointing out.

Valentine
___
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] django_v2 benchmark compatibility fix for Python 3.6

[R. David Murray]

On Tue, 25 Aug 2015 13:11:37 -, "Papa, Florin"  
wrote:
> My name is Florin Papa and I work in the Server Languages Optimizations Team 
> at Intel Corporation.
> 
> I would like to submit a patch that solves compatibility issues of the 
> django_v2 benchmark in the Grand Unified Python Benchmark. The django_v2 
> benchmark uses inspect.getargspec(), which is deprecated and was removed in 
> Python 3.6. Therefore, it crashes with the message "ImportError: cannot 
> import name 'getargspec'" when using the latest version of Python on the 
> default branch.
> 
> The patch modifies the benchmark to use inspect.signature() when Python 
> version is 3.6 or above and keep using inspect.getargspec() otherwise.

Note that Papa has submitted the patch to the tracker:

http://bugs.python.org/issue24934

I'm not myself sure how we are maintaining that repo
(https://hg.python.org/benchmarks), but it does seem like the bug
tracker is the right place for such a patch.

--David
___
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] django_v2 benchmark compatibility fix for Python 3.6

[Terry Reedy]

On 8/25/2015 10:51 AM, R. David Murray wrote:

On Tue, 25 Aug 2015 13:11:37 -, "Papa, Florin"  
wrote:

My name is Florin Papa and I work in the Server Languages Optimizations Team at 
Intel Corporation.

I would like to submit a patch that solves compatibility issues of the django_v2 
benchmark in the Grand Unified Python Benchmark. The django_v2 benchmark uses 
inspect.getargspec(), which is deprecated and was removed in Python 3.6. Therefore, it 
crashes with the message "ImportError: cannot import name 'getargspec'" when 
using the latest version of Python on the default branch.

The patch modifies the benchmark to use inspect.signature() when Python version 
is 3.6 or above and keep using inspect.getargspec() otherwise.


Note that Papa has submitted the patch to the tracker:

 http://bugs.python.org/issue24934

I'm not myself sure how we are maintaining that repo
(https://hg.python.org/benchmarks), but it does seem like the bug
tracker is the right place for such a patch.


Is the django_v2 benchmark original to benchmarks, or a copy from django?

--
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] django_v2 benchmark compatibility fix for Python 3.6

[R. David Murray]

On Tue, 25 Aug 2015 11:18:54 -0400, Terry Reedy  wrote:
> On 8/25/2015 10:51 AM, R. David Murray wrote:
> > On Tue, 25 Aug 2015 13:11:37 -, "Papa, Florin"  
> > wrote:
> >> My name is Florin Papa and I work in the Server Languages Optimizations 
> >> Team at Intel Corporation.
> >>
> >> I would like to submit a patch that solves compatibility issues of the 
> >> django_v2 benchmark in the Grand Unified Python Benchmark. The django_v2 
> >> benchmark uses inspect.getargspec(), which is deprecated and was removed 
> >> in Python 3.6. Therefore, it crashes with the message "ImportError: cannot 
> >> import name 'getargspec'" when using the latest version of Python on the 
> >> default branch.
> >>
> >> The patch modifies the benchmark to use inspect.signature() when Python 
> >> version is 3.6 or above and keep using inspect.getargspec() otherwise.
> >
> > Note that Papa has submitted the patch to the tracker:
> >
> >  http://bugs.python.org/issue24934
> >
> > I'm not myself sure how we are maintaining that repo
> > (https://hg.python.org/benchmarks), but it does seem like the bug
> > tracker is the right place for such a patch.
> 
> Is the django_v2 benchmark original to benchmarks, or a copy from django?

Yeah, that's one question that was in my mind when I said I don't know
how we maintain that repo.  I'm pretty sure it was originally a copy of the
django project, but how do we maintain it?

--David
___
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] django_v2 benchmark compatibility fix for Python 3.6

[Brett Cannon]

On Tue, 25 Aug 2015 at 08:31 R. David Murray  wrote:

> On Tue, 25 Aug 2015 11:18:54 -0400, Terry Reedy  wrote:
> > On 8/25/2015 10:51 AM, R. David Murray wrote:
> > > On Tue, 25 Aug 2015 13:11:37 -, "Papa, Florin" <
> florin.p...@intel.com> wrote:
> > >> My name is Florin Papa and I work in the Server Languages
> Optimizations Team at Intel Corporation.
> > >>
> > >> I would like to submit a patch that solves compatibility issues of
> the django_v2 benchmark in the Grand Unified Python Benchmark. The
> django_v2 benchmark uses inspect.getargspec(), which is deprecated and was
> removed in Python 3.6. Therefore, it crashes with the message "ImportError:
> cannot import name 'getargspec'" when using the latest version of Python on
> the default branch.
> > >>
> > >> The patch modifies the benchmark to use inspect.signature() when
> Python version is 3.6 or above and keep using inspect.getargspec()
> otherwise.
> > >
> > > Note that Papa has submitted the patch to the tracker:
> > >
> > >  http://bugs.python.org/issue24934
> > >
> > > I'm not myself sure how we are maintaining that repo
> > > (https://hg.python.org/benchmarks), but it does seem like the bug
> > > tracker is the right place for such a patch.
> >
> > Is the django_v2 benchmark original to benchmarks, or a copy from django?
>
> Yeah, that's one question that was in my mind when I said I don't know
> how we maintain that repo.  I'm pretty sure it was originally a copy of the
> django project, but how do we maintain it?
>

It's maintained by primarily Antoine and me occasionally doing stuff to it.
=) Traditionally bugs have been reported to bugs.python.org.

As for the django_v2 benchmark, it was created by Unladen Swallow (it's v2
because it was updated to work with Django 1.5 so as to get Python 3
support for the benchmark). IOW it's out own benchmark and we can do
whatever we want with it.
___
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] Profile Guided Optimization active by-default

[Brett Cannon]

On Mon, 24 Aug 2015 at 23:19 Nick Coghlan  wrote:

> On 25 August 2015 at 05:52, Gregory P. Smith  wrote:
> > What we tested and decided to use on our own builds after benchmarking at
> > work was to build with:
> >
> > make profile-opt PROFILE_TASK="-m test.regrtest -w -uall,-audio -x
> test_gdb
> > test_multiprocessing"
> >
> > In general if a test is unreliable or takes an extremely long time,
> exclude
> > it for your sanity.  (i'd also kick out test_subprocess on 2.7; we
> replaced
> > subprocess with subprocess32 in our build so that wasn't an issue)
>
> Having the "production ready" make target be "make profile-opt"
> doesn't strike me as the most intuitive thing in the world.
>
> I agree we want the "./configure && make" sequence to be oriented
> towards local development builds rather than highly optimised
> production ones, so perhaps we could provide a "make production"
> target that enables PGO with an appropriate training set from
> regrtest, and also complains if "--with-pydebug" is configured?
>

That's an interesting idea for a make target. It might help get the
visibility of PGO builds higher as well.
___
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] Profile Guided Optimization active by-default

[R. David Murray]

On Tue, 25 Aug 2015 15:59:23 -, Brett Cannon  wrote:
> On Mon, 24 Aug 2015 at 23:19 Nick Coghlan  wrote:
> 
> > On 25 August 2015 at 05:52, Gregory P. Smith  wrote:
> > > What we tested and decided to use on our own builds after benchmarking at
> > > work was to build with:
> > >
> > > make profile-opt PROFILE_TASK="-m test.regrtest -w -uall,-audio -x
> > test_gdb
> > > test_multiprocessing"
> > >
> > > In general if a test is unreliable or takes an extremely long time,
> > exclude
> > > it for your sanity.  (i'd also kick out test_subprocess on 2.7; we
> > replaced
> > > subprocess with subprocess32 in our build so that wasn't an issue)
> >
> > Having the "production ready" make target be "make profile-opt"
> > doesn't strike me as the most intuitive thing in the world.
> >
> > I agree we want the "./configure && make" sequence to be oriented
> > towards local development builds rather than highly optimised
> > production ones, so perhaps we could provide a "make production"
> > target that enables PGO with an appropriate training set from
> > regrtest, and also complains if "--with-pydebug" is configured?
> >
> 
> That's an interesting idea for a make target. It might help get the
> visibility of PGO builds higher as well.

If we did want to make PGO the default, having a 'make develop' target
would also be an option.  We already have a precedent for that in the
'setup.py develop' command.

--David
___
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] Profile Guided Optimization active by-default

[Brett Cannon]

On Tue, 25 Aug 2015 at 09:10 R. David Murray  wrote:

> On Tue, 25 Aug 2015 15:59:23 -, Brett Cannon  wrote:
> > On Mon, 24 Aug 2015 at 23:19 Nick Coghlan  wrote:
> >
> > > On 25 August 2015 at 05:52, Gregory P. Smith  wrote:
> > > > What we tested and decided to use on our own builds after
> benchmarking at
> > > > work was to build with:
> > > >
> > > > make profile-opt PROFILE_TASK="-m test.regrtest -w -uall,-audio -x
> > > test_gdb
> > > > test_multiprocessing"
> > > >
> > > > In general if a test is unreliable or takes an extremely long time,
> > > exclude
> > > > it for your sanity.  (i'd also kick out test_subprocess on 2.7; we
> > > replaced
> > > > subprocess with subprocess32 in our build so that wasn't an issue)
> > >
> > > Having the "production ready" make target be "make profile-opt"
> > > doesn't strike me as the most intuitive thing in the world.
> > >
> > > I agree we want the "./configure && make" sequence to be oriented
> > > towards local development builds rather than highly optimised
> > > production ones, so perhaps we could provide a "make production"
> > > target that enables PGO with an appropriate training set from
> > > regrtest, and also complains if "--with-pydebug" is configured?
> > >
> >
> > That's an interesting idea for a make target. It might help get the
> > visibility of PGO builds higher as well.
>
> If we did want to make PGO the default, having a 'make develop' target
> would also be an option.  We already have a precedent for that in the
> 'setup.py develop' command.
>

With a `make develop` target we also can make sure not only that
--with-pydebug is used but that the installation target is /tmp so that new
contributors don't accidentally install a debug build.
___
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] Profile Guided Optimization active by-default

[Xavier Combelle]

Pardon me if I'm not in the right place to ask the following naive
question. (say me if it's the case)

Does Profile Guided Optimization performance improvements are specific to
the chip where the built is done or the performance is better on a larger
set of chips?
___
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] Profile Guided Optimization active by-default

[Gregory P. Smith]

PGO is unrelated to the particular CPU the profiling is done on. (It is
conceivable that it'd make a small difference but I've never observed that
in practice)

On Tue, Aug 25, 2015, 9:28 AM Xavier Combelle 
wrote:

Pardon me if I'm not in the right place to ask the following naive
question. (say me if it's the case)

Does Profile Guided Optimization performance improvements are specific to
the chip where the built is done or the performance is better on a larger
set of chips?
___
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] Profile Guided Optimization active by-default

[Gregory P. Smith]

On Mon, Aug 24, 2015, 11:19 PM Nick Coghlan  wrote:

On 25 August 2015 at 05:52, Gregory P. Smith  wrote:
> What we tested and decided to use on our own builds after benchmarking at
> work was to build with:
>
> make profile-opt PROFILE_TASK="-m test.regrtest -w -uall,-audio -x
test_gdb
> test_multiprocessing"
>
> In general if a test is unreliable or takes an extremely long time,
exclude
> it for your sanity.  (i'd also kick out test_subprocess on 2.7; we
replaced
> subprocess with subprocess32 in our build so that wasn't an issue)

Having the "production ready" make target be "make profile-opt"
doesn't strike me as the most intuitive thing in the world.

I agree we want the "./configure && make" sequence to be oriented
towards local development builds rather than highly optimised
production ones, so perhaps we could provide a "make production"
target that enables PGO with an appropriate training set from
regrtest, and also complains if "--with-pydebug" is configured?


Regards,
Nick.

--
Nick Coghlan   |   ncoghlan@ gmail.com
   |   Brisbane, Australia


Agreed. Also, printing a message out at the end of a default make all build
suggesting people use make production for additional performance instead
might help advertise it.

make install could possibly depend on make production as well?
___
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] Profile Guided Optimization active by-default

[Patrascu, Alecsandru]

Indeed, as Gregory well mentioned, PGO is unrelated to a particular CPU on 
which we do profiling.

From: Python-Dev 
[mailto:python-dev-bounces+alecsandru.patrascu=intel@python.org] On Behalf 
Of Gregory P. Smith
Sent: Tuesday, August 25, 2015 7:44 PM
To: Xavier Combelle; python-dev@python.org
Subject: Re: [Python-Dev] Profile Guided Optimization active by-default

PGO is unrelated to the particular CPU the profiling is done on. (It is 
conceivable that it'd make a small difference but I've never observed that in 
practice)
On Tue, Aug 25, 2015, 9:28 AM Xavier Combelle  wrote:
Pardon me if I'm not in the right place to ask the following naive question. 
(say me if it's the case)
Does Profile Guided Optimization performance improvements are specific to the 
chip where the built is done or the performance is better on a larger set of 
chips?


___
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] Building Extensions for Python 3.5 on Windows

[Steve Dower]

I've written up a long technical blog post about the compiler and CRT 
changes in Python 3.5, which will be of interest to those who build and 
distribute native extensions for Windows.


http://stevedower.id.au/blog/building-for-python-3-5/

Hopefully it puts some of the changes we've made into a context where 
they don't just look like unnecessary pain. Feedback and discussion 
welcome, either on these lists or on the post itself.


Cheers,
Steve
___
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] Profile Guided Optimization active by-default

[Skip Montanaro]

On Tue, Aug 25, 2015 at 11:17 AM, Brett Cannon  wrote:

> With a `make develop` target we also can make sure not only that
> --with-pydebug is used but that the installation target is /tmp so that new
> contributors don't accidentally install a debug build.


You need to be careful there. In my environment, I interface with a lot of
Boost.Python-wrapped code which would be quite impractical to compile with
--with-pydebug. I'd like to be able to throw in all the other development
bells and whistles though, without changing the size of the object header.
Maybe "develop-lite"?

-ly, y'rs,

Skip
___
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] [RELEASED] Python 3.5.0rc2 is now available

[Larry Hastings]

On behalf of the Python development community and the Python 3.5 release 
team, I'm relieved to announce the availability of Python 3.5.0rc2, also 
known as Python 3.5.0 Release Candidate 2.


Python 3.5 has now entered "feature freeze".  By default new features 
may no longer be added to Python 3.5.


This is a preview release, and its use is not recommended for production 
settings.



You can find Python 3.5.0rc2 here:

https://www.python.org/downloads/release/python-350rc2/

Windows and Mac users: please read the important platform-specific 
"Notes on this release" section near the end of that page.



Happy hacking,


//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] Building Extensions for Python 3.5 on Windows

[Terry Reedy]

On 8/25/2015 2:17 PM, Steve Dower wrote:

I've written up a long technical blog post about the compiler and CRT
changes in Python 3.5, which will be of interest to those who build and
distribute native extensions for Windows.

http://stevedower.id.au/blog/building-for-python-3-5/

Hopefully it puts some of the changes we've made into a context where
they don't just look like unnecessary pain. Feedback and discussion
welcome, either on these lists or on the post itself.


This is an excellent technical writeup. Can it be linked to from the 
devguide, or maybe the C-API docs, if they do not contain everything in 
the post?


--
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