Re: [Python-Dev] unittest's redundant assertions: asserts vs. failIf/Unlesses

2008-04-08 Thread Michael Foord
Guido van Rossum wrote:
> On Wed, Mar 19, 2008 at 5:16 PM, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
>   
>> On Wed, Mar 19, 2008 at 2:15 PM,  <[EMAIL PROTECTED]> wrote:
>>  >
>>  >  On 02:21 pm, [EMAIL PROTECTED] wrote:
>>  >  >>OTOH, I'd rather there be OOWTDI so whatever the consensus is is fine
>>  >  >>with me.
>>  >  >
>>  >  >This strikes me as a gratuitous API change of the kind Guido was
>>  >  >warning about in his recent post: "Don't change your APIs incompatibly
>>  >  >when porting to Py3k"
>>  >
>>  >  I agree emphatically.  Actually I think this is the most extreme case.
>>  >  The unit test stuff should be as stable as humanly possible between 2
>>  >  and 3, moreso than any other library.
>>
>>  This is convincing for me. Move my +1 back to 3.1.
>> 
>
> Same here; let's tread carefully here and not change this with 3.0.
> Starting to deprecate in 3.1 and killing in 3.3 would be soon enough.
> I like using only the assertKeyword variants, removing assert_, fail*,
> and assertEquals. However I don't like changing assertTrue and
> assertFalse to insist that the value is exactly True or False -- if
> you really care that much, let's add assertIs(x, y) which asserts that
> x and y are the same object. I also think that all tests should use
> the operator their name implies, e.g. assertEqual(x, y) should do
> something like
>
>   if x == y:
> pass
>   else:
> raise AssertionError(...)
>
> rather than
>
>   if x != y:
> raise AssertionError(...)
>
> Someone please open a bug for this task.
>
>   
This sounds like a good compromise and I'm happy to take on the cleanup 
- unless someone else beats me to it. I guess it should wait until 3.0 
final is out of the door before adding the DeprecationWarnings.

Michael Foord
___
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] Changing all network-oriented tests to facilitate (virtually unlimited) parallel test execution [Issue#: 2550]

2008-04-08 Thread Trent Nelson

I've forwarding my most recent update to issue 2550 here such that the proposed 
patch (and in general, the approach to network-oriented test cases) can be 
vetted by a wider audience:

http://bugs.python.org/file9980/trunk.2550-2.patch

This patch works towards fixing a large proportion of the tests that were 
written in such a way that often leads to buildbot errors when port conflicts 
arise.  With this patch applied, I can run many instances of the test suite in 
parallel and none of the network-oriented tests fail (which they do currently 
if you try and do this).

Plenty of discussion (mostly me replying to my own comments) on the subject at: 
http://bugs.python.org/issue2550.

Anyone have any issues with this new approach?  I'm particularily interested in 
whether or not people disagree with the assumption I've drawn regarding never 
using SO_REUSEADDR in tests for TCP/IP sockets (see below).

Trent.



From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Trent Nelson [EMAIL 
PROTECTED]
Sent: 08 April 2008 12:49
To: [EMAIL PROTECTED]
Subject: [issue2550] SO_REUSEADDR doesn't have the same semantics on Windows
as on Unix

Trent Nelson <[EMAIL PROTECTED]> added the comment:

Invested quite a few cycles on this issue last night.  The more time I
spent on it, the more I became convinced that every single test working
with sockets should be changed in one fell swoop in order to facilitate
(virtually unlimited) parallel test execution without fear of port
conflicts.

I've attached a second patch, trunk.2550-2.patch, which is my progress
so far on doing just this.  The main changes can be expressed by the
following two points:

a) do whatever it takes in network-oriented tests to ensure
   unique ports are obtained (relying on the bind_port() and
   find_unused_port() methods exposed by test_support)

b) never, ever, ever call SO_REUSEADDR on a socket from a test;
   because we're putting so much effort into obtaining a unique
   port, this should never be necessary -- in the rare cases that
   our attempts to obtain a unique port fail, then we absolutely
   should fail with EADDRINUSE, as the ability to obtain a unique
   port for the duration of a client/server test is an invariant
   that we *must* be able to depend upon.  If the invariant is
   broken, fail immediately (don't mask the problem with
   SO_REUSEADDR).

With this patch applied, I can spawn a handful of Python processes and
run the entire test suite (without -r, ensuring all tests are run in
the same order, which should encourage port conflicts (if there were
any)) without any errors*.  Doing that now is completely and utterly
impossible.

[*] Well, almost without error.  All the I/O related tests that try and
open @test fail.

I believe there's still outstanding work to do with this patch with
regards to how the intracacies of SO_REUSEADDR and SO_EXCLUSIVEADDRUSE
should be handled in the rest of the stdlib.  I'm still thinking about
the best approach for this.  However, the patch as it currently stands
is still quite substantial so I wanted to get it out sooner rather than
later for review.

(I'll forward this to python-dev@ to try and encourage more eyes from
people with far more network-fu than I.)

Added file: http://bugs.python.org/file9980/trunk.2550-2.patch

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/tnelson%40onresolve.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


[Python-Dev] py3k: print function treats sep=None and end=None in an unintuitive way

2008-04-08 Thread Alessandro Guido
Can anybody please point me why print('a', 'b', sep=None, end=None) should
produce "a b\n" instead of "ab"?
I've read http://docs.python.org/dev/3.0/library/functions.html#print, pep-3105 
and some
ml threads but did not find a good reason justifying such a strange behaviour.

Thanks.

-Alessandro 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] py3k: print function treats sep=None and end=None in an unintuitive way

2008-04-08 Thread Nick Coghlan
Alessandro Guido wrote:
> Can anybody please point me why print('a', 'b', sep=None, end=None) should
> produce "a b\n" instead of "ab"?
> I've read http://docs.python.org/dev/3.0/library/functions.html#print, 
> pep-3105 and some
> ml threads but did not find a good reason justifying such a strange behaviour.

So that print(a, b) does the right thing (i.e. matches the Python 2.x 
print statement's behaviour)

sep=None, end=None means "use the default separator and line ending" 
rather than "don't use a separator or line ending" (this is the same as 
for most functions with optional arguments - you need to look at the 
documentation of the function to find out what default values are used 
when passing None for an optional argument).

That said, it does read oddly, so I'd advise against writing it out 
explicitly like that - if you want the default, just leave out the 
relevant argument.

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] py3k: print function treats sep=None and end=None in an unintuitive way

2008-04-08 Thread Eric Smith
Alessandro Guido wrote:
> Can anybody please point me why print('a', 'b', sep=None, end=None) should
> produce "a b\n" instead of "ab"?
> I've read http://docs.python.org/dev/3.0/library/functions.html#print, 
> pep-3105 and some
> ml threads but did not find a good reason justifying such a strange behaviour.
> 
> Thanks.
> 
>   -Alessandro Guido

Because None mean 'use the default value'.  You probably want:
print('a', 'b', sep='', end='')
___
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] py3k: print function treats sep=None and end=None in an unintuitive way

2008-04-08 Thread Eric Smith
Alessandro Guido wrote:
> Can anybody please point me why print('a', 'b', sep=None, end=None) should
> produce "a b\n" instead of "ab"?
> I've read http://docs.python.org/dev/3.0/library/functions.html#print, 
> pep-3105 and some
> ml threads but did not find a good reason justifying such a strange behaviour.
> 
> Thanks.
> 
>   -Alessandro Guido

Because None mean 'use the default value'.  You probably want:
print('a', 'b', sep='', end='')
___
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] py3k: print function treats sep=None and end=None in an unintuitive way

2008-04-08 Thread Eric Smith
Alessandro Guido wrote:
> Can anybody please point me why print('a', 'b', sep=None, end=None) should
> produce "a b\n" instead of "ab"?
> I've read http://docs.python.org/dev/3.0/library/functions.html#print, 
> pep-3105 and some
> ml threads but did not find a good reason justifying such a strange behaviour.
> 
> Thanks.
> 
>   -Alessandro Guido

Because None means 'use the default value'.  You probably want:
print('a', 'b', sep='', end='')

 >>> import io
 >>> s = io.StringIO()
 >>> print('a', 'b', end='', sep='', file=s)
 >>> s.getvalue()
'ab'
 >>>
___
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] py3k: print function treats sep=None and end=None in an unintuitive way

2008-04-08 Thread Eric Smith
[Sorry for the dupes.  Lesson: never try and send mail from a moving train.]

Eric Smith wrote:
> Alessandro Guido wrote:
>> Can anybody please point me why print('a', 'b', sep=None, end=None) should
>> produce "a b\n" instead of "ab"?
>> I've read http://docs.python.org/dev/3.0/library/functions.html#print, 
>> pep-3105 and some
>> ml threads but did not find a good reason justifying such a strange 
>> behaviour.
>>
>> Thanks.
>>
>>  -Alessandro Guido
> 
> Because None means 'use the default value'.  You probably want:
> print('a', 'b', sep='', end='')
> 
>  >>> import io
>  >>> s = io.StringIO()
>  >>> print('a', 'b', end='', sep='', file=s)
>  >>> s.getvalue()
> 'ab'
>  >>>
> ___
> 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/eric%2Bpython-dev%40trueblade.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


[Python-Dev] [OT] Wingware IDE key for sprinters at PyCon

2008-04-08 Thread Trent Nelson
Anyone happen to have the key handy that Wingware were giving out to sprinters 
at PyCon?  For the life of me, I can't find what I did with that piece of 
paper.  If someone could forward me it off list, that'd be great.

Trent.
___
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] py3k: print function treats sep=N one and end=None in an unintuitive way

2008-04-08 Thread Alessandro Guido
Nick Coghlan wrote:
> So that print(a, b) does the right thing (i.e. matches the Python 2.x 
> print statement's behaviour)

AFAICS print(a, b) does the right thing because default values of "sep" and
"end" are ' ' and '\n' respectively, doesn't it?

Eric Smith wrote:
> Because None means 'use the default value'.  You probably want:
> print('a', 'b', sep='', end='')

I think this is a "not optimally designed" API
because you have to read the documentation to understand why

print('a', 'b', sep=None, end=None)

does not translate into the obvious:

«print strings 'a' and 'b' using no separator and no terminator»

but into:

«print strings 'a' and 'b' using the default separator and the default 
terminator»

However i'll just cope with it, Python is still the best language ;)

Thank you all for replying!

-Alessandro 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] how to easily consume just the parts of eggs that are good for you

2008-04-08 Thread zooko

On Mar 26, 2008, at 7:34 PM, Chris McDonough wrote:
> zooko wrote:

http://mail.python.org/pipermail/python-dev/2008-March/078243.html

>> Here is a simple proposal:  make the standard Python "import"   
>> mechanism notice eggs on the PYTHONPATH and insert them (into the   
>> *same* location) on the sys.path.
>> This eliminates the #1 problem with eggs -- that they don't  
>> easily  work when installing them into places other than your site- 
>> packages  and that if you allow any of them to be installed on  
>> your system then  they take precedence over your non-egg packages  
>> even you explicitly  put those other packages earlier in your  
>> PYTHONPATH.  (That latter  behavior is very disagreeable to more  
>> than a few prorgammers.)
>
> Sorry if I'm out of the loop and there's some subtlety here that  
> I'm disregarding, but it doesn't appear that either of the issues  
> you mention is a actually problem with eggs.  These are instead  
> problems with how eggs get installed by easy_install (which uses  
> a .pth file to extend sys.path).  It's reasonable to put eggs on  
> the PYTHONPATH manually (e.g. sys.path.append('/path/to/some.egg'))  
> instead of using easy_install to install them.

Yes, you are missing something.  While many programmers, such as  
yourself and Lennart Regebro (who posted to this thread) find the  
current eggs system to be perfectly convenient and to Just Work, many  
others, such as Glyph Lefkowitz (who posted to a related thread) find  
them to be so annoying that they actively ensure that no eggs are  
ever allowed to touch their system.

The reasons for this latter problem are two:

1.  You can't conveniently install eggs into a non-system directory,  
such as ~/my-python-stuff.

2.  If you allow even a single egg to be installed into your  
PYTHONPATH, it will change the semantics of your PYTHONPATH.

Both of these problems are directly caused by the need for eggs to  
hack your site.py.  If Python automatically added eggs found in the  
PYTHONPATH to the sys.path, both of these problems would go away.

I am skeptical that the current proposals to define a new database  
for installed packages will fare any better than the current eggs  
scheme does in this respect.

This issue is important to me, because the benefits of eggs grow  
superlinearly with the number of good programmers who use them.  They  
are a tool for re-using source code -- a tool for cooperation between  
programmers.  To gain the greatest benefits at this point we do not  
need to add new features to eggs, we need to make them more palatable  
to more good programmers.

I am skeptical that prorgammers are going to be willing to use a new  
database format.  They already have a database -- their filesystem --  
and they already have the tools to control it -- mv, rm, and  
PYTHONPATH.  Many of them already hate the existence the  
"easy_instlal.pth" database file, and I don't see why a new database  
file would be any different.

My proposal makes the current benefits of eggs -- clean, easy code re- 
use among programmers -- more compatible with their current tools --  
mv, rm, and PYTHONPATH.  It is also forward-compatible with more  
sophisticated proposals to add features like uninstall and operating  
system integration.

By the way, since I posted my proposal two weeks ago I have pointed a  
couple of Python hackers who currently refuse to use eggs at the URL:

http://mail.python.org/pipermail/python-dev/2008-March/078243.html

They both agreed that it made perfect sense.  I told one of them  
about the alternate proposal to define a new database file to contain  
a list of installed packages, and he sighed and rolled his eyes and  
said "So they are planning to reinvent apt!".

Regards,

Zooko

___
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] py3k: print function treats sep=None and end=None in an unintuitive way

2008-04-08 Thread Nick Coghlan
Alessandro Guido wrote:
> «print strings 'a' and 'b' using the default separator and the default 
> terminator»
> 
> However i'll just cope with it, Python is still the best language ;)

I definitely recommend getting used to this idiom - None is used to 
indicate missing (i.e. 'use the default value') arguments in many more 
cases than just the print function.

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] how to easily consume just the parts of eggs that are good for you

2008-04-08 Thread Paul Moore
On 08/04/2008, zooko <[EMAIL PROTECTED]> wrote:
>  By the way, since I posted my proposal two weeks ago I have pointed a
>  couple of Python hackers who currently refuse to use eggs at the URL:
>
>  http://mail.python.org/pipermail/python-dev/2008-March/078243.html
>
>  They both agreed that it made perfect sense.  I told one of them
>  about the alternate proposal to define a new database file to contain
>  a list of installed packages, and he sighed and rolled his eyes and
>  said "So they are planning to reinvent apt!".

I do think that a simple solution like that has some merit. It has two
significant downsides, however:

1. It requires that core Python "bless" the egg format to some extent
- something Guido has said he is unwilling to do.
2. It ignores the issue of package management completely. Personally,
I avoid anything that doesn't integrate with a unified package manager
(whether that be the Windows add/remove feature, or an
as-yet-to-be-built custom Python package manager is not important).

Filesystem commands do not a package manager make...

Paul.
___
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] how to easily consume just the parts of eggs that are good for you

2008-04-08 Thread Chris McDonough
zooko wrote:
> 
> On Mar 26, 2008, at 7:34 PM, Chris McDonough wrote:
>> zooko wrote:
> 
> http://mail.python.org/pipermail/python-dev/2008-March/078243.html
> 
>>> Here is a simple proposal:  make the standard Python "import"  
>>> mechanism notice eggs on the PYTHONPATH and insert them (into the  
>>> *same* location) on the sys.path.
>>> This eliminates the #1 problem with eggs -- that they don't easily  
>>> work when installing them into places other than your site-packages  
>>> and that if you allow any of them to be installed on your system 
>>> then  they take precedence over your non-egg packages even you 
>>> explicitly  put those other packages earlier in your PYTHONPATH.  
>>> (That latter  behavior is very disagreeable to more than a few 
>>> prorgammers.)
>>
>> Sorry if I'm out of the loop and there's some subtlety here that I'm 
>> disregarding, but it doesn't appear that either of the issues you 
>> mention is a actually problem with eggs.  These are instead problems 
>> with how eggs get installed by easy_install (which uses a .pth file to 
>> extend sys.path).  It's reasonable to put eggs on the PYTHONPATH 
>> manually (e.g. sys.path.append('/path/to/some.egg')) instead of using 
>> easy_install to install them.
> 
> Yes, you are missing something.  While many programmers, such as 
> yourself and Lennart Regebro (who posted to this thread) find the 
> current eggs system to be perfectly convenient and to Just Work, many 
> others, such as Glyph Lefkowitz (who posted to a related thread) find 
> them to be so annoying that they actively ensure that no eggs are ever 
> allowed to touch their system.
> 
> The reasons for this latter problem are two:
> 
> 1.  You can't conveniently install eggs into a non-system directory, 
> such as ~/my-python-stuff.

That's just not true.

$ export PYTHONPATH=/home/you/my-python-stuff/foo-1.3.egg
$ python
 >>> import foo

Eggs are directories (or zipfiles) that contain packages.  They happen to 
contain other metadata directories too, but these can be ignored if you just 
want to *use* them (as opposed to wanting to introspect metadata about them).

> 2.  If you allow even a single egg to be installed into your PYTHONPATH, 
> it will change the semantics of your PYTHONPATH.

I think you are mistaken.  The use of the .pth file that changes sys.path is a 
feature of easy_install, not of eggs.  You don't need to use any .pth file to 
put eggs on your PYTHONPATH.

Note that zc.buildout is a framework that installs eggs, and it doesn't rely at 
all on .pth files to automatically hack sys.path.  Instead, it munges console 
scripts to add each egg dir to sys.path.  This is pretty nasty too, but it does 
prove the point.

It is however true that you need to change sys.path to use an egg.  Is that 
what 
you're objecting to fundamentally?  You just don't want to have to change 
sys.path at all to use an egg?  Maybe you're objecting to the notion that an 
egg 
can contain more than one package.  There is functionally no difference between 
an egg and a directory full of packages.

> Both of these problems are directly caused by the need for eggs to hack 
> your site.py.  If Python automatically added eggs found in the 
> PYTHONPATH to the sys.path, both of these problems would go away.

I'm not sure what you mean.  Eggs don't hack site.py.  Eggs are just a 
packaging 
format.  easy_install doesn't hack site.py either.  It just puts a .pth file 
(the parsing of which is a feature of "core" Python itself, not any setuptools 
magic) in site packages and manages it.

It seems like you're advocating adding magic that you can't turn off (magical 
detection of eggs in an already site.py-approved packages directory) to defeat 
magic that you can turn off (by not using easy_install or .pth files).  At some 
level the magic you want to see built in to Python would almost certainly wind 
up doing what you hate by hacking sys.path unless you wanted to restrict eggs 
to 
containing a single package only.  And you wouldn't be able to turn it off 
except through some obscure environment variable setting.

> By the way, since I posted my proposal two weeks ago I have pointed a 
> couple of Python hackers who currently refuse to use eggs at the URL:
> 
> http://mail.python.org/pipermail/python-dev/2008-March/078243.html
> 
> They both agreed that it made perfect sense.  I told one of them about 
> the alternate proposal to define a new database file to contain a list 
> of installed packages, and he sighed and rolled his eyes and said "So 
> they are planning to reinvent apt!".

I think changing the Python core is the worst possible answer to this problem. 
"Don't use easy_install" is currently the best, AFAICT.

- C

___
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] how to easily consume just the parts of eggs that are good for you

2008-04-08 Thread Phillip J. Eby
At 10:01 AM 4/8/2008 -0700, zooko wrote:

>On Mar 26, 2008, at 7:34 PM, Chris McDonough wrote:
> > zooko wrote:
>
>http://mail.python.org/pipermail/python-dev/2008-March/078243.html
>
> >> Here is a simple proposal:  make the standard Python "import"
> >> mechanism notice eggs on the PYTHONPATH and insert them (into the
> >> *same* location) on the sys.path.
> >> This eliminates the #1 problem with eggs -- that they don't
> >> easily  work when installing them into places other than your site-
> >> packages  and that if you allow any of them to be installed on
> >> your system then  they take precedence over your non-egg packages
> >> even you explicitly  put those other packages earlier in your
> >> PYTHONPATH.  (That latter  behavior is very disagreeable to more
> >> than a few prorgammers.)
> >
> > Sorry if I'm out of the loop and there's some subtlety here that
> > I'm disregarding, but it doesn't appear that either of the issues
> > you mention is a actually problem with eggs.  These are instead
> > problems with how eggs get installed by easy_install (which uses
> > a .pth file to extend sys.path).  It's reasonable to put eggs on
> > the PYTHONPATH manually (e.g. sys.path.append('/path/to/some.egg'))
> > instead of using easy_install to install them.
>
>Yes, you are missing something.  While many programmers, such as
>yourself and Lennart Regebro (who posted to this thread) find the
>current eggs system to be perfectly convenient and to Just Work, many
>others, such as Glyph Lefkowitz (who posted to a related thread) find
>them to be so annoying that they actively ensure that no eggs are
>ever allowed to touch their system.
>
>The reasons for this latter problem are two:
>
>1.  You can't conveniently install eggs into a non-system directory,
>such as ~/my-python-stuff.

Wha?

>2.  If you allow even a single egg to be installed into your
>PYTHONPATH, it will change the semantics of your PYTHONPATH.

Only in the same way that manually putting an egg on the front of 
PYTHONPATH can be considered to "change the semantics" of your PYTHONPATH.


>Both of these problems are directly caused by the need for eggs to
>hack your site.py.  If Python automatically added eggs found in the
>PYTHONPATH to the sys.path, both of these problems would go away.

And add new ones.


>I am skeptical that the current proposals to define a new database
>for installed packages will fare any better than the current eggs
>scheme does in this respect.

The purpose for the installation database is to allow easy_install to 
eschew the use of .egg files or directories for anything other than 
multi-version installs.  Thus, no need to add those .egg files or 
directories to the head of the PYTHONPATH.  Conflicts would be 
handled at install time rather than runtime, in other words.


>I am skeptical that prorgammers are going to be willing to use a new
>database format.  They already have a database -- their filesystem --
>and they already have the tools to control it -- mv, rm, and
>PYTHONPATH.  Many of them already hate the existence the
>"easy_instlal.pth" database file, and I don't see why a new database
>file would be any different.

PEP 262 does not propose a database file -- it proposes the inclusion 
of a metadata file for each installed distribution.


>My proposal makes the current benefits of eggs -- clean, easy code re-
>use among programmers -- more compatible with their current tools --
>mv, rm, and PYTHONPATH.  It is also forward-compatible with more
>sophisticated proposals to add features like uninstall and operating
>system integration.

Actually, your current proposal doesn't work, unless you at least 
have some way to indicate which *version* of an egg should be 
automatically added to sys.path -- and some way to change 
that.  Otherwise, you might as well use the -m option to 
easy_install, and require() the eggs at runtime.  (Which needs 
neither .pth files nor site.py hacking.)

Meanwhile, my understanding is that the people who dislike eggs, 
dislike them because when they install a setuptools-based package, 
it's installed as an egg by default.  The installation database 
proposal (and by the way, people really should read and understand 
PEP 262, including the open issues, before trying to compete with 
it), will allow setuptools-based packages to install the 
"old-fashioned" way by default.  That is, not as eggs.  Similarly, 
easy_install would be able to skip installing .eggs unless you wanted 
multi-version support.

So, people who don't like eggs would never see them, since the only 
way you'd ever get them would be via easy_install -m, and they would 
never use it.


>By the way, since I posted my proposal two weeks ago I have pointed a
>couple of Python hackers who currently refuse to use eggs at the URL:
>
>http://mail.python.org/pipermail/python-dev/2008-March/078243.html
>
>They both agreed that it made perfect sense.  I told one of them
>about the alternate proposal to define a new database file to

Re: [Python-Dev] [OT] Wingware IDE key for sprinters at PyCon

2008-04-08 Thread Trent Nelson

All sorted, thanks.

> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]
> On Behalf Of Trent Nelson
> Sent: 08 April 2008 15:48
> To: python-dev@python.org
> Subject: [Python-Dev] [OT] Wingware IDE key for sprinters at PyCon
>
> Anyone happen to have the key handy that Wingware were giving
> out to sprinters at PyCon?  For the life of me, I can't find
> what I did with that piece of paper.  If someone could
> forward me it off list, that'd be great.
>
> Trent.
> ___
> 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/tnelson%40on
resolve.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] [Distutils] how to easily consume just the parts of eggs that are good for you

2008-04-08 Thread zooko
On Apr 8, 2008, at 11:27 AM, Lloyd Kvam wrote:
>
> When I wear my sysadmin hat, eggs become a nuisance.
...
> As a developer, eggs are great.
...
> Fortunately, distutils includes tools like bdist_rpm so that python
> modules can be packaged for easy processing by the system package
> manager.  So once I need to switch back to a sysadmin role, I can use
> the system tools to install and track packages.

This is the same experience I have.  I rely on setuptools and eggs  
extensively in developing our software, and I use setuptools and eggs  
as the primary method of giving our source code to other programmers.

But no software is ever installed on our production servers unless  
that software is in .deb form in an apt-gettable repository, and this  
requirement is unlikely to change for the forseeable future.

Regards,

Zooko

___
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] Changing all network-oriented tests to facilitate (virtually unlimited) parallel test execution [Issue#: 2550]

2008-04-08 Thread Gregory P. Smith
On Tue, Apr 8, 2008 at 5:00 AM, Trent Nelson <[EMAIL PROTECTED]> wrote:

>
> I've forwarding my most recent update to issue 2550 here such that the
> proposed patch (and in general, the approach to network-oriented test cases)
> can be vetted by a wider audience:
>
> http://bugs.python.org/file9980/trunk.2550-2.patch
>
> This patch works towards fixing a large proportion of the tests that were
> written in such a way that often leads to buildbot errors when port
> conflicts arise.  With this patch applied, I can run many instances of the
> test suite in parallel and none of the network-oriented tests fail (which
> they do currently if you try and do this).
>
> Plenty of discussion (mostly me replying to my own comments) on the
> subject at: http://bugs.python.org/issue2550.
>
> Anyone have any issues with this new approach?  I'm particularily
> interested in whether or not people disagree with the assumption I've drawn
> regarding never using SO_REUSEADDR in tests for TCP/IP sockets (see below).
>
>Trent.


I think your assumptions are fair.

Note that not using SO_REUSEADDR can reserve the port for a few minutes
beyond the actual unbinding destruction of the server socket on some OSes
but with tens of thousands of ports available and likely not more than 1-200
being needed by a full test suite run and how long the test suite takes to
run I think that is acceptable and is not a problem we're likely to ever run
into (fix it only iffwe ever do).

-gps


>
>
>
> 
> From: [EMAIL PROTECTED]
> [EMAIL PROTECTED] On Behalf Of Trent Nelson [
> [EMAIL PROTECTED]
> Sent: 08 April 2008 12:49
> To: [EMAIL PROTECTED]
> Subject: [issue2550] SO_REUSEADDR doesn't have the same semantics on
> Windowsas on Unix
>
> Trent Nelson <[EMAIL PROTECTED]> added the comment:
>
> Invested quite a few cycles on this issue last night.  The more time I
> spent on it, the more I became convinced that every single test working
> with sockets should be changed in one fell swoop in order to facilitate
> (virtually unlimited) parallel test execution without fear of port
> conflicts.
>
> I've attached a second patch, trunk.2550-2.patch, which is my progress
> so far on doing just this.  The main changes can be expressed by the
> following two points:
>
> a) do whatever it takes in network-oriented tests to ensure
>   unique ports are obtained (relying on the bind_port() and
>   find_unused_port() methods exposed by test_support)
>
> b) never, ever, ever call SO_REUSEADDR on a socket from a test;
>   because we're putting so much effort into obtaining a unique
>   port, this should never be necessary -- in the rare cases that
>   our attempts to obtain a unique port fail, then we absolutely
>   should fail with EADDRINUSE, as the ability to obtain a unique
>   port for the duration of a client/server test is an invariant
>   that we *must* be able to depend upon.  If the invariant is
>   broken, fail immediately (don't mask the problem with
>   SO_REUSEADDR).
>
> With this patch applied, I can spawn a handful of Python processes and
> run the entire test suite (without -r, ensuring all tests are run in
> the same order, which should encourage port conflicts (if there were
> any)) without any errors*.  Doing that now is completely and utterly
> impossible.
>
> [*] Well, almost without error.  All the I/O related tests that try and
> open @test fail.
>
> I believe there's still outstanding work to do with this patch with
> regards to how the intracacies of SO_REUSEADDR and SO_EXCLUSIVEADDRUSE
> should be handled in the rest of the stdlib.  I'm still thinking about
> the best approach for this.  However, the patch as it currently stands
> is still quite substantial so I wanted to get it out sooner rather than
> later for review.
>
> (I'll forward this to python-dev@ to try and encourage more eyes from
> people with far more network-fu than I.)
>
> Added file: http://bugs.python.org/file9980/trunk.2550-2.patch
>
> __
> Tracker <[EMAIL PROTECTED]>
> 
> __
> ___
> Python-bugs-list mailing list
> Unsubscribe:
> http://mail.python.org/mailman/options/python-bugs-list/tnelson%40onresolve.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/greg%40krypto.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] how to easily consume just the parts of eggs that are good for you

2008-04-08 Thread Greg Ewing
zooko wrote:

> 1.  You can't conveniently install eggs into a non-system directory,  
> such as ~/my-python-stuff.
> 
> 2.  If you allow even a single egg to be installed into your  
> PYTHONPATH, it will change the semantics of your PYTHONPATH.

I discovered another annoyance with eggs the other day -- it
seems that tracebacks referring to egg-resident files contain the
pathname of some temporary directory that existed when the egg
was being packaged, rather than the one it actually exists in
at run time.

-- 
Greg
___
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] Changing all network-oriented tests to facilitate (virtually unlimited) parallel test execution [Issue#: 2550]

2008-04-08 Thread Trent Nelson
Committed the patch in r62234.  Hopefully the work paid off!  (He says moments 
before all the buildbots turn red...)


From: Gregory P. Smith [mailto:[EMAIL PROTECTED]
Sent: 08 April 2008 20:58
To: Trent Nelson
Cc: python-dev@python.org
Subject: Re: [Python-Dev] Changing all network-oriented tests to facilitate 
(virtually unlimited) parallel test execution [Issue#: 2550]



On Tue, Apr 8, 2008 at 5:00 AM, Trent Nelson <[EMAIL PROTECTED]> wrote:

I've forwarding my most recent update to issue 2550 here such that the proposed 
patch (and in general, the approach to network-oriented test cases) can be 
vetted by a wider audience:

http://bugs.python.org/file9980/trunk.2550-2.patch

This patch works towards fixing a large proportion of the tests that were 
written in such a way that often leads to buildbot errors when port conflicts 
arise.  With this patch applied, I can run many instances of the test suite in 
parallel and none of the network-oriented tests fail (which they do currently 
if you try and do this).

Plenty of discussion (mostly me replying to my own comments) on the subject at: 
http://bugs.python.org/issue2550.

Anyone have any issues with this new approach?  I'm particularily interested in 
whether or not people disagree with the assumption I've drawn regarding never 
using SO_REUSEADDR in tests for TCP/IP sockets (see below).

   Trent.

I think your assumptions are fair.

Note that not using SO_REUSEADDR can reserve the port for a few minutes beyond 
the actual unbinding destruction of the server socket on some OSes but with 
tens of thousands of ports available and likely not more than 1-200 being 
needed by a full test suite run and how long the test suite takes to run I 
think that is acceptable and is not a problem we're likely to ever run into 
(fix it only iffwe ever do).

-gps





From: [EMAIL PROTECTED] [EMAIL 
PROTECTED]] On Behalf Of Trent Nelson [EMAIL 
PROTECTED]]
Sent: 08 April 2008 12:49
To: [EMAIL PROTECTED]
Subject: [issue2550] SO_REUSEADDR doesn't have the same semantics on Windows
as on Unix

Trent Nelson <[EMAIL PROTECTED]> added the comment:

Invested quite a few cycles on this issue last night.  The more time I
spent on it, the more I became convinced that every single test working
with sockets should be changed in one fell swoop in order to facilitate
(virtually unlimited) parallel test execution without fear of port
conflicts.

I've attached a second patch, trunk.2550-2.patch, which is my progress
so far on doing just this.  The main changes can be expressed by the
following two points:

a) do whatever it takes in network-oriented tests to ensure
  unique ports are obtained (relying on the bind_port() and
  find_unused_port() methods exposed by test_support)

b) never, ever, ever call SO_REUSEADDR on a socket from a test;
  because we're putting so much effort into obtaining a unique
  port, this should never be necessary -- in the rare cases that
  our attempts to obtain a unique port fail, then we absolutely
  should fail with EADDRINUSE, as the ability to obtain a unique
  port for the duration of a client/server test is an invariant
  that we *must* be able to depend upon.  If the invariant is
  broken, fail immediately (don't mask the problem with
  SO_REUSEADDR).

With this patch applied, I can spawn a handful of Python processes and
run the entire test suite (without -r, ensuring all tests are run in
the same order, which should encourage port conflicts (if there were
any)) without any errors*.  Doing that now is completely and utterly
impossible.

[*] Well, almost without error.  All the I/O related tests that try and
open @test fail.

I believe there's still outstanding work to do with this patch with
regards to how the intracacies of SO_REUSEADDR and SO_EXCLUSIVEADDRUSE
should be handled in the rest of the stdlib.  I'm still thinking about
the best approach for this.  However, the patch as it currently stands
is still quite substantial so I wanted to get it out sooner rather than
later for review.

(I'll forward this to python-dev@ to try and encourage more eyes from
people with far more network-fu than I.)

Added file: http://bugs.python.org/file9980/trunk.2550-2.patch

__
Tracker <[EMAIL PROTECTED]>

__
___
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/tnelson%40onresolve.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-d

Re: [Python-Dev] how to easily consume just the parts of eggs that are good for you

2008-04-08 Thread Ben Finney
zooko <[EMAIL PROTECTED]> writes:

> I am skeptical that prorgammers are going to be willing to use a new
> database format. They already have a database -- their filesystem --
> and they already have the tools to control it -- mv, rm, and
> PYTHONPATH. Many of them already hate the existence the
> "easy_instlal.pth" database file, and I don't see why a new database
> file would be any different.

Moreover, many of us already have a database of *all* packages on the
system, not just Python-language ones: the package database of our
operating system. Adding another, parallel, database which needs
separate maintenance, and only applies to Python packages, is not a
step forward in such a situation.

> They both agreed that it made perfect sense. I told one of them
> about the alternate proposal to define a new database file to
> contain a list of installed packages, and he sighed and rolled his
> eyes and said "So they are planning to reinvent apt!".

That's pretty much my reaction, too.

-- 
 \  "Contentment is a pearl of great price, and whosoever procures |
  `\it at the expense of ten thousand desires makes a wise and |
_o__)   happy purchase."  -- J. Balguy |
Ben Finney

___
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] py3k: print function treats sep=None and end=None in an unintuitive way

2008-04-08 Thread Scott David Daniels
Alessandro Guido wrote:
> Nick Coghlan wrote:
> Eric Smith wrote:
>> Because None means 'use the default value'.  You probably want:
>> print('a', 'b', sep='', end='')
> 
> I think this is a "not optimally designed" API
> because you have to read the documentation to understand why

Excuse me, I don't know about you, but I don't mind a language
with a document to consult.  I actually wasn't born understanding
_any_ computer (or for that matter natural) language.

0Scott David Daniels
[EMAIL PROTECTED]



___
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] unittest's redundant assertions: assertsvs. failIf/Unlesses

2008-04-08 Thread Terry Reedy

"Michael Foord" <[EMAIL PROTECTED]> wrote in message 
news:[EMAIL PROTECTED]
| > Someone please open a bug for this task.
| >
| >
| This sounds like a good compromise and I'm happy to take on the cleanup
| - unless someone else beats me to it. I guess it should wait until 3.0
| final is out of the door before adding the DeprecationWarnings.

I think, however, that the docs should be revised now, for 2.6/3.0.
In the list of methods under TestCase Objects, the preferred method of each 
pair (or triplit) should be given first and the others marked as future 
deprecations, not recommended for new test code.  The explanations of the 
methods should use the preferred names.  So failIf/assertFalse should be 
reversed in order (assuming that failIf is the one to go) and the text "The 
inverse of the failUnless() method" should be changed to "The inverse of 
the assertTrue() method" (if that is the one to be kept).

I would also (lesser priority) revise examples to only use the preferred 
names.  The would make things easiest for new unittest users that are not 
Java refugees.

tjr



___
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] [Distutils] how to easily consume just the parts of eggs that are good for you

2008-04-08 Thread Phillip J. Eby
At 10:49 PM 4/8/2008 -0400, Stanley A. Klein wrote:
>On Tue, April 8, 2008 9:37 pm, Ben Finney
><[EMAIL PROTECTED]> wrote:
> > Date: Wed, 09 Apr 2008 11:37:07 +1000
> > From: Ben Finney <[EMAIL PROTECTED]>
> > Subject: Re: [Distutils] how to easily consume just the parts of eggs
> >   thatare good for you
> > To: [EMAIL PROTECTED]
> >
> >
> > zooko <[EMAIL PROTECTED]> writes:
> >> eyes and said "So they are planning to reinvent apt!".
> >
> > That's pretty much my reaction, too.
>
>I have the same reaction.

I'm curious.  Have any of you actually read PEP 262 in any detail?  I 
have seen precious little discussion so far that doesn't appear to be 
based on significant misunderstandings of either the purpose of 
reviving the PEP, or the mechanics of its proposed implementation.


>I have tried in the past to use easy_install, but have run into problems
>because there is no communication between easy_install and the rpm
>database, resulting in failure of easy_install to recognize that
>dependencies have already been installed using rpms.

This problem doesn't exist with Python 2.5, unless you're using a 
platform that willfully strips out the installation information that 
Python 2.5 provides for these packages.


>A database focused only on Python packages is highly inappropriate for
>Linux systems, violates the Linux standards, and creates problems because
>eggs are not coordinated with the operating system package manager.

The revamp of PEP 262 is aimed at removing .egg files and directories 
from the process, by allowing system packagers to tell Python what 
files belong to them and should not be messed with.  And conversely, 
allowing systems and installation targets *without* package managers 
to safely manage their Python installations.


>   The
>way to achieve a database for Python would be to provide tools for
>conversion of eggs to rpms and debs,

Such tools already exist, although the conversion takes place from 
source distributions rather than egg distributions.


>to have eggs support conformance to
>the LSB and FHS,

Applying LSB and FHS to the innards of Python packages makes as much 
sense as applying them to the contents of Java .jar files -- i.e., 
none.  If it's unchanging data that's part of a program or library, 
then it's a program or library, just like static data declared in a C 
program or library.  Whether the file extension is .py, .so, or even 
.png is irrelevant.

___
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] unittest's redundant assertions: assertsvs. failIf/Unlesses

2008-04-08 Thread Fred Drake
On Apr 8, 2008, at 11:47 PM, Terry Reedy wrote:
> I think, however, that the docs should be revised now, for 2.6/3.0.
> In the list of methods under TestCase Objects, the preferred method  
> of each
> pair (or triplit) should be given first and the others marked as  
> future
> deprecations, not recommended for new test code.


+1 !

This kind of information, once known, should be included in all  
maintained versions of the documentation so that users can build good  
coding habits, or have more time to adjust existing code.


   -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