Re: [Python-Dev] [Pydotorg] Should we help pythonmac.org?

[fuzzyman]

> Bill Janssen wrote:
>>> I strongly recommend that we *NOT* make macports.org the main,
>>> official Mac OS X version of Python. Secondary is fine, but not
>>> primary. Macports is what the name says: it's a system of Mac ports of
>>> Linux packages, mostly command-line only.
>>
>> I agree with David about this.
>>
>>> The official Mac Python should be an OS X application, with an icon,
>>> living in /Applications, ideally with a Mac-standard editor app  (the
>>> 2.5.1 I have has IDLE), etc.
>>
>> No, probably not.  Frankly, I think the official Mac Python should be
>> (and is) /usr/bin/python, the version that Apple ships with the
>> system.  I always try to make my stuff work with that Python, instead
>> of installing a different version, which in my experience usually
>> leads to grief somewhere down the road.
>>
> I've certainly heard many tales of Mac users coming to grief because
> they decided to overwrite their system Python, or tried to be clever and
> run multiple interpreters (which is usually somewhat less disastrous).
>

The Mac system depends a lot on stuff that comes installed with the system
version of Python - including specific versions of Twisted etc.

I *thought* (relative Mac newbie), the standard advice was that if you
want to install extension modules then you should install your own version
of Python and not mess with the system version.

Meaning that you have to maintain two Python installs - something that
hasn't been a problem for me yet. So even if Mac OS ships with Python 2.6,
many users will still want to install their own version.

The default page for Python on the Mac is horribly out of date:
http://python.org/download/mac/

No mention of Leopard.

Michael

> I guess this underlines the fact that Apple don't really want the hoi
> polloi tinkering with their systems; it's somewhat tedious when code is
> released for later Python versions and you have to privately backport,
> though, isn't it?
>
> There have been hints dropped that if the 2.6 release hits its deadline
> it will be incorporated into vendor builds. Let's hope one of them is
> MacOS, then at least it'll be relatively up to date.
>
> regards
>   Steve
> --
> Steve Holden+1 571 484 6266   +1 800 494 3119
> Holden Web LLC  http://www.holdenweb.com/
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
>

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Should we help pythonmac.org?

[Ronald Oussoren]

My two cents: the link to pythonmac.org should be removed, especially  
for downloading an installer for Python. The main 2.5.x download pages  
already have a binary installer for OSX (10.3.9 or later), the copy on  
pythonmac.org is just that: an (outdated) copy of the installer on the  
main python.org download page.


There's also a collection of installers for various packages (such as  
PIL) on there, which make it easy to install such packages without  
trying to build them yourself and without pulling in all of macports  
or fink. Sadly enough that package collection doesn't seem to be  
maintained at the moment.


Ronald

On 18 Aug, 2008, at 18:05, Guido van Rossum wrote:


Does anyone have connections with the owners of pythonmac.org?
Apparently they are serving up an ancient version of Python 2.5. The
Google App Engine has a minor issue in 2.5 that's solved in 2.5.1, but
that is apparently not available from that site. Perhaps we can
contribute more recent Mac versions, or provide them directly on
python.org? (The Downloads -> Macintosh page points to pythonmac.org,
which means lots of All Engine users download this old version.)

--
--Guido van Rossum (home: python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com


___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Pydotorg] Should we help pythonmac.org?

[Steve Holden]

Leonardo Santagada wrote:

-1 to use mac ports python as the base python

On 18/08/2008, at 22:18, Bill Janssen wrote:



The official Mac Python should be an OS X application, with an icon,
living in /Applications, ideally with a Mac-standard editor app  (the
2.5.1 I have has IDLE), etc.


No, probably not.  Frankly, I think the official Mac Python should be
(and is) /usr/bin/python, the version that Apple ships with the
system.  I always try to make my stuff work with that Python, instead
of installing a different version, which in my experience usually
leads to grief somewhere down the road.



I don't think this way, the official python should be the one from 
python.org, as it is on windows or there will be no point to make python 
2.5.1 and 2.5.2 (or any point release that is not incorporated in 
vendors builds).


The only grief I ever had in using the python from python.org is that I 
have to compile PyObjC from source, but this can be easily fixed.


Talking about this, why not just point pythonmac.org to python.org 
python version and release the packages as eggs on cheeseshop? 
(specially py2exe and pyobjc as those are usually heavily needed on macs).


I'm suspicious of any solution involving the word "just". I suppose we 
will "just" be able to recruit volunteers to maintain the additional 
content?


regards
 Steve
--
Steve Holden+1 571 484 6266   +1 800 494 3119
Holden Web LLC  http://www.holdenweb.com/

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Pydotorg] Should we help pythonmac.org?

[Fred Drake]

On Aug 19, 2008, at 3:45 AM, [EMAIL PROTECTED] wrote:

I *thought* (relative Mac newbie), the standard advice was that if you
want to install extension modules then you should install your own  
version

of Python and not mess with the system version.


My understanding is that if there is a system Python, you shouldn't  
change it.  Ever.


System Python's are for other components of the system; you can use  
them, but shouldn't modify them.  Including installing or updating  
packages in the site-packages directory.


At Zope Corporation, we use a clean Python for all development and  
deployments.  Nothing gets installed into the site-packages, because  
different applications want different packages (or different  
versions), and we want to deploy with what we test with.



Meaning that you have to maintain two Python installs - something that
hasn't been a problem for me yet. So even if Mac OS ships with  
Python 2.6,

many users will still want to install their own version.


Indeed.  I've never had to do anything to maintain the system Python  
on Mac OS X.  It's there, Mac OS X does what it will with it, and I  
use my private (and squeaky clean!) Python installations.



  -Fred

--
Fred Drake   

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Hanging out on freenode IRC #python-dev

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I will be hanging out as much as possible over the next two days on  
the #python-dev channel on freenode IRC.  If you have any last minute  
decisions you need, that will be the most immediate way to get in  
touch with me.


Modulo work commitments, I'm generally available from about 7am to  
about 7pm US Eastern (UTC -0400) time.


Cheers,
- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKrEGHEjvBPtnXfVAQKCZAP+JyldH4bq1MO/0s5cJYDIM1hKNuXTm488
Ys/scWaPb7zBGi5/+Wdbwmle82EAsl3SDH6yDzjzhvgHOkOdsvaCP2bbVaXzDQ2r
gOWs9jNBug/1HuGlaD3UPLehZ0I8Hy192XZz0o9z6jXmh7+ffbbDdyUW8x3D4IKX
+pu/DsL8EkY=
=+MNA
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] Beta 3 planned for this Wednesday

[Benjamin Peterson]

On Mon, Aug 18, 2008 at 10:29 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hello everyone,
>
> I am going to try to release the last planned beta of 2.6 and 3.0 this
> Wednesday.  Looking at the stable buildbots and showstopper bugs indicates
> some work to do between now and then.  Here are the showstoppers, along with
> my recommendations.
>
> 1878class attribute cache failure (regression)
> - - Medium priority
> - - Guido, there are some design choices that need your decision.  I'd like to
>  fix this for beta 3 if it's going to be fixed at all, because I suspect the
>  changes will be too disruptive once we reach release candidates.
>
> 2394[Py3k] Finish the memoryview object implementation
> - - High priority
> - - This one is serious enough to hold up the release.  I really do not think 
> we
>  should be finishing this implementation in the rc phase.

How finished is finished? I see Antoine has implemented a little more of it.

>
> 1179[CVE-2007-4965] Integer overflow in imageop module
> - - High priority
> - - This will block final release and I think it needs to be fixed for this 
> beta.

I've never used imageop, but I'll see if I can review the patch.

>
> 31312to3 can't find fixes_dir
> - - Medium priority
> - - I'm willing to defer this to the release candidates, but it will 
> definitely
>  block the release candidates.

This is pretty simple. There are patches that can be applied, but I
think 2to3 requires a little refactoring. I suppose that can be done
after the beta, though.

>
> 3402test_nis is hanging on Solaris
> - - Medium priority
> - - I suggest disabling this test and adding a note to the release notes.  If
>  nobody comes forward to fix it for the final release, tough.
>
> 3352Deficiencies in multiprocessing/threading API
> - - Medium priority
> - - This one is getting some love, so I'm confident this will get fixed before
>  beta 3.

Jesse said he could have it done today.
>
> As for the buildbots, they're not looking so good.  It looks like the trunk
> has various failures in multiprocessing (hopefully fixed soon) and bsddb3.
> Also some crashes in test_anydbm.  Hmm.
>
> 3.0 is looking better but there's a weird error in test_sys and
> test_threading.
>
> - -Barry
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFIqj4v2YZpQepbvXERAolaAJ4uydGlv5wP2/SrZt4HzROkWfQUeACcDyoJ
> 7DZW8MgxYKQMedhj7wJywDo=
> =oJk1
> -END PGP SIGNATURE-
> ___
> Python-3000 mailing list
> [EMAIL PROTECTED]
> http://mail.python.org/mailman/listinfo/python-3000
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-3000/musiccomposition%40gmail.com
>



-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Pydotorg] Should we help pythonmac.org?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Aug 19, 2008, at 8:51 AM, Fred Drake wrote:

My understanding is that if there is a system Python, you shouldn't  
change it.  Ever.


Huge, big, honkin' +1 from me on that.  Besides, for a system Python,  
you want your distribution to manage packages, not setuptools,  
otherwise you confuse -- and probably break -- your system.


As a corollary, a system Python script should never ever use #!/usr/ 
bin/env python as its first line.  It should always use /usr/bin/ 
python because that's the only thing it can guarantee it knows  
anything about.


I've had several discussions with distro vendors about this, some at  
Pycon and others I'm more intimately involved with .  I think  
there's general agreement about these principles, even if it's not  
always implemented correctly for every tool (but that's what bug  
reports are for :).


- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKrMhXEjvBPtnXfVAQKprwQAsuckU4jw5B+asnd6XNqCjuOuIDYRuv3w
sOlfn76qwoxaA9KJe7aCBOcoXpUnB4ibEm8O403LYV9izRXf62xgGdyVWTS73yEc
Sj6maoeIIO9ph7/p7eWT0Hl3pVmphsiLRgd7usyDSeRf+8ncXmE8Clr7i1vZ1rn+
fkFznLm7Kb0=
=xHHt
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] ImportError message suggestion

[Kent Tenney]

Howdy,

I brought this up on c.l.p., was encouraged to try it here.

http://groups.google.com/group/comp.lang.python/browse_thread/thread/88474a32877026fc/
==
from image import annotate
ImportError: cannot import name annotate

I found the problem via

import image
print image.__file__

which told me the wrong image module had been found.

It would be nice if ImportError announced this up front:

ImportError: cannot import name annotate from /usr//image.pyc
==

I got a bit of encouragement, and a patch from Wojtek Walczak
http://www.stud.umk.pl/~wojtekwa/patches/from-import-py2.5.1.patch

a bit more encouragement:
"I think the acceptance for this wouldn't be that hard since there is
no real issue for regression (the only one I could think of is for
doctest module, although I'm not sure there are any reason to test for
failed import in doctest)"

and a caveat:
"I have code that uses numpy if available, otherwise uses slower normal
Python code. Inside the doctests I'd like to test both situations..."

I can't write the C code myself, or evaluate the patch.

I think this change might save some other poor schlub the time
I've spent fussing with this issue.

Thanks,
Kent
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] Beta 3 planned for this Wednesday

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Aug 19, 2008, at 9:02 AM, Benjamin Peterson wrote:

On Mon, Aug 18, 2008 at 10:29 PM, Barry Warsaw <[EMAIL PROTECTED]>  
wrote:


1878class attribute cache failure (regression)
- - Medium priority
- - Guido, there are some design choices that need your decision.   
I'd like to
fix this for beta 3 if it's going to be fixed at all, because I  
suspect the

changes will be too disruptive once we reach release candidates.

2394[Py3k] Finish the memoryview object implementation
- - High priority
- - This one is serious enough to hold up the release.  I really do  
not think we

should be finishing this implementation in the rc phase.


How finished is finished? I see Antoine has implemented a little  
more of it.


The API needs to be completed.  If there are bugs, that's fine but we  
need to stabilize the API by the release candidate.  I just followed  
up on the issues and it looks like Antoine has a good handle on this.



1179[CVE-2007-4965] Integer overflow in imageop module
- - High priority
- - This will block final release and I think it needs to be fixed  
for this beta.


I've never used imageop, but I'll see if I can review the patch.


Great, thanks!


31312to3 can't find fixes_dir
- - Medium priority
- - I'm willing to defer this to the release candidates, but it  
will definitely

block the release candidates.


This is pretty simple. There are patches that can be applied, but I
think 2to3 requires a little refactoring. I suppose that can be done
after the beta, though.


Yep, but it should be done before rc1.


3402test_nis is hanging on Solaris
- - Medium priority
- - I suggest disabling this test and adding a note to the release  
notes.  If

nobody comes forward to fix it for the final release, tough.

3352Deficiencies in multiprocessing/threading API
- - Medium priority
- - This one is getting some love, so I'm confident this will get  
fixed before

beta 3.


Jesse said he could have it done today.


Excellent.

- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKrV1nEjvBPtnXfVAQLtXgP9HiHfxtbCPojQ1r6oMeou+7iWcedoBROL
BhtEEDxp74X8Bnnu8IfONMvQRL3I9wrktm6AztCKN8o9ZEAY5IlcFD4ICKM8f6My
kU5P6/ffJL7DgMyZSHh2w8p9lafNeH8tH1twy1hRWmh+jq8hkp1pgipYBCVqzSzp
iO3fKdhIGXk=
=IpIE
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Pydotorg] Should we help pythonmac.org?

[Jesse Noller]

On Tue, Aug 19, 2008 at 8:51 AM, Fred Drake <[EMAIL PROTECTED]> wrote:
> On Aug 19, 2008, at 3:45 AM, [EMAIL PROTECTED] wrote:
>>
>> I *thought* (relative Mac newbie), the standard advice was that if you
>> want to install extension modules then you should install your own version
>> of Python and not mess with the system version.
>
> My understanding is that if there is a system Python, you shouldn't change
> it.  Ever.
>
> System Python's are for other components of the system; you can use them,
> but shouldn't modify them.  Including installing or updating packages in the
> site-packages directory.
>
> At Zope Corporation, we use a clean Python for all development and
> deployments.  Nothing gets installed into the site-packages, because
> different applications want different packages (or different versions), and
> we want to deploy with what we test with.
>
>> Meaning that you have to maintain two Python installs - something that
>> hasn't been a problem for me yet. So even if Mac OS ships with Python 2.6,
>> many users will still want to install their own version.
>
> Indeed.  I've never had to do anything to maintain the system Python on Mac
> OS X.  It's there, Mac OS X does what it will with it, and I use my private
> (and squeaky clean!) Python installations.
>
>
>  -Fred
>
> --
> Fred Drake   

Just to add to this - with the advent of PEP 370[1], we now have the
ability to use per-user site-packages directories. This neatly
sidesteps the problem (for the most part) of tainting the system
installations of python directly.

As for the Mac issue - as a mac user/developer - I only install "big
ticket" packages into the system path - for everything else, I either
use virtualenv.py, a custom python install or the PYTHONPATH
overrides.

I've personally *never* used a python distribution from macports or
fink - if I need a custom build, I'll do it myself, rather than
install something into the /opt/ tree macports uses - I've had too
many issues with library/binary conflicts with the pre-installed
libraries/tools from twiddling with PATH and LD_LIBRARY_PATH to add
the /opt tree to my environment in order to get compiles/tools to play
nice.

-Jesse

[1] http://www.python.org/dev/peps/pep-0370/
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Pydotorg] Should we help pythonmac.org?

[Fred Drake]

[Removed pydotorg from the recipients; this has nothing to do with the  
website.]


On Aug 19, 2008, at 10:51 AM, Jesse Noller wrote:

Just to add to this - with the advent of PEP 370[1], we now have the
ability to use per-user site-packages directories. This neatly
sidesteps the problem (for the most part) of tainting the system
installations of python directly.


True.  This can help with newer Pythons.  It doesn't really deal with  
having multiple Python versions, IIRC.



As for the Mac issue - as a mac user/developer - I only install "big
ticket" packages into the system path - for everything else, I either
use virtualenv.py, a custom python install or the PYTHONPATH
overrides.


I've no idea what a "big ticket" package would be.  Using zc.buildout  
nicely sidesteps any issues of installing into the Python  
installation, and caches expensive builds.



I've personally *never* used a python distribution from macports or
fink - if I need a custom build, I'll do it myself, rather than
install something into the /opt/ tree macports uses - I've had too
many issues with library/binary conflicts with the pre-installed
libraries/tools from twiddling with PATH and LD_LIBRARY_PATH to add
the /opt tree to my environment in order to get compiles/tools to play
nice.



I'd go so far as to say that any reliance on LD_LIBRARY_PATH is a bad  
idea, since it's horribly fragile.  But I do link in the readline from  
macports.



  -Fred

--
Fred Drake   

___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] ImportError message suggestion

[Aahz]

On Tue, Aug 19, 2008, Kent Tenney wrote:
>
> I can't write the C code myself, or evaluate the patch.

Maybe not, but maybe you can upload them to the bug tracker -- that's
the only way this will get looked at.
-- 
Aahz ([EMAIL PROTECTED])   <*> http://www.pythoncraft.com/

Adopt A Process -- stop killing all your children!
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why does httplib import from test_support?

[Nick Coghlan]

Brett Cannon wrote:
> On Mon, Aug 18, 2008 at 11:55 AM, Fred Drake <[EMAIL PROTECTED]> wrote:
>> On Aug 18, 2008, at 2:43 PM, Antoine Pitrou wrote:
>>> If it's about silencing warnings, then how about putting it in the
>>> warnings
>>> module?
>>
>> That sounds good to me, and would be very reasonable.  This would make a
>> nice context manager.
>>
> 
> That works for me as well; just move catch_warning() to 'warnings' and
> leave test.test_support as-is. If we did that, though, I would want to
> make 'record' False by default so that it had more reasonable defaults
> for non-testing purposes.

Moving this single context manager over to warnings definitely makes
more sense to me than moving the whole test_support module.

It would also be easy enough to add a "catch_warning" factory function
in test_support that switched the default back to record=True so we
didn't have to change all of the invocations in the test suite.

Cheers,
Nick.

-- 
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] ImportError message suggestion

[Matt Giuca]

> ImportError: cannot import name annotate from /usr//image.pyc


That could be handy.

Not sure it's necessary, however, and exposes some system information in the
error message. I can imagine a web app which prints out exception messages,
and this would mean the server file structure is printed to the world
(though arguably you should not be doing this on your web app, I work on an
open source web app and we do dump tracebacks to our users sometimes --
because it's open source we don't mind them seeing the code -- but we'd
rather not have them see our server details).

If you do get this issue (as a developer), I find the built-in help()
function very handy -- you can import a module then go help(that_module) and
it tells you the absolute path to the module. That might be a sufficient
alternative to this patch (though requiring a bit more manual labour).

So I am neither for nor against this suggestion.

"I think the acceptance for this wouldn't be that hard since there is
> no real issue for regression (the only one I could think of is for
> doctest module, although I'm not sure there are any reason to test for
> failed import in doctest)"


I agree. (I'm more familiar with unittest than doctest, where you'd just use
assertRaises(ImportError, ...) and not care what the exception message is --
is there any way in doctest to check for the exception type without caring
about the message?)

I can't write the C code myself, or evaluate the patch.
>

Go to http://bugs.python.org/ and add a new issue. Upload the patch as an
attachment when you enter the issue description. I think you'll have to put
it down as a feature request for 2.7/3.1, since the beta tomorrow will mean
no more features in 2.6/3.0.

Matt
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Pydotorg] Should we help pythonmac.org?

[Bill Janssen]

> I've certainly heard many tales of Mac users coming to grief because 
> they decided to overwrite their system Python, or tried to be clever and 
> run multiple interpreters (which is usually somewhat less disastrous).
> 
> I guess this underlines the fact that Apple don't really want the hoi 
> polloi tinkering with their systems; it's somewhat tedious when code is 
> released for later Python versions and you have to privately backport, 
> though, isn't it?

I build lots of different versions of Python on my Macs, and it all
works fine.  I think people run into trouble when they try to
"replace" the system Python, in one way or another, for general use.
But if you want to bundle a different Python version in an app, or in
a framework-private bundle, it seems to be fine.

> There have been hints dropped that if the 2.6 release hits its deadline 
> it will be incorporated into vendor builds. Let's hope one of them is 
> MacOS, then at least it'll be relatively up to date.

Hah!  After spending years with Python 2.3 (for OS X 10.4), 2.5.1 is a
breath of fresh air.

Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] ImportError message suggestion

[Matt Giuca]

I think this is not the place to be discussing the patch (the tracker is),
but while I think of it, I'll just say:

You need to DECREF the fn variable (both
PyObject_GetAttrStringand
PyString_FromString
return new
references). If this makes no sense, read up on reference
counting (http://docs.python.org/ext/refcounts.html,
http://www.python.org/doc/api/countingRefs.html).


+PyString_AsString(name),
+ PyString_AsString(fn));
+   Py_DECREF(fn);
}

Also:

   - Do you really want "?" if you can't get the filename for some reason --
   why not just not say anything?
   - Perhaps don't create a new variable "fn", use one of the many defined
   at the top of the eval function.

Otherwise, looks like it will do the job.

But I haven't tested it, just eyeballed it.

Matt
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why does httplib import from test_support?

[Guido van Rossum]

On Tue, Aug 19, 2008 at 8:46 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
>> On Mon, Aug 18, 2008 at 11:55 AM, Fred Drake <[EMAIL PROTECTED]> wrote:
>>> On Aug 18, 2008, at 2:43 PM, Antoine Pitrou wrote:
 If it's about silencing warnings, then how about putting it in the
 warnings
 module?
>>>
>>> That sounds good to me, and would be very reasonable.  This would make a
>>> nice context manager.
>>>
>>
>> That works for me as well; just move catch_warning() to 'warnings' and
>> leave test.test_support as-is. If we did that, though, I would want to
>> make 'record' False by default so that it had more reasonable defaults
>> for non-testing purposes.
>
> Moving this single context manager over to warnings definitely makes
> more sense to me than moving the whole test_support module.

Works for me.

> It would also be easy enough to add a "catch_warning" factory function
> in test_support that switched the default back to record=True so we
> didn't have to change all of the invocations in the test suite.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Pydotorg] Should we help pythonmac.org?

[Bill Janssen]

> > My understanding is that if there is a system Python, you shouldn't  
> > change it.  Ever.
> 
> Huge, big, honkin' +1 from me on that.  Besides, for a system Python,  
> you want your distribution to manage packages, not setuptools,  
> otherwise you confuse -- and probably break -- your system.

I find this discussion fascinating.  I install new packages into my
system Python all the time, with "/usr/bin/python setup.py install",
and that includes setuptools.  I've got PIL, ReportLab, Twisted, Xlib,
appscript, docutils, email-4.0.1, fuse, PyLucene, medusa, mutagen,
roman, setuptools, and SSL installed in the Leopard machine I'm
writing from.  They don't wind up in
/System/Library/.../site-packages/, they wind up in
/Library/Python/2.5/site-packages/, which is sort of the right place,
from an Apple point of view.  I do this on lots of Macs -- I've got a
regular posse of them at work.  And I've never had any problems with
it.

I agree that there are some things I'd be very wary of installing into
the system Python, like PyObjC, and Zope.  Usually, I don't install
anything which appears to already be there.

Bill
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Pydotorg] Should we help pythonmac.org?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Aug 19, 2008, at 1:28 PM, Bill Janssen wrote:


My understanding is that if there is a system Python, you shouldn't
change it.  Ever.


Huge, big, honkin' +1 from me on that.  Besides, for a system Python,
you want your distribution to manage packages, not setuptools,
otherwise you confuse -- and probably break -- your system.


I find this discussion fascinating.  I install new packages into my
system Python all the time, with "/usr/bin/python setup.py install",
and that includes setuptools.  I've got PIL, ReportLab, Twisted, Xlib,
appscript, docutils, email-4.0.1, fuse, PyLucene, medusa, mutagen,
roman, setuptools, and SSL installed in the Leopard machine I'm
writing from.  They don't wind up in
/System/Library/.../site-packages/, they wind up in
/Library/Python/2.5/site-packages/, which is sort of the right place,
from an Apple point of view.  I do this on lots of Macs -- I've got a
regular posse of them at work.  And I've never had any problems with
it.

I agree that there are some things I'd be very wary of installing into
the system Python, like PyObjC, and Zope.  Usually, I don't install
anything which appears to already be there.


It probably affects OS X and Windows less than Linux distros like  
Gentoo or Ubuntu because the former don't heavily rely on the system  
python for their basic operation.   You can pretty royally screw up  
the latter if your Python environment isn't just right.


I think it's a /good/ thing that some OS distros are heavily invested  
in Python for their core operation.  We just need to understand the  
best practices when they are.


- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKsGoHEjvBPtnXfVAQLvoQP+K4DPZ2XyBZIR6IY9Tnf2c8hUm7+MNaVh
o6J0qLDm7XFVtQw6OhWd6zzRMLswFV86yojGvXb/rM8dwF8zIjrw4HZguIBxSIq8
e88zSNr713lTN/ds394bPkTC323+7QJEA/JOYNztAw2SUlvP7r1o67RDVptxlSvq
vrtb3VNl+7A=
=U4jT
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why does httplib import from test_support?

[Brett Cannon]

On Tue, Aug 19, 2008 at 8:46 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
>> On Mon, Aug 18, 2008 at 11:55 AM, Fred Drake <[EMAIL PROTECTED]> wrote:
>>> On Aug 18, 2008, at 2:43 PM, Antoine Pitrou wrote:
 If it's about silencing warnings, then how about putting it in the
 warnings
 module?
>>>
>>> That sounds good to me, and would be very reasonable.  This would make a
>>> nice context manager.
>>>
>>
>> That works for me as well; just move catch_warning() to 'warnings' and
>> leave test.test_support as-is. If we did that, though, I would want to
>> make 'record' False by default so that it had more reasonable defaults
>> for non-testing purposes.
>
> Moving this single context manager over to warnings definitely makes
> more sense to me than moving the whole test_support module.
>
> It would also be easy enough to add a "catch_warning" factory function
> in test_support that switched the default back to record=True so we
> didn't have to change all of the invocations in the test suite.
>

Right; just have a simple wrapper in test.test_support that had a
different default.

I will get to this when I can, although I am sure Barry won't be too
upset if this misses b3.

-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Why does httplib import from test_support?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Aug 19, 2008, at 2:31 PM, Brett Cannon wrote:

On Tue, Aug 19, 2008 at 8:46 AM, Nick Coghlan <[EMAIL PROTECTED]>  
wrote:

Brett Cannon wrote:

On Mon, Aug 18, 2008 at 11:55 AM, Fred Drake <[EMAIL PROTECTED]> wrote:

On Aug 18, 2008, at 2:43 PM, Antoine Pitrou wrote:

If it's about silencing warnings, then how about putting it in the
warnings
module?


That sounds good to me, and would be very reasonable.  This would  
make a

nice context manager.



That works for me as well; just move catch_warning() to 'warnings'  
and
leave test.test_support as-is. If we did that, though, I would  
want to
make 'record' False by default so that it had more reasonable  
defaults

for non-testing purposes.


Moving this single context manager over to warnings definitely makes
more sense to me than moving the whole test_support module.

It would also be easy enough to add a "catch_warning" factory  
function

in test_support that switched the default back to record=True so we
didn't have to change all of the invocations in the test suite.



Right; just have a simple wrapper in test.test_support that had a
different default.

I will get to this when I can, although I am sure Barry won't be too
upset if this misses b3.


Nope.
- -Barry

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)

iQCVAwUBSKsZd3EjvBPtnXfVAQLGRAQAhVwJLkwi/+ZlW7x53sKyyMEf+pJj7UTK
l0MjS/JFXlDmW5uBg9VnKbSrdMnbQPwHIhA1Xl20Pz3qV4mPTdrD6+pVuwyBQJj6
rakN6wtjvYMq3S3cDIZIabbaqx05XT5+mqWA+2fIc7/mzHboORtJmfAlE/Tjr4/P
TR7TgSqryzQ=
=TCYz
-END PGP SIGNATURE-
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] Beta 3 planned for this Wednesday

[Guido van Rossum]

On Mon, Aug 18, 2008 at 8:29 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> 1878class attribute cache failure (regression)
> - - Medium priority
> - - Guido, there are some design choices that need your decision.  I'd like to
>  fix this for beta 3 if it's going to be fixed at all, because I suspect the
>  changes will be too disruptive once we reach release candidates.

Resolved, see r65874.

> 2394[Py3k] Finish the memoryview object implementation
> - - High priority
> - - This one is serious enough to hold up the release.  I really do not think 
> we
>  should be finishing this implementation in the rc phase.

Can someone review Antoine's patch at http://codereview.appspot.com/3004 ?
It's above my head.

> 1179[CVE-2007-4965] Integer overflow in imageop module
> - - High priority
> - - This will block final release and I think it needs to be fixed for this 
> beta.

I'll look into this. Didn't we have a patch?

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Pydotorg] Should we help pythonmac.org?

[Jack Jansen]

On  19-Aug-2008, at 19:28 , Bill Janssen wrote:


My understanding is that if there is a system Python, you shouldn't
change it.  Ever.


Huge, big, honkin' +1 from me on that.  Besides, for a system Python,
you want your distribution to manage packages, not setuptools,
otherwise you confuse -- and probably break -- your system.


I find this discussion fascinating.  I install new packages into my
system Python all the time, with "/usr/bin/python setup.py install",
and that includes setuptools.  I've got PIL, ReportLab, Twisted, Xlib,
appscript, docutils, email-4.0.1, fuse, PyLucene, medusa, mutagen,
roman, setuptools, and SSL installed in the Leopard machine I'm
writing from.  They don't wind up in
/System/Library/.../site-packages/, they wind up in
/Library/Python/2.5/site-packages/, which is sort of the right place,
from an Apple point of view.  I do this on lots of Macs -- I've got a
regular posse of them at work.  And I've never had any problems with
it.


Same here: if have yet to see adverse consequences of installing third  
party packages into system Python. And now that Apple is distributing  
fairly current versions of things like PyObjC there's even little  
reason to build my own copy of Python. I have one on disk, but I find  
that I use the system Python for almost everything.


Fink (and to a lesser extent MacPorts) I don't touch with a 10 feet  
pole: too often I've created software for distribution only to find  
that it somehow, behind my back, was linked against a dynamic library  
that I had installed locally through it.

--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman



___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Pydotorg] Should we help pythonmac.org?

[Jesse Noller]

On Tue, Aug 19, 2008 at 1:28 PM, Bill Janssen <[EMAIL PROTECTED]> wrote:
>> > My understanding is that if there is a system Python, you shouldn't
>> > change it.  Ever.
>>
>> Huge, big, honkin' +1 from me on that.  Besides, for a system Python,
>> you want your distribution to manage packages, not setuptools,
>> otherwise you confuse -- and probably break -- your system.
>
> I find this discussion fascinating.  I install new packages into my
> system Python all the time, with "/usr/bin/python setup.py install",
> and that includes setuptools.  I've got PIL, ReportLab, Twisted, Xlib,
> appscript, docutils, email-4.0.1, fuse, PyLucene, medusa, mutagen,
> roman, setuptools, and SSL installed in the Leopard machine I'm
> writing from.  They don't wind up in
> /System/Library/.../site-packages/, they wind up in
> /Library/Python/2.5/site-packages/, which is sort of the right place,
> from an Apple point of view.  I do this on lots of Macs -- I've got a
> regular posse of them at work.  And I've never had any problems with
> it.
>
> I agree that there are some things I'd be very wary of installing into
> the system Python, like PyObjC, and Zope.  Usually, I don't install
> anything which appears to already be there.
>
> Bill

Bill is correct - using /usr/bin/python does install packages to
/Library/... - this is sort of the right place because it still
installs it to a "system path", where it can side-effect other users,
but it is a "mostly correct" way for Apple framework installs.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] Beta 3 planned for this Wednesday

[Guido van Rossum]

On Tue, Aug 19, 2008 at 1:19 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> 1179[CVE-2007-4965] Integer overflow in imageop module
>> - - High priority
>> - - This will block final release and I think it needs to be fixed for this 
>> beta.

Submitted the patch to 2.5 and 2.6.

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] Beta 3 planned for this Wednesday

[Jesse Noller]

> 3352Deficiencies in multiprocessing/threading API
> - - Medium priority
> - - This one is getting some love, so I'm confident this will get fixed before
>  beta 3.
>

This is complete on 2.6 as of r65864
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com