Re: [Python-Dev] benchmark

2013-09-18 Thread Victor Stinner 
Oops, I wanted to send the patch to myself, not to the python-dev
mailing list, sorry :-)

(It's a set of patch to try to optimize the tracemalloc module.)

Victor

2013/9/18 Victor Stinner :
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 450 adding statistics module

2013-09-18 Thread Antoine Pitrou 
Le Tue, 17 Sep 2013 14:40:21 -0700,
Ethan Furman  a écrit :
> On 09/17/2013 02:21 PM, Guido van Rossum wrote:
> > Congrats, I've accepted the PEP. Nice work! Please work with the
> > reviewers on the issue on the code.
> 
> Congratulations, Stephen!

Or Steven even ;)


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 428: Pathlib -> stat caching

2013-09-18 Thread Antoine Pitrou 
Le Tue, 17 Sep 2013 18:10:53 -0700,
Philip Jenvey  a écrit :
> 
> On Sep 16, 2013, at 1:05 PM, Antoine Pitrou wrote:
> 
> > On Mon, 16 Sep 2013 15:48:54 -0400
> > Brett Cannon  wrote:
> >>> 
> >>> So I would like to propose the following API change:
> >>> 
> >>> - Path.stat() (and stat-accessing methods such as get_mtime()...)
> >>>  returns an uncached stat object by default
> >>> 
> >>> - Path.cache_stat() can be called to return the stat() *and*
> >>> cache it for future use, such that any future call to stat(),
> >>> cache_stat() or a stat-accessing function reuses that cached stat
> >>> 
> >>> In other words, only if you use cache_stat() at least once is the
> >>> stat() value cached and reused by the Path object.
> >>> (also, it's a per-Path decision)
> >>> 
> >> 
> >> Any reason why stat() can't get a keyword-only cached=True argument
> >> instead? Or have stat() never cache() but stat_cache() always so
> >> that people can choose if they want fresh or cached based on API
> >> and not whether some library happened to make a decision for them?
> > 
> > 1. Because you also want the helper functions (get_mtime(), etc.) to
> > cache the value too. It's not only about stat().
> 
> With the proposed rich stat object the convenience methods living on
> Path wouldn't result in much added convenience:
> 
> p.is_dir() vs p.stat().is_dir()

One reason is that the proposed rich stat object doesn't exist yet :-)

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] License() release list is imcomplete; intentional?

2013-09-18 Thread Georg Brandl 
On 09/17/2013 05:37 PM, Terry Reedy wrote:
> On 2.7, >>> license() return a text that includes a complete list of 
> releases from 1.6 to 2.7 and stops there
>  Release Derived YearOwner   GPL-
>  fromcompatible? (1)
> 
>  0.9.0 thru 1.2  1991-1995   CWI yes
>  1.3 thru 1.5.2  1.2 1995-1999   CNRIyes
>  1.6 1.5.2   2000CNRIno
>  2.0 1.6 2000BeOpen.com  no
> ...
>  2.6.5   2.6.4   2010PSF yes
>  2.7 2.6 2010PSF yes
> 
> Was it intentional to stop with 2.7 and not continue with 2.7.1, etc?
> 
> On 3.3.2, the 2.x list ends with 2.6.5 and never mentions 2.7. Intentional?
> It then jumps back to 3.0 and ends with the 'previous' release, 3.3.1. 
> Should 3.3.2 be included in the 3.3.2 list?
> 
> ...
>  2.6.4   2.6.3   2009PSF yes
>  2.6.5   2.6.4   2010PSF yes
>  3.0 2.6 2008PSF yes
>  3.0.1   3.0 2009PSF yes
> ...
>  3.2.4   3.2.3   2013PSF yes
>  3.3.0   3.2 2012PSF yes
>  3.3.1   3.3.0   2013PSF yes

Since there are 3 versions of this table, it's unavoidable that one of them
gets out of sync :)

* LICENSE
* Doc/license.rst
* the versions for each release on the website

So I wholeheartedly support truncating before 2.2 (which is the first
release where all micro versions are PSF owned and GPL compatible) and
just saying "2.2 onwards" (or whatever is the best way to say it).

cheers,
Georg

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 450 adding statistics module

2013-09-18 Thread Ethan Furman 

On 09/18/2013 01:26 AM, Antoine Pitrou wrote:

Le Tue, 17 Sep 2013 14:40:21 -0700,
Ethan Furman  a écrit :

On 09/17/2013 02:21 PM, Guido van Rossum wrote:

Congrats, I've accepted the PEP. Nice work! Please work with the
reviewers on the issue on the code.


Congratulations, Stephen!


Or Steven even ;)


*sigh*  I used to be a good speller, too!

--
~Ethan~
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

2013-09-18 Thread Martin v. Löwis 
Am 18.09.13 08:43, schrieb Gregory P. Smith:
> Just drop support for 10.6 with Python 3.4. Problem solved. People on
> that old of a version of the OS can build their own Python 3.4 or do the
> right thing and upgrade or just install Linux.
> 
> This isn't Windows. Compiler tool chains are freely available for the
> legacy platform. We don't need to maintain such a long legacy support
> tail there ourselves.

I don't mind such a decision in principle, but also in principle, I'd
prefer if there was a pre-set policy to decide this question, documented
in PEP 11.

Here a piece of OSX release history:
- 10.5:   October 2007
  * 10.5.8:   August 2009
- 10.6:   August 2009
  * 10.6.8:   July 2011
- 10.7:   July 2011
  * 10.7.5:   July 2012
- 10.8:   July 2012

So possible policy that would now exclude 10.6 for binary installers
would be:

- only the two latest feature releases are supported
- only feature releases younger than 3 years are supported

Note that a separate policy should be added to decide whether support
for older versions is actively removed from source code (or equally
bug fixes for old versions are not accepted anymore).

Regards,
Martin

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

2013-09-18 Thread Martin v. Löwis 
Am 15.09.13 00:56, schrieb Ryan:
> +1. A 10.6-only build makes sense.

I'd like to support Russell's point: this could put a burden on everyone
releasing extension modules to also provide two binary releases, which
e.g. would then mess up downloads from PyPI. So -1.

+0 on dropping 10.6 support from the binary installers as proposed
by Greg.

Regards,
Martin

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

2013-09-18 Thread Antoine Pitrou 
Le Wed, 18 Sep 2013 14:54:32 +0200,
"Martin v. Löwis"  a écrit :
> Am 18.09.13 08:43, schrieb Gregory P. Smith:
> > Just drop support for 10.6 with Python 3.4. Problem solved. People
> > on that old of a version of the OS can build their own Python 3.4
> > or do the right thing and upgrade or just install Linux.
> > 
> > This isn't Windows. Compiler tool chains are freely available for
> > the legacy platform. We don't need to maintain such a long legacy
> > support tail there ourselves.
> 
> I don't mind such a decision in principle, but also in principle, I'd
> prefer if there was a pre-set policy to decide this question,
> documented in PEP 11.
> 
> Here a piece of OSX release history:
> - 10.5:   October 2007
>   * 10.5.8:   August 2009
> - 10.6:   August 2009
>   * 10.6.8:   July 2011
> - 10.7:   July 2011
>   * 10.7.5:   July 2012
> - 10.8:   July 2012

This means that any Mac shipped pre-July 2011 has 10.6 or lower?
I know Mac users are fashion victims, but 2011 doesn't sound that old
to me ;-)
(it's even younger than Barry!)

Regards

Antoine.


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

2013-09-18 Thread Ronald Oussoren 
On Sep 18, 2013, at 03:36 PM, Antoine Pitrou  wrote:Le Wed, 18 Sep 2013 14:54:32 +0200, "Martin v. Löwis"  a écrit :Am 18.09.13 08:43, schrieb Gregory P. Smith:> Just drop support for 10.6 with Python 3.4. Problem solved. People> on that old of a version of the OS can build their own Python 3.4> or do the right thing and upgrade or just install Linux.>> This isn't Windows. Compiler tool chains are freely available for> the legacy platform. We don't need to maintain such a long legacy> support tail there ourselves.I don't mind such a decision in principle, but also in principle, I'dprefer if there was a pre-set policy to decide this question,documented in PEP 11.Here a piece of OSX release history:- 10.5: October 2007* 10.5.8: August 2009- 10.6: August 2009* 10.6.8: July 2011- 10.7: July 2011* 10.7.5: July 2012- 10.8: July 2012 This means that any Mac shipped pre-July 2011 has 10.6 or lower? I know Mac users are fashion victims, but 2011 doesn't sound that old to me ;-) (it's even younger than Barry!) That's correct, and IMHO it is too early to drop support for 10.6 and doubly so when it is only done to use a newer compiler for the binary build.Still-using-10.5-in-production-ly yours,    Ronald  Regards  Antoine.   ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

2013-09-18 Thread Russell Owen 
I agree that a policy is a good idea, and I suggest it be primarily based on 
age, since we cannot assume Apple will release new versions of the OS on a 
given timeline.

I personally think too early to drop support for MacOS X 10.6 and am on the 
edge about 10.5.

-- Russell

On Sep 18, 2013, at 5:54 AM, "Martin v. Löwis"  wrote:

> Am 18.09.13 08:43, schrieb Gregory P. Smith:
>> Just drop support for 10.6 with Python 3.4. Problem solved. People on
>> that old of a version of the OS can build their own Python 3.4 or do the
>> right thing and upgrade or just install Linux.
>> 
>> This isn't Windows. Compiler tool chains are freely available for the
>> legacy platform. We don't need to maintain such a long legacy support
>> tail there ourselves.
> 
> I don't mind such a decision in principle, but also in principle, I'd
> prefer if there was a pre-set policy to decide this question, documented
> in PEP 11.
> 
> Here a piece of OSX release history:
> - 10.5:   October 2007
>  * 10.5.8:   August 2009
> - 10.6:   August 2009
>  * 10.6.8:   July 2011
> - 10.7:   July 2011
>  * 10.7.5:   July 2012
> - 10.8:   July 2012
> 
> So possible policy that would now exclude 10.6 for binary installers
> would be:
> 
> - only the two latest feature releases are supported
> - only feature releases younger than 3 years are supported
> 
> Note that a separate policy should be added to decide whether support
> for older versions is actively removed from source code (or equally
> bug fixes for old versions are not accepted anymore).
> 
> Regards,
> Martin
> 

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

2013-09-18 Thread Ronald Oussoren 
On Sep 18, 2013, at 03:03 PM, "Martin v. Löwis"  wrote:Am 15.09.13 00:56, schrieb Ryan:+1. A 10.6-only build makes sense. I'd like to support Russell's point: this could put a burden on everyone releasing extension modules to also provide two binary releases, which e.g. would then mess up downloads from PyPI. So -1.  +0 on dropping 10.6 support from the binary installers as proposed by Greg. Dropping support for 10.6 isn't really necessary, just build (carefully) on a later release of OSX (preferably the last one to pick up the most recent developer tools).   I'll try to provide a more detailed response tonight, but the basic idea is to use OSX 10.8, the current Xcode release and the OSX 10.8 SDK to do the build. This is a supported configuration for building binaries that target older OSX releases, but some care is needed with the configure script for 3th-party libraries: those might pick up features that aren't available in 10.6. Ronald  Regards, Martin  ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] License() release list is imcomplete; intentional?

2013-09-18 Thread Guido van Rossum 
OK. Let's do it.


On Wed, Sep 18, 2013 at 1:54 AM, Georg Brandl  wrote:

> On 09/17/2013 05:37 PM, Terry Reedy wrote:
> > On 2.7, >>> license() return a text that includes a complete list of
> > releases from 1.6 to 2.7 and stops there
> >  Release Derived YearOwner   GPL-
> >  fromcompatible? (1)
> >
> >  0.9.0 thru 1.2  1991-1995   CWI yes
> >  1.3 thru 1.5.2  1.2 1995-1999   CNRIyes
> >  1.6 1.5.2   2000CNRIno
> >  2.0 1.6 2000BeOpen.com  no
> > ...
> >  2.6.5   2.6.4   2010PSF yes
> >  2.7 2.6 2010PSF yes
> >
> > Was it intentional to stop with 2.7 and not continue with 2.7.1, etc?
> >
> > On 3.3.2, the 2.x list ends with 2.6.5 and never mentions 2.7.
> Intentional?
> > It then jumps back to 3.0 and ends with the 'previous' release, 3.3.1.
> > Should 3.3.2 be included in the 3.3.2 list?
> >
> > ...
> >  2.6.4   2.6.3   2009PSF yes
> >  2.6.5   2.6.4   2010PSF yes
> >  3.0 2.6 2008PSF yes
> >  3.0.1   3.0 2009PSF yes
> > ...
> >  3.2.4   3.2.3   2013PSF yes
> >  3.3.0   3.2 2012PSF yes
> >  3.3.1   3.3.0   2013PSF yes
>
> Since there are 3 versions of this table, it's unavoidable that one of them
> gets out of sync :)
>
> * LICENSE
> * Doc/license.rst
> * the versions for each release on the website
>
> So I wholeheartedly support truncating before 2.2 (which is the first
> release where all micro versions are PSF owned and GPL compatible) and
> just saying "2.2 onwards" (or whatever is the best way to say it).
>
> cheers,
> Georg
>
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

2013-09-18 Thread Skip Montanaro 
As a MacBook Pro user running Snow Leopard/10.6.8, I would find the
lack of a binary release problematic, were it not for the fact that I
routinely build from source (and don't do anything Mac-specific with
Python). For those not familiar with the platform, it's perhaps worth
noting that upgrade is out of my hands. Apple dropped support for my
"ancient" MBP (2006?), so 10.6.8 is as up-to-date as I can get. I
guess that's what you expect from a company whose main revenues these
days come from cell phones and tablets, and addition of pastels to
their color pallet warrants announcement in a TV commercial.

I suspect other Mac users stuck on Snow Leopard who are not Python
developers would rue the lack of binary installers more than me.

Skip
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

2013-09-18 Thread Stephen J. Turnbull 
Skip Montanaro writes:

 > I suspect other Mac users stuck on Snow Leopard who are not Python
 > developers would rue the lack of binary installers more than me.

Perhaps, but if Python current as of now isn't good enough for someone
for the foreseeable future, aren't they going to want up-to-date
libraries to backup the Python modules that use them, not to mention
security fixes and the like?  That's why I get my Python (for Snow
Leopard) from MacPorts.  I wouldn't hesitate to build it myself, but I
get timely upgrades from MacPorts so there's no need to bother.  I'd
be far less likely to upgrade quickly (for bugfix releases) if I had
to make a special trip to python.org for installers.

The MacPorts build could break at any time, I suppose, but at least
for the moment there are alternatives to building it yourself.



___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

2013-09-18 Thread Bill Janssen 
Russell Owen  wrote:

> I agree that a policy is a good idea, and I suggest it be primarily based on 
> age, since we cannot assume Apple will release new versions of the OS on a 
> given timeline.
> 
> I personally think too early to drop support for MacOS X 10.6 and am on the 
> edge about 10.5.

I run one 10.5 machine, three 10.6 machines, and 5+ 10.7+ machines right
now.  I have a perfectly fine and fast Mac Pro which can't even be
upgraded past 10.7.  So using Apple's OS release numbers as the gating
factor might be a problem.

I'd be happy to drop pre-built binary installers for 10.6, but that's
different from dropping all support for it.

Bill

> -- Russell
> 
> On Sep 18, 2013, at 5:54 AM, "Martin v. Löwis"  wrote:
> 
> > Am 18.09.13 08:43, schrieb Gregory P. Smith:
> >> Just drop support for 10.6 with Python 3.4. Problem solved. People on
> >> that old of a version of the OS can build their own Python 3.4 or do the
> >> right thing and upgrade or just install Linux.
> >> 
> >> This isn't Windows. Compiler tool chains are freely available for the
> >> legacy platform. We don't need to maintain such a long legacy support
> >> tail there ourselves.
> > 
> > I don't mind such a decision in principle, but also in principle, I'd
> > prefer if there was a pre-set policy to decide this question, documented
> > in PEP 11.
> > 
> > Here a piece of OSX release history:
> > - 10.5:   October 2007
> >  * 10.5.8:   August 2009
> > - 10.6:   August 2009
> >  * 10.6.8:   July 2011
> > - 10.7:   July 2011
> >  * 10.7.5:   July 2012
> > - 10.8:   July 2012
> > 
> > So possible policy that would now exclude 10.6 for binary installers
> > would be:
> > 
> > - only the two latest feature releases are supported
> > - only feature releases younger than 3 years are supported
> > 
> > Note that a separate policy should be added to decide whether support
> > for older versions is actively removed from source code (or equally
> > bug fixes for old versions are not accepted anymore).
> > 
> > Regards,
> > Martin
> > 
> 
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/bill%40janssen.org
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

2013-09-18 Thread Ned Deily 
Thank you all for your comments so far on this subject.  I have noted 
two separate issues raised here: one, how to build the Pythons provided 
by binary installers to get optimum performance (i.e. use more recent 
compilers); and, two, what OS X releases should we support with binary 
installers.  As I noted earlier, I've opened Issue19019 and I will 
update it with concrete proposals when we've complete the necessary 
testing and fixing of various build configurations, including of the 
sort Ronald and I outlined.  If you are interested in the details of 
this, please move that discussion to the bug tracker.

As to point two, I will put a stake in the ground here and declare that 
we will continue to support 10.6 with 3.4 batteries-included installers.  
For various reasons, 10.6 remains surprisingly popular (at a recent 
Python hackathon meetup in San Francisco, every person I helped who had 
a Mac was running 10.6) and it is not that old even by Apple standards.  
There are tradeoffs in how best to provide that support.  Among those 
tradeoffs are the impacts to those who provide binary packages for 
extension modules and third-party libraries, as Russell notes.  Again, 
after investigating and testing the nitty-gritty details, if it seems 
that a change in how we provide installers is warranted, we can discuss 
that on Issue19019 and report back here prior to any final decision.  
Also, at that time, it would be appropriate to consider a policy for 
long-term support of OS X releases; it's a bit premature to do so now.

-- 
 Ned Deily,
 [email protected]

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

2013-09-18 Thread Stephen J. Turnbull 
Skip Montanaro writes:

 > > That's why I get my Python (for Snow Leopard) from MacPorts.
 > 
 > Unless things have changed, that probably doesn't support Mac-specific
 > stuff, does it?

You mean in the Python port or in general?  MacPorts supports
Mac-specific APIs in a number of ports where upstream does.

In Python, I don't know.  I would assume that anything python.org
supports is supported by MacPorts, though.



___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

2013-09-18 Thread Skip Montanaro 
> That's why I get my Python (for Snow Leopard) from MacPorts.

Unless things have changed, that probably doesn't support Mac-specific
stuff, does it?

I was thinking more of non-developer users who are likely to need/want
Mac-specific interfaces for tools which are written in Python. That
might just shift the burden to the developers of such tools. My guess
is that there is a domino effect. Apple stops supporting Snow Leopard,
which, all other things considered, forces third-party developers who
use Python in their products to stop supporting it, which then
pressures their users to buy new hardware so they can run newer
versions of those developers' tools.  This is good for Apple, but
creates headaches and monetary costs for developers and users
downstream.

S
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

2013-09-18 Thread Ned Deily 
In article <[email protected]>,
 "Stephen J. Turnbull"  wrote:
> Skip Montanaro writes:
>  > > That's why I get my Python (for Snow Leopard) from MacPorts.
>  > Unless things have changed, that probably doesn't support Mac-specific
>  > stuff, does it?
> You mean in the Python port or in general?  MacPorts supports
> Mac-specific APIs in a number of ports where upstream does.
> 
> In Python, I don't know.  I would assume that anything python.org
> supports is supported by MacPorts, though.

Yes, there are no significant differences in feature support between a 
python.org Python and a MacPorts-supplied Python or a Homebrew-supplied 
Python or a Fink-supplied Python.  If you are doing any sort of a 
hard-core Python development work that requires the use of third-party C 
libraries et al, you are probably better off using a complete solution, 
including Python, from one of the above big-three package managers for 
OS X.  If you need to support multiple versions of OS X, IME, MacPorts 
does the best job of supporting older versions (I have up-to-date 
MacPorts installations on OS X 10.4 through 10.9).

But the primary mission for python.org installers is somewhat different: 
provide up-to-date, easy-to-install, batteries-included Pythons for 
users who are not necessarily experienced with Python itself.  People 
who need development environments with significant third-party libraries 
not included with Python or OS X itself are often better served by 
either investing in the time to set up and become familiar with using 
one of the general open source distributors (MacPorts, Homebrew, et al) 
or by using a specialized Python distribution (e.g. for scientific 
users).

-- 
 Ned Deily,
 [email protected]

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] License() release list is imcomplete; intentional?

2013-09-18 Thread Georg Brandl 
Now tracked at http://bugs.python.org/issue19043

Georg

On 09/18/2013 04:57 PM, Guido van Rossum wrote:
> OK. Let's do it.
> 
> 
> On Wed, Sep 18, 2013 at 1:54 AM, Georg Brandl  > wrote:
> 
> On 09/17/2013 05:37 PM, Terry Reedy wrote:
> > On 2.7, >>> license() return a text that includes a complete list of
> > releases from 1.6 to 2.7 and stops there
> >  Release Derived YearOwner   GPL-
> >  fromcompatible? (1)
> >
> >  0.9.0 thru 1.2  1991-1995   CWI yes
> >  1.3 thru 1.5.2  1.2 1995-1999   CNRIyes
> >  1.6 1.5.2   2000CNRIno
> >  2.0 1.6 2000BeOpen.com  no
> > ...
> >  2.6.5   2.6.4   2010PSF yes
> >  2.7 2.6 2010PSF yes
> >
> > Was it intentional to stop with 2.7 and not continue with 2.7.1, etc?
> >
> > On 3.3.2, the 2.x list ends with 2.6.5 and never mentions 2.7. 
> Intentional?
> > It then jumps back to 3.0 and ends with the 'previous' release, 3.3.1.
> > Should 3.3.2 be included in the 3.3.2 list?
> >
> > ...
> >  2.6.4   2.6.3   2009PSF yes
> >  2.6.5   2.6.4   2010PSF yes
> >  3.0 2.6 2008PSF yes
> >  3.0.1   3.0 2009PSF yes
> > ...
> >  3.2.4   3.2.3   2013PSF yes
> >  3.3.0   3.2 2012PSF yes
> >  3.3.1   3.3.0   2013PSF yes
> 
> Since there are 3 versions of this table, it's unavoidable that one of 
> them
> gets out of sync :)
> 
> * LICENSE
> * Doc/license.rst
> * the versions for each release on the website
> 
> So I wholeheartedly support truncating before 2.2 (which is the first
> release where all micro versions are PSF owned and GPL compatible) and
> just saying "2.2 onwards" (or whatever is the best way to say it).
> 
> cheers,
> Georg
> 
> ___
> Python-Dev mailing list
> [email protected] 
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
> 
> 
> 
> 
> -- 
> --Guido van Rossum (python.org/~guido )
> 
> 


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

2013-09-18 Thread Barry Warsaw 
On Sep 18, 2013, at 10:04 AM, Skip Montanaro wrote:

>As a MacBook Pro user running Snow Leopard/10.6.8, I would find the
>lack of a binary release problematic, were it not for the fact that I
>routinely build from source (and don't do anything Mac-specific with
>Python). For those not familiar with the platform, it's perhaps worth
>noting that upgrade is out of my hands. Apple dropped support for my
>"ancient" MBP (2006?), so 10.6.8 is as up-to-date as I can get. I
>guess that's what you expect from a company whose main revenues these
>days come from cell phones and tablets, and addition of pastels to
>their color pallet warrants announcement in a TV commercial.

I'm in a similar boat with my old MBP, and I am not upgrading my somewhat
newer one because of compatibility with other software.  But OTOH, I have
never installed the binary releases, I just build them from MacPorts, so as
long as that still works, I'm happy.  (I have a 8mo Air running the latest
Lion and will likely update that when Mavericks is out.)

-Barry
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (2.6): #14984: only import pwd on POSIX.

2013-09-18 Thread Barry Warsaw 
On Sep 18, 2013, at 03:00 PM, r.david.murray wrote:

>http://hg.python.org/cpython/rev/fb3ad8a749c8
>changeset:   85749:fb3ad8a749c8
>branch:  2.6
>parent:  85735:1b673e0fd8f3
>user:R David Murray 
>date:Wed Sep 18 08:49:25 2013 -0400
>summary:
>  #14984: only import pwd on POSIX.
>
>files:
>  Lib/netrc.py |  4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
>
>
>diff --git a/Lib/netrc.py b/Lib/netrc.py
>--- a/Lib/netrc.py
>+++ b/Lib/netrc.py
>@@ -2,7 +2,9 @@
> 
> # Module and documentation by Eric S. Raymond, 21 Dec 1998
> 
>-import os, stat, shlex, pwd
>+import os, stat, shlex
>+if os.name == 'posix':
>+import pwd

Would it make more sense to do:

try:
import pwd
except ImportError:
pwd = None

?
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-checkins] cpython (2.6): #14984: only import pwd on POSIX.

2013-09-18 Thread R. David Murray 
On Wed, 18 Sep 2013 21:38:48 -0400, Barry Warsaw  wrote:
> On Sep 18, 2013, at 03:00 PM, r.david.murray wrote:
> 
> >http://hg.python.org/cpython/rev/fb3ad8a749c8
> >changeset:   85749:fb3ad8a749c8
> >branch:  2.6
> >parent:  85735:1b673e0fd8f3
> >user:R David Murray 
> >date:Wed Sep 18 08:49:25 2013 -0400
> >summary:
> >  #14984: only import pwd on POSIX.
> >
> >files:
> >  Lib/netrc.py |  4 +++-
> >  1 files changed, 3 insertions(+), 1 deletions(-)
> >
> >
> >diff --git a/Lib/netrc.py b/Lib/netrc.py
> >--- a/Lib/netrc.py
> >+++ b/Lib/netrc.py
> >@@ -2,7 +2,9 @@
> > 
> > # Module and documentation by Eric S. Raymond, 21 Dec 1998
> > 
> >-import os, stat, shlex, pwd
> >+import os, stat, shlex
> >+if os.name == 'posix':
> >+import pwd
> 
> Would it make more sense to do:
> 
> try:
> import pwd
> except ImportError:
> pwd = None

I don't think so.  The code that uses pwd is protected by an 'if os.name
== 'posix' as well.  I think that's clearer than setting pwd to none
and guarding that section by 'if pwd'.  And in 3.4 I just moved the
import into the if block that uses it.

--David
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

2013-09-18 Thread Gregory P. Smith 
On Wed, Sep 18, 2013 at 6:38 AM, Ronald Oussoren wrote:

>
>
> On Sep 18, 2013, at 03:03 PM, "Martin v. Löwis" 
> wrote:
>
> Am 15.09.13 00:56, schrieb Ryan:
>
> +1. A 10.6-only build makes sense.
>
>
> I'd like to support Russell's point: this could put a burden on everyone
> releasing extension modules to also provide two binary releases, which
> e.g. would then mess up downloads from PyPI. So -1.
>
> +0 on dropping 10.6 support from the binary installers as proposed
> by Greg.
>
>
>
> Dropping support for 10.6 isn't really necessary, just build (carefully)
> on a later release of OSX (preferably the last one to pick up the most
> recent developer tools).
>
> I'll try to provide a more detailed response tonight, but the basic idea
> is to use OSX 10.8, the current Xcode release and the OSX 10.8 SDK to do
> the build. This is a supported configuration for building binaries that
> target older OSX releases, but some care is needed with the configure
> script for 3th-party libraries: those might pick up features that aren't
> available in 10.6.
>
>
Cool, that sounds like we should _really_ be doing. Best of both worlds and
it'll give a much faster to build to everyone. Good luck!

-gps
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com