[Python-Dev] turtle.Screen- how to implement best a Singleton

[Gregor Lingl]

Hi,

this posting - concerning the new turtle module - goes to the Python-Dev 
and Python-3000 lists and to a couple of 'power users' of turtle 
graphics, hoping to recieve feedback from the developer's point of view 
as well as from the user's point of view.


Currently the implementations of the turtle.Screen class for Python 2.6 
and Python 3.0 differ by a 'tiny' detail with an important difference in 
behaviour. So clearly this has to be resolved  before the final 
release.(The origin of this difference is, that when I ported turtle.py 
to Python 3.0 I discovered (and 'fixed') what I now consider to be a bug 
in the 2.6 version.) I'd like to ask you kindly for your advice to 
achieve an optimal solution.


The posting consists of three parts:
1. Exposition of design goals
2. Problem with the implementation 
3. How to solve it?


Preliminary remark:  I've had some discussions on this topic before but 
I still do not see a clear solution. Moreover I'm well aware of the fact 
that using the Singleton pattern is controversial. So ...


1. Exposition of design goals
... why use the Singleton design pattern? The turtle module contains a 
TurtleScreen class, which implements methods to control the drawing area 
the turtle is (turtles are) drawing on. It's constructor needs a Tkinter 
Canvas as argument. In order to avoid the need for users to tinker 
around with Tkinter stuff there is the Screen(TurtleScreen) class, 
designed to be used by beginners(students, kids,...), particularly in 
interactive sessions.


A (THE (!)) Screen object is essentially a window containing a scrolled 
canvas, the TurtleScreen. So it's a ressource which should exist only 
once. It can be constructed in several ways:
- implicitely by calling an arbitrary function derived from a 
Turtle-method, such as forward(100) or by constructing a Turtle such as 
bob = Turtle()
- implicitely by calling an arbitrary function derived from a Screen 
method, such as bgcolor("red")

- explicitely by calling it's constructor such as s = Screen()
Anyway this construction should only happen if a Screen object doesn't 
exist yet.
Now for the pending question: What should happen, when s = Screen() is 
called explicitely and there exists already 'the' Screen object.

(i) Clearly s should get a reference to the existing Screen object, but ...
(ii) (a)... should s be reinitialized (this is the case now in Python 
2.6), or

(b)... should s be left untouched (this is the case now in Python 3.0)

I, for my part, prefer the latter solution (b). Example: a student, 
having (interactively) produced some design using some turtle t = 
Turtle() decides spontaneously to change backgroundcolor. s = Screen(); 
s.bgcolor("pink") should do this for her - instead of deleting her 
design and moreover her turtle. To reinitialize the screen she still can 
use s.clear().


Of course, there are workarounds to achieve the same effect also with 
solution (a), for instance by assigning s = Screen() *before* drawing 
anything or by assigning s = t.getscreen(). But imho (which derives 
itself from my experience as a teacher) solution (b) supports better the 
oop-view as well as experimenting spontaneously in interactive sessions.


2. Problem with the implementation
The task is to derive a Singleton class from a Nonsingleton class 
(Screen from TurtleScreen). The current implementations of the Screen 
'Singleton' both use the Borg idiom.  Just for *explaining* the 
difference between the two versions of class Screen here concisely,  
I'll use a 'standard' Singleton pattern (roughly equivalent to the Borg 
idiom):


class Spam(object):
   def __init__(self, s):
   self.s = s

class SingleSpam(Spam):
   _inst = None
   def __new__(cls, *args, **kwargs):   
   if cls != type(cls._inst):

   cls._inst = Spam.__new__(cls, *args, **kwargs)
   return cls._inst
   def __init__(self, s):
   if vars(self): return##  should this be here???
   Spam.__init__(self, s)

Shortly, this means that SingleSpam.__init__() acts like an empty method 
whenever a (the!) SingleSpam object already exists. 3.0 version of 
Screen acts like this. By contrast 2.6 version of Screen acts as if the 
butlast line were not there and thus reinitializes the Screen object.


3. How to solve it?

Main question: which *behaviour* of the Screen class should be 
preferred.  If  3.0, is it feasible and correct not to call the 
constructor of the parent class if the object already exists?


Additional question: Do you consider the Borg idiom a good solution for 
this task or should the standard singleton pattern as shown above be 
preferred. Or would you suggest a solution/an approach different from both?


Thanks for your patience, and - in advance - for your assistance

Regard,
Gregor




___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/opt

[Python-Dev] issue 3582

[Kristján Valur Jónsson]

Hello there.
Yesterday I posted a feature request, http://bugs.python.org/issue3582, along 
with a patch.
It provides platform specifict TLS functions on windows.
Implementing it I came across the strange semantics of 
PyThread_set_key_value().  If a value has been set previously, it will ignore 
the set.
This is most unusual, and I had to make two TLS calls in the NT version to 
emulate this behaviour.

This behaviour is mentioned in pystate.c:

   The only situation where you can legitimately have more than one
 thread state for an OS level thread is when there are multiple
 interpreters, when:

 a) You shouldn't really be using the PyGILState_ APIs anyway,
and:

 b) The slightly odd way PyThread_set_key_value works (see
comments by its implementation) means that the first thread
state created for that given OS level thread will "win",
which seems reasonable behaviour.
  */
Now, this seems to be the only place where this is required, but I fail to see 
how even in
this scenario it makes sense.  As a) code says, you shouldn't be using the GIL 
api anyway, and
it will undoubtebly create problems elsewhere if sticking the thread state into 
TLS fails silently.

Changing this odd behaviour of PyThread_set_key_value () is trivial and would 
make it easier to use native TLS functions on other platforms.  Any thoughts?

K
___
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] Why does httplib import from test_support?

[skip]

Is this new as of the last couple of days?

Traceback (most recent call last):
  File "/Users/skip/tmp/py/mmfold.py", line 182, in 
sys.exit(main())
  File "/Users/skip/tmp/py/mmfold.py", line 95, in main
for line in urllib.urlopen(url+"?adminpw=%s" % passwd):
  File "/Users/skip/local/lib/python2.6/urllib.py", line 87, in urlopen
return opener.open(url)
  File "/Users/skip/local/lib/python2.6/urllib.py", line 203, in open
return getattr(self, name)(url)
  File "/Users/skip/local/lib/python2.6/urllib.py", line 285, in open_http
import httplib
  File "/Users/skip/local/lib/python2.6/httplib.py", line 72, in 
from test.test_support import catch_warning
ImportError: No module named test_support

The import statement seems to work from an interactive shell (I have a
module named test in the same directory as the main prog, hence the
problem), but even if it does work should we be importing stuff from the
test package in non-test code?

Skip

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

[EMAIL PROTECTED] wrote:
> The import statement seems to work from an interactive shell (I have a
> module named test in the same directory as the main prog, hence the
> problem), but even if it does work should we be importing stuff from the
> test package in non-test code?

I saw those checkins go by on the checkins list - they have to do with
silencing -3 warnings for modules that the stdlib still uses in Python
2.6 for backwards compatibility reasons (but switching to the relevant
new approaches in 3.0, thus making the warnings a false alarm).

test.test_support.catch_warning is a convenient way to suppress a
warning for a small piece of code and then revert the state of the
warnings module back to the way it was afterwards.

Those imports should probably be guarded with sys.py3kwarn though, with
a standard import being used if the command line flag isn't set.

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] turtle.Screen- how to implement best a Singleton

[Gregor Lingl]

Thanks for the feedback,
Gregor

Vern Ceder schrieb:

Gregor,

I don't feel authoritative on the correctness/appropriateness of the 
implementation, but I do agree completely that behavior b, or what you 
have in the 3.0 version, is vastly preferable.


Cheers,
Vern

Gregor Lingl wrote:

Hi,

this posting - concerning the new turtle module - goes to the 
Python-Dev and Python-3000 lists and to a couple of 'power users' of 
turtle graphics, hoping to recieve feedback from the developer's 
point of view as well as from the user's point of view.


Currently the implementations of the turtle.Screen class for Python 
2.6 and Python 3.0 differ by a 'tiny' detail with an important 
difference in behaviour. So clearly this has to be resolved  before 
the final release.(The origin of this difference is, that when I 
ported turtle.py to Python 3.0 I discovered (and 'fixed') what I now 
consider to be a bug in the 2.6 version.) I'd like to ask you kindly 
for your advice to achieve an optimal solution.


The posting consists of three parts:
1. Exposition of design goals
2. Problem with the implementation 3. How to solve it?

Preliminary remark:  I've had some discussions on this topic before 
but I still do not see a clear solution. Moreover I'm well aware of 
the fact that using the Singleton pattern is controversial. So ...


1. Exposition of design goals
... why use the Singleton design pattern? The turtle module contains 
a TurtleScreen class, which implements methods to control the drawing 
area the turtle is (turtles are) drawing on. It's constructor needs a 
Tkinter Canvas as argument. In order to avoid the need for users to 
tinker around with Tkinter stuff there is the Screen(TurtleScreen) 
class, designed to be used by beginners(students, kids,...), 
particularly in interactive sessions.


A (THE (!)) Screen object is essentially a window containing a 
scrolled canvas, the TurtleScreen. So it's a ressource which should 
exist only once. It can be constructed in several ways:
- implicitely by calling an arbitrary function derived from a 
Turtle-method, such as forward(100) or by constructing a Turtle such 
as bob = Turtle()
- implicitely by calling an arbitrary function derived from a Screen 
method, such as bgcolor("red")

- explicitely by calling it's constructor such as s = Screen()
Anyway this construction should only happen if a Screen object 
doesn't exist yet.
Now for the pending question: What should happen, when s = Screen() 
is called explicitely and there exists already 'the' Screen object.
(i) Clearly s should get a reference to the existing Screen object, 
but ...
(ii) (a)... should s be reinitialized (this is the case now in Python 
2.6), or
(b)... should s be left untouched (this is the case now in Python 
3.0)


I, for my part, prefer the latter solution (b). Example: a student, 
having (interactively) produced some design using some turtle t = 
Turtle() decides spontaneously to change backgroundcolor. s = 
Screen(); s.bgcolor("pink") should do this for her - instead of 
deleting her design and moreover her turtle. To reinitialize the 
screen she still can use s.clear().


Of course, there are workarounds to achieve the same effect also with 
solution (a), for instance by assigning s = Screen() *before* drawing 
anything or by assigning s = t.getscreen(). But imho (which derives 
itself from my experience as a teacher) solution (b) supports better 
the oop-view as well as experimenting spontaneously in interactive 
sessions.


2. Problem with the implementation
The task is to derive a Singleton class from a Nonsingleton class 
(Screen from TurtleScreen). The current implementations of the Screen 
'Singleton' both use the Borg idiom.  Just for *explaining* the 
difference between the two versions of class Screen here concisely,  
I'll use a 'standard' Singleton pattern (roughly equivalent to the 
Borg idiom):


class Spam(object):
   def __init__(self, s):
   self.s = s

class SingleSpam(Spam):
   _inst = None
   def __new__(cls, *args, **kwargs):  if cls != 
type(cls._inst):

   cls._inst = Spam.__new__(cls, *args, **kwargs)
   return cls._inst
   def __init__(self, s):
   if vars(self): return##  should this be here???
   Spam.__init__(self, s)

Shortly, this means that SingleSpam.__init__() acts like an empty 
method whenever a (the!) SingleSpam object already exists. 3.0 
version of Screen acts like this. By contrast 2.6 version of Screen 
acts as if the butlast line were not there and thus reinitializes the 
Screen object.


3. How to solve it?

Main question: which *behaviour* of the Screen class should be 
preferred.  If  3.0, is it feasible and correct not to call the 
constructor of the parent class if the object already exists?


Additional question: Do you consider the Borg idiom a good solution 
for this task or should the standard singleton pattern as shown above 
be preferred. Or would you suggest a solution/an approach different 

Re: [Python-Dev] optimization required: .format() is much slower than %

[Eric Smith]

Eric Smith wrote:

Eric Smith wrote:

Eric Smith wrote:

Nick Coghlan wrote:
Secondly, the string % operator appears to have an explicit 
optimisation for the 'just return str(self)' case. This optimisation 
is missing from the new string format method.


I'll see if I can optimize this case.


3.0, from svn:
$ ./python.exe -m timeit "'some text with {0}'.format('nothing')"
10 loops, best of 3: 3.14 usec per loop

3.0, with PyUnicode_ExactCheck, skipping __format__ lookup:
$ ./python.exe -m timeit "'some text with {0}'.format('nothing')"
10 loops, best of 3: 2.32 usec per loop

I could probably improve this some more, by skipping the creation of 
the object used to describe the format_spec.


Compare with:
$ ./python.exe -m timeit "'some text with %s' % 'nothing'"
100 loops, best of 3: 1.37 usec per loop


r63826 has an optimization when formatting types that are exactly 
unicode, long, or float (not subclasses).  Unfortunately it's only for 
3.0.  For 2.6 it's messier.  I'm still pondering what to do with that. 
I'll get to it sometime, but maybe after the beta.


I finally backported this to 2.6 in r65814.  There's a similar 30% 
speedup for the simplest cases.  Unicode optimization is worse than 
string optimization, because of the way int, long, and float formatters 
work.  This can be fixed, but I'm not sure the gain justifies the 
effort.  I doubt I'll have time to look into this before beta3.


Eric.
___
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] optimization required: .format() is much slower than %

[Antoine Pitrou]

Eric Smith  trueblade.com> writes:
> 
> I finally backported this to 2.6 in r65814.  There's a similar 30% 
> speedup for the simplest cases.  Unicode optimization is worse than 
> string optimization, because of the way int, long, and float formatters 
> work.  This can be fixed, but I'm not sure the gain justifies the 
> effort.  I doubt I'll have time to look into this before beta3.

Given the choice, I would think it's more important to further speedup the 
implementation in 3.0 rather than try to backport the existing speedups to 2.6.
In 2.6 the standard formatting facility is still the % operator.

(Just my two suboptimal cents)



___
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] issue 3582

[Bill Janssen]

> It provides platform specific TLS functions on windows.

In this context, TLS is "thread-local storage".

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

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

[Guido van Rossum]

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/archive%40mail-archive.com

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

[skip]

Guido> Does anyone have connections with the owners of pythonmac.org?

I believe that's Bob Ippolito ([EMAIL PROTECTED] - cc'd).

Skip

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

Guido> -- 
Guido> --Guido van Rossum (home: python.org/~guido/)
Guido> ___
Guido> Python-Dev mailing list
Guido> Python-Dev@python.org
Guido> http://mail.python.org/mailman/listinfo/python-dev
Guido> Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/skip%40pobox.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] Should we help pythonmac.org?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Aug 18, 2008, at 12:05 PM, 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.)


I'd be happy to arrange things with a Mac expert to put the Mac  
binaries on the download site.


- -Barry

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

iQCVAwUBSKmpOHEjvBPtnXfVAQJNFAQAiQu+ZgeHoi7fzF7NWwqDoP4AAH8UNF5B
6JL74CmJnarhZ40dum3RUz+bEM3Htfik+baMUInCEz+hlOBBbZi9qTyVxTdA9zOg
t2/Z/mzl7o/0POyoxAaVcYVBife2FYiNUIfB9AvP7TtUYCJmI2bCTCiBkTO/GLDm
7VBpEF3gNhs=
=jIn7
-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?

[Guido van Rossum]

Note that many distros are in the habit of not installing the test
package by default. So dependencies outside that package on *anything*
in it are a problem. Maybe test_support should be lifted out of the
test package?

On Mon, Aug 18, 2008 at 4:35 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>> The import statement seems to work from an interactive shell (I have a
>> module named test in the same directory as the main prog, hence the
>> problem), but even if it does work should we be importing stuff from the
>> test package in non-test code?
>
> I saw those checkins go by on the checkins list - they have to do with
> silencing -3 warnings for modules that the stdlib still uses in Python
> 2.6 for backwards compatibility reasons (but switching to the relevant
> new approaches in 3.0, thus making the warnings a false alarm).
>
> test.test_support.catch_warning is a convenient way to suppress a
> warning for a small piece of code and then revert the state of the
> warnings module back to the way it was afterwards.
>
> Those imports should probably be guarded with sys.py3kwarn though, with
> a standard import being used if the command line flag isn't set.
>
> 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/guido%40python.org
>



-- 
--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] Why does httplib import from test_support?

[Brett Cannon]

On Mon, Aug 18, 2008 at 4:35 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>> The import statement seems to work from an interactive shell (I have a
>> module named test in the same directory as the main prog, hence the
>> problem), but even if it does work should we be importing stuff from the
>> test package in non-test code?
>
> I saw those checkins go by on the checkins list - they have to do with
> silencing -3 warnings for modules that the stdlib still uses in Python
> 2.6 for backwards compatibility reasons (but switching to the relevant
> new approaches in 3.0, thus making the warnings a false alarm).
>

Nick is right and all of those checkins were mine.

> test.test_support.catch_warning is a convenient way to suppress a
> warning for a small piece of code and then revert the state of the
> warnings module back to the way it was afterwards.
>

Yep.

> Those imports should probably be guarded with sys.py3kwarn though, with
> a standard import being used if the command line flag isn't set.

That's probably a good idea.

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

[Brett Cannon]

On Mon, Aug 18, 2008 at 10:06 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Note that many distros are in the habit of not installing the test
> package by default. So dependencies outside that package on *anything*
> in it are a problem. Maybe test_support should be lifted out of the
> test package?
>

Well, if distros do tend to do this and we are going to continue to
document what is in that module for people's benefit, then yes, it
should probably be moved or we try to convince distros to at least
include the module and possibly regrtest.

-Brett


> On Mon, Aug 18, 2008 at 4:35 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>>> The import statement seems to work from an interactive shell (I have a
>>> module named test in the same directory as the main prog, hence the
>>> problem), but even if it does work should we be importing stuff from the
>>> test package in non-test code?
>>
>> I saw those checkins go by on the checkins list - they have to do with
>> silencing -3 warnings for modules that the stdlib still uses in Python
>> 2.6 for backwards compatibility reasons (but switching to the relevant
>> new approaches in 3.0, thus making the warnings a false alarm).
>>
>> test.test_support.catch_warning is a convenient way to suppress a
>> warning for a small piece of code and then revert the state of the
>> warnings module back to the way it was afterwards.
>>
>> Those imports should probably be guarded with sys.py3kwarn though, with
>> a standard import being used if the command line flag isn't set.
>>
>> 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/guido%40python.org
>>
>
>
>
> --
> --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/brett%40python.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] Why does httplib import from test_support?

[Guido van Rossum]

On Mon, Aug 18, 2008 at 10:34 AM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 18, 2008 at 10:06 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> Note that many distros are in the habit of not installing the test
>> package by default. So dependencies outside that package on *anything*
>> in it are a problem. Maybe test_support should be lifted out of the
>> test package?
>>
>
> Well, if distros do tend to do this and we are going to continue to
> document what is in that module for people's benefit, then yes, it
> should probably be moved or we try to convince distros to at least
> include the module and possibly regrtest.

Don't fight the distros! Move it. I'm not sure why regrtest needs to
be moved though?

> -Brett
>
>
>> On Mon, Aug 18, 2008 at 4:35 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>>> [EMAIL PROTECTED] wrote:
 The import statement seems to work from an interactive shell (I have a
 module named test in the same directory as the main prog, hence the
 problem), but even if it does work should we be importing stuff from the
 test package in non-test code?
>>>
>>> I saw those checkins go by on the checkins list - they have to do with
>>> silencing -3 warnings for modules that the stdlib still uses in Python
>>> 2.6 for backwards compatibility reasons (but switching to the relevant
>>> new approaches in 3.0, thus making the warnings a false alarm).
>>>
>>> test.test_support.catch_warning is a convenient way to suppress a
>>> warning for a small piece of code and then revert the state of the
>>> warnings module back to the way it was afterwards.
>>>
>>> Those imports should probably be guarded with sys.py3kwarn though, with
>>> a standard import being used if the command line flag isn't set.
>>>
>>> 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/guido%40python.org
>>>
>>
>>
>>
>> --
>> --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/brett%40python.org
>>
>



-- 
--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] Why does httplib import from test_support?

[Brett Cannon]

On Mon, Aug 18, 2008 at 11:10 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 18, 2008 at 10:34 AM, Brett Cannon <[EMAIL PROTECTED]> wrote:
>> On Mon, Aug 18, 2008 at 10:06 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>>> Note that many distros are in the habit of not installing the test
>>> package by default. So dependencies outside that package on *anything*
>>> in it are a problem. Maybe test_support should be lifted out of the
>>> test package?
>>>
>>
>> Well, if distros do tend to do this and we are going to continue to
>> document what is in that module for people's benefit, then yes, it
>> should probably be moved or we try to convince distros to at least
>> include the module and possibly regrtest.
>
> Don't fight the distros! Move it.

And now the great debate; what should it be named? Should we start a
testing package and name the module testing.support, possibly moving
doctest, unittest, and any other testing code there at some point? Or
just make it test_support at the top level? Or should the granularity
be greater, such as separating out stuff that deals with the
interpreter, files, and system state (or something)? The module has
stuff ranging from is_resource_enabled and verbose for regrtest to
catch_warning, TESTFN, and run_with_locale.

>I'm not sure why regrtest needs to
> be moved though?
>

Doesn't have to move. It's just the only other piece of code in the
'test' package that isn't just a test.

-Brett


>> -Brett
>>
>>
>>> On Mon, Aug 18, 2008 at 4:35 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
 [EMAIL PROTECTED] wrote:
> The import statement seems to work from an interactive shell (I have a
> module named test in the same directory as the main prog, hence the
> problem), but even if it does work should we be importing stuff from the
> test package in non-test code?

 I saw those checkins go by on the checkins list - they have to do with
 silencing -3 warnings for modules that the stdlib still uses in Python
 2.6 for backwards compatibility reasons (but switching to the relevant
 new approaches in 3.0, thus making the warnings a false alarm).

 test.test_support.catch_warning is a convenient way to suppress a
 warning for a small piece of code and then revert the state of the
 warnings module back to the way it was afterwards.

 Those imports should probably be guarded with sys.py3kwarn though, with
 a standard import being used if the command line flag isn't set.

 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/guido%40python.org

>>>
>>>
>>>
>>> --
>>> --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/brett%40python.org
>>>
>>
>
>
>
> --
> --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] Why does httplib import from test_support?

[Guido van Rossum]

Given that we're about to release beta3, I propose to name it
test_support at the top level and leave it at that for now.
Introducing a testing package should be relegated to 3.1 IMO.

On Mon, Aug 18, 2008 at 11:23 AM, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 18, 2008 at 11:10 AM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> On Mon, Aug 18, 2008 at 10:34 AM, Brett Cannon <[EMAIL PROTECTED]> wrote:
>>> On Mon, Aug 18, 2008 at 10:06 AM, Guido van Rossum <[EMAIL PROTECTED]> 
>>> wrote:
 Note that many distros are in the habit of not installing the test
 package by default. So dependencies outside that package on *anything*
 in it are a problem. Maybe test_support should be lifted out of the
 test package?

>>>
>>> Well, if distros do tend to do this and we are going to continue to
>>> document what is in that module for people's benefit, then yes, it
>>> should probably be moved or we try to convince distros to at least
>>> include the module and possibly regrtest.
>>
>> Don't fight the distros! Move it.
>
> And now the great debate; what should it be named? Should we start a
> testing package and name the module testing.support, possibly moving
> doctest, unittest, and any other testing code there at some point? Or
> just make it test_support at the top level? Or should the granularity
> be greater, such as separating out stuff that deals with the
> interpreter, files, and system state (or something)? The module has
> stuff ranging from is_resource_enabled and verbose for regrtest to
> catch_warning, TESTFN, and run_with_locale.
>
>>I'm not sure why regrtest needs to
>> be moved though?
>>
>
> Doesn't have to move. It's just the only other piece of code in the
> 'test' package that isn't just a test.
>
> -Brett
>
>
>>> -Brett
>>>
>>>
 On Mon, Aug 18, 2008 at 4:35 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
>> The import statement seems to work from an interactive shell (I have a
>> module named test in the same directory as the main prog, hence the
>> problem), but even if it does work should we be importing stuff from the
>> test package in non-test code?
>
> I saw those checkins go by on the checkins list - they have to do with
> silencing -3 warnings for modules that the stdlib still uses in Python
> 2.6 for backwards compatibility reasons (but switching to the relevant
> new approaches in 3.0, thus making the warnings a false alarm).
>
> test.test_support.catch_warning is a convenient way to suppress a
> warning for a small piece of code and then revert the state of the
> warnings module back to the way it was afterwards.
>
> Those imports should probably be guarded with sys.py3kwarn though, with
> a standard import being used if the command line flag isn't set.
>
> 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/guido%40python.org
>



 --
 --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/brett%40python.org

>>>
>>
>>
>>
>> --
>> --Guido van Rossum (home page: http://www.python.org/~guido/)
>>
>



-- 
--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] Why does httplib import from test_support?

[Benjamin Peterson]

On Mon, Aug 18, 2008 at 1:31 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Given that we're about to release beta3, I propose to name it
> test_support at the top level and leave it at that for now.
> Introducing a testing package should be relegated to 3.1 IMO.

Why not name it testutils?



-- 
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] Why does httplib import from test_suppor t?

[Antoine Pitrou]

Brett Cannon  python.org> writes:
> >
> > I saw those checkins go by on the checkins list - they have to do with
> > silencing -3 warnings for modules that the stdlib still uses in Python
> > 2.6 for backwards compatibility reasons (but switching to the relevant
> > new approaches in 3.0, thus making the warnings a false alarm).
> >
> 
> Nick is right and all of those checkins were mine.

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


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

[Fred Drake]

On Aug 18, 2008, at 2:33 PM, Benjamin Peterson wrote:

Why not name it testutils?



Heh.  And what's the difference between *utils, *tools, and *lib?   
They all sound the same to me.  :-(



  -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] Why does httplib import from test_support?

[Fred Drake]

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.



  -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] Why does httplib import from test_support?

[Brett Cannon]

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.

-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] Should we help pythonmac.org?

[Guido van Rossum]

Alternatively, I just got mail from Bob Ippolito indicating that he'd
be happy to hand over the domain to the PSF. It's got quite a bit more
on it than Python distros, and it's a fairly popular resource for Mac
users I imagine. However macports.org seems to have more Python stuff,
and has a more recent version of 2.5. (2.5.2). Perhaps we should link
to macports.org instead?

On Mon, Aug 18, 2008 at 9:54 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Aug 18, 2008, at 12:05 PM, 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.)
>
> I'd be happy to arrange things with a Mac expert to put the Mac binaries on
> the download site.

-- 
--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] Should we help pythonmac.org?

[Steve Holden]

Someone told me the other day that macports made for difficult installs, 
but not being a Mac user I wasn't in a position to evaluate the advice.


I can see the desirability of having a Python-specific domain, but then 
again if the pydotorg team were going to maintain the content then they 
might just as well maintain it under python.org. I really do think it 
would be better if the Mac downloads were available from the same site 
as all the others, but I don't know whether we have the manpower and 
skills available to cut the releases and maintain the additional content.


I'm copying the pydotorg list to see what, if anything, they have to say 
about it. That's where the work is likely to land, so we'd better know 
in advance if it would cause problems.


regards
 Steve

Guido van Rossum wrote:

Alternatively, I just got mail from Bob Ippolito indicating that he'd
be happy to hand over the domain to the PSF. It's got quite a bit more
on it than Python distros, and it's a fairly popular resource for Mac
users I imagine. However macports.org seems to have more Python stuff,
and has a more recent version of 2.5. (2.5.2). Perhaps we should link
to macports.org instead?

On Mon, Aug 18, 2008 at 9:54 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:

On Aug 18, 2008, at 12:05 PM, 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.)

I'd be happy to arrange things with a Mac expert to put the Mac binaries on
the download site.





--
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] Should we help pythonmac.org?

[Bob Ippolito]

The major difference between the packages on macports and
pythonmac.org is that macports is their own distro of nearly
everything, akin to installing a copy of FreeBSD over top of Mac OS X.
pythonmac.org contains packages that are self-contained and don't have
a whole new set of libraries to install (in the cases where they do
require libraries, they link them in statically for the most part).

These days I don't have a lot of preference, I don't use either :)

On Mon, Aug 18, 2008 at 1:08 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Alternatively, I just got mail from Bob Ippolito indicating that he'd
> be happy to hand over the domain to the PSF. It's got quite a bit more
> on it than Python distros, and it's a fairly popular resource for Mac
> users I imagine. However macports.org seems to have more Python stuff,
> and has a more recent version of 2.5. (2.5.2). Perhaps we should link
> to macports.org instead?
>
> On Mon, Aug 18, 2008 at 9:54 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> On Aug 18, 2008, at 12:05 PM, 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.)
>>
>> I'd be happy to arrange things with a Mac expert to put the Mac binaries on
>> the download site.
>
> --
> --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?

[Fred Drake]

On Aug 18, 2008, at 5:42 PM, Steve Holden wrote:
Someone told me the other day that macports made for difficult  
installs, but not being a Mac user I wasn't in a position to  
evaluate the advice.


Not being a Mac user either, I've been using Mac OS X for about a year  
now for most of my development.


I've got mixed feelings about macports:  It's painful to use, compared  
to things like rpm and apt, but... it might be the best that's  
available for the Mac.


I'm not going to trust it to give me a usable Python, though, in spite  
of not having had problems with Pythons it provides.  Just 'cause I've  
gotten paranoid.


I'm copying the pydotorg list to see what, if anything, they have to  
say about it. That's where the work is likely to land, so we'd  
better know in advance if it would cause problems.


If there are content maintainers for the Mac content (including  
installation packages of whatever form), then python.org is the right  
place for it.  Presumably //someone// is creating those now, right?   
If they could upload them to python.org and update the pages  
accordingly, that should be no worse than anything they're doing now.



  -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] [Pydotorg] Should we help pythonmac.org?

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Aug 18, 2008, at 6:13 PM, Fred Drake wrote:


On Aug 18, 2008, at 5:42 PM, Steve Holden wrote:
Someone told me the other day that macports made for difficult  
installs, but not being a Mac user I wasn't in a position to  
evaluate the advice.


Not being a Mac user either, I've been using Mac OS X for about a  
year now for most of my development.


I've got mixed feelings about macports:  It's painful to use,  
compared to things like rpm and apt, but... it might be the best  
that's available for the Mac.


I'm not going to trust it to give me a usable Python, though, in  
spite of not having had problems with Pythons it provides.  Just  
'cause I've gotten paranoid.


I use macports too, mostly for stuff I'm too lazy to build from  
source.  I'm sure there's a Python in there, but like Fred, I don't  
use it.


I do agree that we could and probably should maintain any Mac Python  
content on the main python.org site, but also if Bob wants to donate  
the domain, we can just have it forward to www.python.org/allyourmacsarebelongtous


- -Barry

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

iQCVAwUBSKn6k3EjvBPtnXfVAQJdZgP/a2G3T9jowXMjYc5dc/+PFFVM0mxe0+Y1
rJKoHZ+jumWEsxERD6kXCjrq00z21lGISnEBQkT5taieGgt8ouI3RtC3Atpp/wCR
oqvyFJUb9Xxu7TUAV94G3yC/CUq0ZQiKT80F0YB/IQAGeYy6orkfolUqMosUOsVo
KB1WDrqXEiU=
=SZ1A
-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?

[David Goodger]

> Guido van Rossum wrote:
>> Alternatively, I just got mail from Bob Ippolito indicating that he'd
>> be happy to hand over the domain to the PSF. It's got quite a bit more
>> on it than Python distros, and it's a fairly popular resource for Mac
>> users I imagine. However macports.org seems to have more Python stuff,
>> and has a more recent version of 2.5. (2.5.2). Perhaps we should link
>> to macports.org instead?

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. Those who want/need it know
about it or will find it easily, while those who don't need it would
only be confused by it.

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.

Unfortunately, I can only recommend. I don't know anything about
building Mac apps.

-- 
David Goodger 
___
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?

[Bob Ippolito]

On Mon, Aug 18, 2008 at 3:41 PM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Aug 18, 2008, at 6:13 PM, Fred Drake wrote:
>
>> On Aug 18, 2008, at 5:42 PM, Steve Holden wrote:
>>>
>>> Someone told me the other day that macports made for difficult installs,
>>> but not being a Mac user I wasn't in a position to evaluate the advice.
>>
>> Not being a Mac user either, I've been using Mac OS X for about a year now
>> for most of my development.
>>
>> I've got mixed feelings about macports:  It's painful to use, compared to
>> things like rpm and apt, but... it might be the best that's available for
>> the Mac.
>>
>> I'm not going to trust it to give me a usable Python, though, in spite of
>> not having had problems with Pythons it provides.  Just 'cause I've gotten
>> paranoid.
>
> I use macports too, mostly for stuff I'm too lazy to build from source.  I'm
> sure there's a Python in there, but like Fred, I don't use it.
>
> I do agree that we could and probably should maintain any Mac Python content
> on the main python.org site, but also if Bob wants to donate the domain, we
> can just have it forward to www.python.org/allyourmacsarebelongtous

We already do that for the wiki, we could do that for the other parts
of the site just as easily (even without or before a transfer of
ownership) :) I'm happy to pay for the domain and hosting, I just
don't have a lot of spare cycles these days unless I need something at
work.

-bob
___
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 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.

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?

[Steve Holden]

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


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/archive%40mail-archive.com

Re: [Python-Dev] [Python-3000] parse_qs and parse_qsl functions

[Barry Warsaw]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Aug 16, 2008, at 12:52 PM, Brett Cannon wrote:

>On Sat, Aug 16, 2008 at 7:04 AM, Facundo Batista
><[EMAIL PROTECTED]> wrote:
>> Hi!
>>
>> The issue 600362 has two patches (one for 2.6 and the other for 3.0)
>> that are ready to commit (with a small change in the docs). This
>> patches relocates the parse_qs and parse_qsl functions into the
>> urlparse module (urllib.parse in 3k), bringing them from the cgi one.
>>
>> For backward compatibility, those functions are also accessible from
>> the cgi module, but in the documentation says that the function was
>> moved, and you should use it from the urlparse one.
>>
>> So, we don't have *any* change in the behaviour towards the final user.
>>
>> Two questions:
>>
>> - It's ok to do this now or we should wait for 3.1/2.7?
>>
>> - Should we add a deprecation warning in the cgi module for this functions?
>>
>> I propose to commit this now, but leave a deprecation warning for the
>> next release.
>>
>
>Obviously Barry's call, but I think it's fine to do what you are proposing.

I think it's fine to commit this.  I would put a DeprecationWarning in 3.0 and
a PendingDeprecationWarning in 2.6 (updated to a DW in 2.7).

- -Barry
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIqja42YZpQepbvXERAp7oAJ9t6h/MtzAQQDDS3J65p7Zwpf+JzgCeO24r
kCmcTtPIeo/M0hiqmtee0/o=
=FVuq
-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] Beta 3 planned for this Wednesday

[Barry Warsaw]

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

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.

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.

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.

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

[Leonardo Santagada]

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


--
Leonardo Santagada



___
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