Re: [Python-Dev] stabilizing builds

[Michael Hudson]

"Gregory P. Smith" <[EMAIL PROTECTED]> writes:

> Using BerkeleyDB 3.2 often segfaults for me; using 3.3 often hangs in
> the test suite.  Both are so old I don't see much motivation to track
> the issues down.

My goal is to not have http://www.python.org/dev/buildbot/ go red
randomly because of erratic bsddb tests, so I'd definitely prefer it
if we didn't build bsddb3 when a not-supported bsddb is found.

Things seem much better today after your recent changes though, so
thanks for that :)

Cheers,
mwh

-- 
  at any rate, I'm satisfied that not only do they know which end of
  the pointy thing to hold, but where to poke it for maximum effect.
  -- Eric The Read, asr, on google.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] The path module PEP

[Michael Hoffman]

[Ian Bickling]

> I'm personally +1 on /.  I think people who think it is confusing are
> giving a knee-jerk reaction.  It's very easy to tell the difference
> between file-related code and math-related code, and / is currently only
> used for math.  In contrast, + is used for concatenation and addition,
> and these are far more ambiguous from context -- but still it doesn't
> cause that many problems.

I was initially -0 on / but I have found it quite useful and a lot
simpler than a lot of joinpath()s over time.

So +1 on / for me.
-- 
Michael Hoffman <[EMAIL PROTECTED]>
European Bioinformatics Institute

___
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] The path module PEP

[Michael Hoffman]

[Tony Meyer]

> It would be great (and save a lot of rehashing) if you could go over
> the python-dev discussion and add the relevant parts (for example,
> whether to include the __div__ hack) to the PEP:
>
> 

In particular the points about Path being able to be a drop-in
replacement for str/unicode are useful ones, and explain the use of
joinpath() etc. It is really useful that I can use a Path anywhere I
might have used an str and not have to worry about the conversions.
-- 
Michael Hoffman <[EMAIL PROTECTED]>
European Bioinformatics Institute

___
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] Know anyone interested in a Google internship?

[skip]

Guido> Google is looking to fill an unprecedented number of student
Guido> intern positions this summer, at several US locations 

Maybe a Python Job Board post would be in order...

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] The path module PEP

[Toby Dickenson]

On Tuesday 24 January 2006 20:22, BJörn Lindqvist wrote:

> Replacing glob.glob
> ---
> 
> glob.glob("/lib/*.so")
> ==>
> Path("/lib").glob("*.so")

This definition seems confusing because it splits the glob pattern string in 
two ('/lib', and '*.so'). Unless there is an intention to change the behavior 
of the current glob module, why not make the glob method parameterless:

glob.glob("/lib/*.so")
==>
Path("/lib/*.so").glob()


Possible confusion with the one parameter version:

Does glob matching happen on the first half too? That is, does 
Path('*').glob('*.so') match files in any directory, or only directories 
whose name is an asterisk.

What behavior can I expect from Path('/foo/').glob(bar), where bar is some 
arbitrary string? It could be reasonable to expect that it would only match 
filenames inside the foo directory. However it could also be reasonable to 
expect to use bar=='/etc/*'


-- 
Toby Dickenson
___
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] The path module PEP

[Jason Orendorff]

On 1/25/06, Toby Dickenson <[EMAIL PROTECTED]> wrote:
> On Tuesday 24 January 2006 20:22, BJörn Lindqvist wrote:
> > #Replacing glob.glob
> > glob.glob("/lib/*.so")
> > ==>
> > Path("/lib").glob("*.so")
>
> This definition seems confusing because it splits the glob pattern string in
> two ('/lib', and '*.so'). [...]

Well, let's make this look more like real code:

#line 1
LIB_DIR = "/lib"
==>
LIB_DIR = Path("/lib")

#line 296
libs = glob.glob(os.path.join(LIB_DIR, "*.so"))
==>
libs = LIB_DIR.files("*.so")

Clearer?  In d.files(pattern), d is simply the root directory for the
search.  The same is true of all the searching methods: dirs(),
walkfiles(), walkdirs(), etc.

I actually never use path.glob().  For example, here files() is
actually more accurate, and the word "files" is surely clearer than
"glob".  Given files(), dirs(), and listdir(), I have never found a
real use case for glob().

-j
___
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] The path module PEP

[Jason Orendorff]

On 1/24/06, Ian Bicking <[EMAIL PROTECTED]> wrote:
> There's kind of a lot of methods in here, which is a little bothersome.
> It also points towards the motivation for the class -- too many
> options in too many places in the stdlib.  But throwing them *all* in
> one class consolidates but doesn't simplify, especially with duplicate
> functionality.

I agree.

Let me explain why there's so much cruft in path.py.  The design is
heavily skewed toward people already very familiar with the existing
stdlib equivalents, because that is the market for third-party
modules.  I think my users want to type p.methodname() for whatever
method name they already know, and have it *just work*.   A sloppy API
you've already learned is easier to pick up than a clean API you've
never seen before.  Ergo, cruft.

A stdlib Path should have different design goals.  It should have less
redundancy, fewer methods overall, and PEP-8-compliant names.

-j
___
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] The path module PEP

[BJörn Lindqvist]

My comments on the issues. It was easier this way than trying to reply
on every message individually.

Inheritance from string (Jason)

This issue has been brought up before when people were discussing the
path module. I think the consensus is that, while the inheritance
isn't pure, practicality beats purity. It would require to big changes
to Python and would break to much existing code to not extend string.

I'll add this to Resolved Issues if nobody minds.

* http://mail.python.org/pipermail/python-dev/2001-August/016663.html
* http://mail.python.org/pipermail/python-dev/2001-August/016665.html
* http://mail.python.org/pipermail/python-list/2005-July/291091.html
* http://mail.python.org/pipermail/python-list/2005-July/291152.html


Remove __div__ (Ian, Jason, Michael, Oleg)

This is one of those where everyone (me too) says "I don't care either
way." If that is so, then I see no reason to change it unless someone
can show a scenario in which it hurts readability. Plus, a few people
have said that they like the shortcut.

* http://mail.python.org/pipermail/python-list/2005-July/292251.html
* http://mail.python.org/pipermail/python-dev/2005-June/054496.html
* http://mail.python.org/pipermail/python-list/2005-July/291628.html
* http://mail.python.org/pipermail/python-list/2005-July/291621.html


Remove redundant methods (Eric, Ian, Jason, Ronald, Toby)

I think it is a good idea to take out some of Path's
methods. Especially the ones that exist as both methods and
properties. I have updated the pep and dumped basename(), dirname(),
splitdrive() and splitext().  I think that glob() should also go away
because I can't of the top of my head think of a scenario where it
would be suitable over listdir(), dirs() or files(). Plus, for
contrived examples; like glob.glob("/*bin/*foo*") the Path way doesn't
look so good: Path("/").glob("*bin/*foo*").


Renaming methods because of PEP 8 (Gustavo, Ian, Jason)

I'm personally not keen on that. I like most of the names as they
are. abspath(), joinpath(), realpath() and splitall() looks so much
better than abs_path(), join_path(), real_path() and split_all() in my
eyes. If someone like the underscores I'll add it to Open Issues.


Removing open() and methods that manipulate the whole file at once
(Ian, Jason)

I think this is settled with the addition of the with statement? My
idea when scrubbing these methods was that it would make it easier to
get the PEP accepted. However, even with with, these methods save some
typing.

* http://mail.python.org/pipermail/python-dev/2005-June/054439.html
* http://mail.python.org/pipermail/python-list/2005-July/291435.html


?time properties and get?time() methods

Clearly, Path has either the properties or the methods, not both at
once. Yet another "I don't care either way."

* http://mail.python.org/pipermail/python-dev/2005-June/054439.html
* http://mail.python.org/pipermail/python-list/2005-July/291424.html
* http://mail.python.org/pipermail/python-list/2005-July/291460.html


I have also the corrected the copy-paste errors I inadvertedly
introduced. Path should *not* have an __iter__. :)

* match() and matchcase() wraps the fnmatch.fnmatch() and
  fnmatch.fnmatchcase() functions. I believe that the renaming is
  uncontroversial and that the introduction of matchcase() makes it so
  the whole fnmatch module can be deprecated.

I have created an implementation of Path that corresponds to the
specification in the PEP (which I hope will appear on
www.python.org/peps soon). It is based on Reinhold's (Georg Brandl)
implementation from pre-PEP threads in c.l.p last summer. But I have
no place to upload it. I would also like if some people wants to
co-author this PEP with me - it's really neither my PEP nor my module.

--
mvh Björn
___
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] The path module PEP

[Oleg Broytmann]

On Wed, Jan 25, 2006 at 09:37:04PM +0100, BJ?rn Lindqvist wrote:
> Remove __div__ (Ian, Jason, Michael, Oleg)

   I didn't say "remove". Exactly opposite - I am enamoured by the beauty
of the syntax! (-:

Oleg.
-- 
 Oleg Broytmannhttp://phd.pp.ru/[EMAIL PROTECTED]
   Programmers don't die, they just GOSUB without RETURN.
___
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] The path module PEP

[Ian Bicking]

BJörn Lindqvist wrote:
> * match() and matchcase() wraps the fnmatch.fnmatch() and
>   fnmatch.fnmatchcase() functions. I believe that the renaming is
>   uncontroversial and that the introduction of matchcase() makes it so
>   the whole fnmatch module can be deprecated.

The renaming is fine with me.  I generally use the fnmatch module for 
wildcard matching, not necessarily against path names.  Path.match 
doesn't replace that functionality.  Though fnmatch.translate isn't even 
publically documented, which is the function I actually tend to use.

Though it seems a little confusing to me that glob treats separators 
specially, and that's not implemented at the fnmatch level.  So 
Path('/a/b/d/c').match('a/*/d') is true, but Path('/').walk('a/*/d') 
won't return Path('/a/b/c/d').  I think .match() should be fixed.  But I 
don't think fnmatch should be changed.

I'm actually finding myself a little confused by the glob arguments (if 
the glob contains '/'), now that I really think about them.

-- 
Ian Bicking  /  [EMAIL PROTECTED]  /  http://blog.ianbicking.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] The path module PEP

[Ian Bicking]

John J Lee wrote:
> On Tue, 24 Jan 2006, Ian Bicking wrote:
> [...]
> 
>>Losing .open() would make it much harder for anyone wanting to write, 
>>say, a URI library that implements the Path API.
> 
> [...]
> 
> Why?  Could you expand a bit?
> 
> What's wrong with urlopen(filesystem_path_instance) ?

My example shows this more clearly I think:

   def read_config(path):
   text = path.open().read()
   ... do something ...

If I implement a URI object with an .open() method, then I can use it 
with this function, even though read_config() was written with file 
paths in mind.  But without it that won't work:

   def read_config(path):
   text = open(path).read()
   ...

-- 
Ian Bicking  /  [EMAIL PROTECTED]  /  http://blog.ianbicking.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] The path module PEP

[John J Lee]

[Ian Bicking]
>Losing .open() would make it much harder for anyone wanting to write, 
>say, a URI library that implements the Path API.

[John]
> Why?  Could you expand a bit?
> 
> What's wrong with urlopen(filesystem_path_instance) ?

[Ian]
>def read_config(path):
>text = path.open().read()
>... do something ...

I should have expected that answer, but couldn't believe that you think
it's a good idea to implement that obese filesystem path API for URLs ;-)

Shouldn't we instead have:

 a) .open()-able objects blessed in the stdlib & stdlib docs, as a
separate interface from the path interface (I guess that would be an
argument in favour of path implementing that one-method interface, as long
as it's not tied too tightly to the fat path interface)

 b) a path object with a thinner interface (I know you've already
expressed that preference yourself...)?


John
___
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] The path module PEP

[John J Lee]

On Tue, 24 Jan 2006, Ian Bicking wrote:
[...]
> Losing .open() would make it much harder for anyone wanting to write, 
> say, a URI library that implements the Path API.
[...]

Why?  Could you expand a bit?

What's wrong with urlopen(filesystem_path_instance) ?


John
___
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] The path module PEP

[Tony Meyer]

> Remove __div__ (Ian, Jason, Michael, Oleg)
>
> This is one of those where everyone (me too) says "I don't care either
> way." If that is so, then I see no reason to change it unless someone
> can show a scenario in which it hurts readability. Plus, a few people
> have said that they like the shortcut.
>
> * http://mail.python.org/pipermail/python-list/2005-July/292251.html
> * http://mail.python.org/pipermail/python-dev/2005-June/054496.html
> * http://mail.python.org/pipermail/python-list/2005-July/291628.html
> * http://mail.python.org/pipermail/python-list/2005-July/291621.html

Well, if you include the much larger discussion on python-list,  
people (including me) have said that removing __div__ is a good  
idea.  If it's included in the PEP, please at least include a  
justification and cover the problems with it.  The vast majority of  
people (at least at the time) were either +0 or -0, not +1.  +0's are  
not justification for including something.

Against it:

  * Zen: Beautiful is better than ugly. Explicit is better than  
implicit. Readability counts. There should be one-- and preferably  
only one --obvious way to do it.

  * Not every platform that Python supports has '/' as the path  
separator.  Windows, a pretty major one, has '\'.  I have no idea  
what various portable devices use, but there's a reasonable chance  
it's not '/'.

  * It's being used to mean "join", which is the exact opposite  
of /'s other meaning ("divide").

  * Python's not Perl.  We like using functions and not symbols.

> Renaming methods because of PEP 8 (Gustavo, Ian, Jason)
>
> I'm personally not keen on that. I like most of the names as they
> are. abspath(), joinpath(), realpath() and splitall() looks so much
> better than abs_path(), join_path(), real_path() and split_all() in my
> eyes. If someone like the underscores I'll add it to Open Issues.

+1 to following PEP 8.  These aren't built-ins, it's a library  
module.  In addition to the PEP, underscores make it much easier to  
read, especially for those for whom English is not their first language.

=Tony.Meyer
___
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] The path module PEP

[Phillip J. Eby]

At 11:25 AM 1/26/2006 +1300, Tony Meyer wrote:
>Against it:
>
>   * Zen: Beautiful is better than ugly. Explicit is better than
>implicit. Readability counts. There should be one-- and preferably
>only one --obvious way to do it.
>
>   * Not every platform that Python supports has '/' as the path
>separator.  Windows, a pretty major one, has '\'.

"/" also works on Windows, and the Python distutils already set the 
precedent of requiring /-separated paths on *all* platforms, converting 
them to os.sep behind the scenes.

I'd also note that using the / operator seems to me to be a big win on 
"beautiful is better than ugly".  Path-joining code is mighty ugly without 
it, and / is more readable as well.

It'd be nice to see the urllib modules grow a URL type supporting this 
operator, among other path operators.

I would also suggest that as with the individual posixpath, ntpath, etc. 
libraries today, we should be able to import NTPath and PosixPath classes 
directly from those modules, for code that needs to manipulate a path for 
some system other than the one it's running on.

___
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] The path module PEP

[Ian Bicking]

Tony Meyer wrote:
>>Remove __div__ (Ian, Jason, Michael, Oleg)
>>
>>This is one of those where everyone (me too) says "I don't care either
>>way." If that is so, then I see no reason to change it unless someone
>>can show a scenario in which it hurts readability. Plus, a few people
>>have said that they like the shortcut.
>>
>>* http://mail.python.org/pipermail/python-list/2005-July/292251.html
>>* http://mail.python.org/pipermail/python-dev/2005-June/054496.html
>>* http://mail.python.org/pipermail/python-list/2005-July/291628.html
>>* http://mail.python.org/pipermail/python-list/2005-July/291621.html
> 
> 
> Well, if you include the much larger discussion on python-list,  
> people (including me) have said that removing __div__ is a good  
> idea.  If it's included in the PEP, please at least include a  
> justification and cover the problems with it.  The vast majority of  
> people (at least at the time) were either +0 or -0, not +1.  +0's are  
> not justification for including something.

If it were possible to use .join() for joining paths, I think I wouldn't 
mind so much.  But reusing a string method for something very different 
seems like a bad idea.  So we're left with .joinpath().  Still better 
than os.path.join() I guess, but only a little.  I guess that's why I'm 
+1 on /.

> Against it:
> 
>   * Zen: Beautiful is better than ugly. Explicit is better than  
> implicit. Readability counts. There should be one-- and preferably  
> only one --obvious way to do it.

I think / is pretty.  I think it reads well.  There's already some 
inevitable redundancy in this interface.  I use os.path.join so much 
that I know anything I use will feel readable quickly, but I also think 
I'll find / more appealing.

>   * Not every platform that Python supports has '/' as the path  
> separator.  Windows, a pretty major one, has '\'.  I have no idea  
> what various portable devices use, but there's a reasonable chance  
> it's not '/'.

I believe all platforms support /; at least Windows and Mac do, in 
addition to their native separators.  I assume any platform that 
supports filesystem access will support / in Python.

If anything, a good shortcut for .joinpath() will at least encourage 
people to use it, thus discouraging hardcoding of path separators.  I 
expect it would encourage portable paths.

Though Path('/foo') / '/bar' == Path('/bar'), which is *not* intuitive, 
though in the context of "join" it's not as surprising.  So that is a 
problem.  If / meant "under this path" then that could be a useful 
operator (in that I'd really like such an operator or method).  Either 
paths would be forced to be under the original path, or it would be an 
error if they somehow escaped.  Currently there's no quick-and-easy way 
to ensure this, except to join the paths, do abspath(), then confirm 
that the new path starts with the old path.

>   * It's being used to mean "join", which is the exact opposite  
> of /'s other meaning ("divide").
> 
>   * Python's not Perl.  We like using functions and not symbols.

A little too heavy on the truisms.  Python isn't the anti-Perl.

>>Renaming methods because of PEP 8 (Gustavo, Ian, Jason)
>>
>>I'm personally not keen on that. I like most of the names as they
>>are. abspath(), joinpath(), realpath() and splitall() looks so much
>>better than abs_path(), join_path(), real_path() and split_all() in my
>>eyes. If someone like the underscores I'll add it to Open Issues.
> 
> 
> +1 to following PEP 8.  These aren't built-ins, it's a library  
> module.  In addition to the PEP, underscores make it much easier to  
> read, especially for those for whom English is not their first language.

I don't find abs_path() much easier to read than abspath() -- neither is 
a full name.  absolute_path() perhaps, but that is somewhat redundant; 
absolute()...?  Eh.

Precedence in naming means something, and in this case all the names 
have existed for a very long time (as long as Python?)  PEP 8 encourages 
following naming precedence.  While I don't see a need to match every 
existing function with a method, to the degree they do match I see no 
reason why we shouldn't keep the names.  And I see reasons why the names 
shouldn't be changed.


-- 
Ian Bicking  /  [EMAIL PROTECTED]  /  http://blog.ianbicking.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] The path module PEP

[Charles Cazabon]

Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> 
> I'd also note that using the / operator seems to me to be a big win on 
> "beautiful is better than ugly".

It screams "magic" in a very un-Pythonic (and possibly very Perl-like) way.
I'm not aware of any other part of the standard library grossly abusing
standard operators in this way.  As others have noted, "/" is being used here
to mean precisely the opposite of what it means in every other use in Python,
which alone should be justification for getting rid of it.

Charles
-- 
---
Charles Cazabon   <[EMAIL PROTECTED]>
GPL'ed software available at:   http://pyropus.ca/software/
---
___
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] / as path join operator (was: Re: The path module PEP)

[John J Lee]

On Thu, 26 Jan 2006, Tony Meyer wrote:
[...]
> Well, if you include the much larger discussion on python-list,  
> people (including me) have said that removing __div__ is a good  
> idea.  If it's included in the PEP, please at least include a  
> justification and cover the problems with it.  The vast majority of  
> people (at least at the time) were either +0 or -0, not +1.  +0's are  
> not justification for including something.



FWLIW, I'm definitely +1 on using / as a path join operator.


>   * It's being used to mean "join", which is the exact opposite  
> of /'s other meaning ("divide").

But it's a very readable way to write a common operation.  Perhaps one
reason the discrepancy you point out doesn't bother me is that division is
the least-used of the +-*/ arithmetic operations.

Also, &, | and ^ seem like some sort of precedent, to my brain (if they
don't to yours, that's fine and I believe you ;-).


>   * Python's not Perl.  We like using functions and not symbols.

I think this is a tasteful, if not parsimonious, use of a symbol.




John
___
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] The path module PEP

[Ian Bicking]

BJörn Lindqvist wrote:
> Remove __div__ (Ian, Jason, Michael, Oleg)
> 
> This is one of those where everyone (me too) says "I don't care either
> way." If that is so, then I see no reason to change it unless someone
> can show a scenario in which it hurts readability. Plus, a few people
> have said that they like the shortcut.
> 
> * http://mail.python.org/pipermail/python-list/2005-July/292251.html
> * http://mail.python.org/pipermail/python-dev/2005-June/054496.html
> * http://mail.python.org/pipermail/python-list/2005-July/291628.html
> * http://mail.python.org/pipermail/python-list/2005-July/291621.html

Curious how often I use os.path.join and division, I searched a project 
of mine, and in 12k lines there were 34 uses of join, and 1 use of 
division.  In smaller scripts os.path.join tends to show up a lot more 
(per line).  I'm sure there's people who use division far more than I, 
and os.path.join less, but I'm guessing the majority of users are more 
like me.

That's not necessarily a justification of / for paths, but at least this 
use for "/" wouldn't be obscure or mysterious after you get a little 
experience seeing code that uses it.


-- 
Ian Bicking  /  [EMAIL PROTECTED]  /  http://blog.ianbicking.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] The path module PEP

[Tony Meyer]

[Ian Bicking]
> If it were possible to use .join() for joining paths, I think I  
> wouldn't mind so much.  But reusing a string method for something  
> very different seems like a bad idea.  So we're left with .joinpath 
> ().  Still better than os.path.join() I guess, but only a little.   
> I guess that's why I'm +1 on /.

Why does reusing a string method for something very different seem  
like a bad idea, but reusing a mathematical operator for something  
very different seem like a good idea?  Path's aren't strings, so join 
() seems the logical choice.  (There are also alternatives to  
"joinpath" if the name is the thing: add(), for example).

[Tony Meyer]
>> Against it:
>>   * Zen: Beautiful is better than ugly. Explicit is better than   
>> implicit. Readability counts. There should be one-- and  
>> preferably  only one --obvious way to do it.
>
> I think / is pretty.  I think it reads well.

I suppose that the only beholder's eye that matters here is Guido's.   
(It still violates explicit/implicit and only-one-way.  Not rules, of  
course, but good guidelines).

>   There's already some inevitable redundancy in this interface.

That's hardly a reason to encourage *more*.  If anything, it's a  
reason to try for less, where possible.

>>   * Not every platform that Python supports has '/' as the path   
>> separator.  Windows, a pretty major one, has '\'.  I have no idea   
>> what various portable devices use, but there's a reasonable  
>> chance  it's not '/'.
>
> I believe all platforms support /; at least Windows and Mac do, in  
> addition to their native separators.

This is not strictly true.  Using '/' can lead to strange results  
with Windows, where it gets interpreted as a flag instead.  It's not  
reliable, it's not the path separator that Windows users/developers  
understand, and it's not the correct (i.e. according to Microsoft)  
path separator.  If by Mac you mean OS X, then that's just another  
*nix based OS.  I'm pretty sure that pre OS X (which isn't supported  
any more anyway, right?) '/' was not, in fact, supported, and that  
":" was required.  I also believe it's important to remember that  
Windows and *nix descendants are not "all platforms".

> If anything, a good shortcut for .joinpath() will at least  
> encourage people to use it, thus discouraging hardcoding of path  
> separators.  I expect it would encourage portable paths.

I'm not sure that I believe that the reason that people don't type  
"os.path.join('a', 'b')" is because they are too lazy to type it.   
However, I don't have any evidence either way, so it could be true.

[re: PEP8 following]
> Precedence in naming means something, and in this case all the  
> names have existed for a very long time (as long as Python?)  PEP 8  
> encourages following naming precedence.  While I don't see a need  
> to match every existing function with a method, to the degree they  
> do match I see no reason why we shouldn't keep the names.  And I  
> see reasons why the names shouldn't be changed.

PEP 8 encourages following naming precedence within a module, doesn't  
it?  Guido has said that he'd like to have the standard library  
tidied up, at least somewhat (e.g. StringIO.StringIO ->  
stringio.StringIO) for Python 3000.  It would make it less painful if  
new additions already followed the plan.

=Tony.Meyer
___
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] / as path join operator (was: Re: The path module PEP)

[Tony Meyer]

[John J Lee]
> But it's a very readable way to write a common operation.  Perhaps one
> reason the discrepancy you point out doesn't bother me is that  
> division is
> the least-used of the +-*/ arithmetic operations.

Do you have evidence to back that up?  It seems a strange claim.   
Outside of doing 'maths-y' work, I would think I'd use + most (but  
for strings), then / (for percentages).

> Also, &, | and ^ seem like some sort of precedent, to my brain (if  
> they
> don't to yours, that's fine and I believe you ;-).

I don't follow this, sorry.  You're referring to the bitwise operations?

[Ian Bicking]
> Curious how often I use os.path.join and division, I searched a  
> project
> of mine, and in 12k lines there were 34 uses of join, and 1 use of
> division.  In smaller scripts os.path.join tends to show up a lot more
> (per line).  I'm sure there's people who use division far more than I,
> and os.path.join less, but I'm guessing the majority of users are more
> like me.

The problem with these sorts of guesses is that there's no evidence.   
(Maybe the suggestion that Brett's PhD should collect a corpus of  
Python scripts was a good one ).  Are mathematicians that under  
represented?  Is file processing that highly represented?  I have no  
idea.

=Tony.Meyer
___
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] The path module PEP

[Bob Ippolito]

On Jan 25, 2006, at 3:42 PM, Tony Meyer wrote:

> [Ian Bicking]
>> If it were possible to use .join() for joining paths, I think I
>> wouldn't mind so much.  But reusing a string method for something
>> very different seems like a bad idea.  So we're left with .joinpath
>> ().  Still better than os.path.join() I guess, but only a little.
>> I guess that's why I'm +1 on /.
>
> Why does reusing a string method for something very different seem
> like a bad idea, but reusing a mathematical operator for something
> very different seem like a good idea?  Path's aren't strings, so join
> () seems the logical choice.  (There are also alternatives to
> "joinpath" if the name is the thing: add(), for example).

join() is already defined for strings, division is not.  Different  
namespace... just like + is concatenation for list+list, tuple+tuple,  
basestring+basestring, but it's addition for numbers...

>>>   * Not every platform that Python supports has '/' as the path
>>> separator.  Windows, a pretty major one, has '\'.  I have no idea
>>> what various portable devices use, but there's a reasonable
>>> chance  it's not '/'.
>>
>> I believe all platforms support /; at least Windows and Mac do, in
>> addition to their native separators.
>
> This is not strictly true.  Using '/' can lead to strange results
> with Windows, where it gets interpreted as a flag instead.  It's not
> reliable, it's not the path separator that Windows users/developers
> understand, and it's not the correct (i.e. according to Microsoft)
> path separator.  If by Mac you mean OS X, then that's just another
> *nix based OS.  I'm pretty sure that pre OS X (which isn't supported
> any more anyway, right?) '/' was not, in fact, supported, and that
> ":" was required.  I also believe it's important to remember that
> Windows and *nix descendants are not "all platforms".

Mac OS X understands '/' as the separator at the POSIX layer, but ':'  
as the path separator at the Carbon API (which is only used in  
obscure places from Python).  Earlier versions of Mac OS are no  
longer supported, and you're right -- they only understood ':' as a  
path separator.

>> If anything, a good shortcut for .joinpath() will at least
>> encourage people to use it, thus discouraging hardcoding of path
>> separators.  I expect it would encourage portable paths.
>
> I'm not sure that I believe that the reason that people don't type
> "os.path.join('a', 'b')" is because they are too lazy to type it.
> However, I don't have any evidence either way, so it could be true.

In many cases, when I know I only care about *nix, I will use 'a/b'  
instead of os.path.join because it's just so much more concise and  
more obvious.

The only times I use os.path.join are when I don't know if there will  
be a trailing slash or not, or if I'm actively trying to make  
something cross-platform.

-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] The path module PEP

[John J Lee]

On Thu, 26 Jan 2006, Tony Meyer wrote:
[...]
> Why does reusing a string method for something very different seem  
> like a bad idea, but reusing a mathematical operator for something  
> very different seem like a good idea?
[...]

That's easy -- it's because, if you're going to use a name, people expect
(with some level of trust) that you'll pick a good one.  But people
understand that there are only a few operators to use, so the meaning of
operators is naturally more overloaded than that of method names.


John
___
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] The path module PEP

[Ian Bicking]

Tony Meyer wrote:
> [Ian Bicking]
> 
>> If it were possible to use .join() for joining paths, I think I  
>> wouldn't mind so much.  But reusing a string method for something  
>> very different seems like a bad idea.  So we're left with .joinpath 
>> ().  Still better than os.path.join() I guess, but only a little.   I 
>> guess that's why I'm +1 on /.
> 
> 
> Why does reusing a string method for something very different seem  like 
> a bad idea, but reusing a mathematical operator for something  very 
> different seem like a good idea?  Path's aren't strings, so join () 
> seems the logical choice.  (There are also alternatives to  "joinpath" 
> if the name is the thing: add(), for example).

Paths are strings, that's in the PEP.

As an aside, I think it should be specified what (if any) string methods 
won't be inherited by Path (or will be specifically disabled by making 
them throw some exception).  I think .join() and __iter__ at least 
should be disabled.

>> Precedence in naming means something, and in this case all the  names 
>> have existed for a very long time (as long as Python?)  PEP 8  
>> encourages following naming precedence.  While I don't see a need  to 
>> match every existing function with a method, to the degree they  do 
>> match I see no reason why we shouldn't keep the names.  And I  see 
>> reasons why the names shouldn't be changed.
> 
> 
> PEP 8 encourages following naming precedence within a module, doesn't  
> it?  Guido has said that he'd like to have the standard library  tidied 
> up, at least somewhat (e.g. StringIO.StringIO ->  stringio.StringIO) for 
> Python 3000.  It would make it less painful if  new additions already 
> followed the plan.

I think the use of underscores or squished words isn't as bit a deal as 
the case of modules.  It's often rather ambiguous what a "word" really 
is.  At least in English word combinations slowly and ambiguously float 
towards being combined.  So abspath and abs_path both feel sufficiently 
inside the scope of PEP 8 that precedence is worth maintaining. 
rfc822's getallmatchingheaders method was going too far, but a little 
squishing doesn't bother me, if it is consistent (and it's actually 
easier to be consistent about squishing than underscores).

-- 
Ian Bicking  /  [EMAIL PROTECTED]  /  http://blog.ianbicking.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] The path module PEP

[Michael Hoffman]

[Charles Cazabon]

> It screams "magic" in a very un-Pythonic (and possibly very
> Perl-like) way.  I'm not aware of any other part of the standard
> library grossly abusing standard operators in this way.

I think the use of the modulo operator for string substitution is
pretty comparable, despite it being in the interpreter rather than in
the stdlib. And some of us have come to love that, too.
-- 
Michael Hoffman <[EMAIL PROTECTED]>
European Bioinformatics Institute

___
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] The path module PEP

[Gustavo J. A. M. Carneiro]

On Wed, 2006-01-25 at 21:37 +0100, BJörn Lindqvist wrote:

> Renaming methods because of PEP 8 (Gustavo, Ian, Jason)
> 
> I'm personally not keen on that. I like most of the names as they
> are. abspath(), joinpath(), realpath() and splitall() looks so much
> better than abs_path(), join_path(), real_path() and split_all() in my
> eyes. If someone like the underscores I'll add it to Open Issues.


 Function Names

  Function names should be lowercase, with words separated by underscores
  as necessary to improve readability.

  mixedCase is allowed only in contexts where that's already the
  prevailing style (e.g. threading.py), to retain backwards compatibility.

 Method Names and Instance Variables

  Use the function naming rules: lowercase with words separated by
  underscores as necessary to improve readability.


  It is very clear.  Whether you agree with PEP 8 or not is not relevant
to this discussion.  Since this is a completely new module, it should be
correctly named from the start.  The "familiarity with os.path argument"
is a very weak one, IMHO.

  Plus, the names are full of redundancy.  Why abspath(), joinpath(),
realpath(), splitall()?  Why not instead: absolute(), join(), real(),
split() ?  Remember that they are all methods of a Path class, you don't
need to keep repeating 'path' all over the place[1].

  On a slightly different subject, regarding path / path, I think it
feels much more natural path + path.  Path.join is really just a string
concatenation, except that it adds a path separator in the middle if
necessary, if I'm not mistaken.

  Best regards.

[1]  Yes, I'm the kind of guy who hates struct timeval having tv_sec and
tv_usec field members instead of sec and usec.

-- 
Gustavo J. A. M. Carneiro
<[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
The universe is always one step beyond logic

___
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] The path module PEP

[Thomas Wouters]

On Wed, Jan 25, 2006 at 09:37:04PM +0100, BJörn Lindqvist wrote:

> Inheritance from string (Jason)

> This issue has been brought up before when people were discussing the
> path module. I think the consensus is that, while the inheritance
> isn't pure, practicality beats purity. It would require to big changes
> to Python and would break to much existing code to not extend string.

This is my only problem with the PEP. It's all very nice that subclassing
from string makes it easier not to break things, but subclassing implies a
certain relationship. That relationship doesn't exist, in this case. Having
the string subclass behave differently than strings (consider the __iter__
and join methods) is a bad idea. I can dish up a half dozen contrived
problem cases, but the main reason I don't like it is that it feels wrong.

If the reason to subclass string is that it's too hard to make an object
'string-like' at a low enough level for the C API, I suggest fixing that,
instead. If that means Path has to wait until Python 2.6, then that's too
bad. The inability to feed C functions/types open() non-string objects has
troubled me before, and though I haven't invested a lot of time in it, I
don't quite understand why it isn't possible. Fixing it in a
backward-compatible manner may require a new __hook__, although I think
using __str__ or __unicode__ shouldn't be too problematic.

Even if fixing the "%es"/"%et" etc formats to the arg-parsing methods is
infeasible, I would prefer a new format code for 'string-alike as C string'
over the unpythonic inappropriate subclassing. Although, even if the
subclassing was completely appropriate, I would much rather improve builtin
support for ducktyping than showcase subclassing ;)

But perhaps I've missed that single, all-convincing argument that it has use
subclassing... In that case, could it be added to the PEP? :)

-- 
Thomas Wouters <[EMAIL PROTECTED]>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
___
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] / as path join operator (was: Re: The path module PEP)

[John J Lee]

[John J Lee]
> But it's a very readable way to write a common operation.  Perhaps one
> reason the discrepancy you point out doesn't bother me is that  
> division is the least-used of the +-*/ arithmetic operations.

[Tony Meyer]
> 
> Do you have evidence to back that up? 

No. :)


[Ian Bicking]
> of mine, and in 12k lines there were 34 uses of join, and 1 use of
> division.  In smaller scripts os.path.join tends to show up a lot more

[Tony]
> The problem with these sorts of guesses is that there's no evidence.   
> (Maybe the suggestion that Brett's PhD should collect a corpus of  
> Python scripts was a good one ).  Are mathematicians that under  
> represented?  Is file processing that highly represented?  I have no  
> idea.

A second data point: I looked at ~10k lines of physical data analysis code
I have lying around -- presumably a relatively rare and extreme example as
the Python-world in general goes.  Result:

  140 occurences of os.path.join

  170 physical lines (as opposed to syntactical lines) containing / as a
  division operator (very few lines contained > 1 use of '/', so you
  can multiply 170 by 1.25 to get an upper bound of 213 uses in total)

(To get the second number, I used find and grep heavily but very
cautiously, and final manual count of stubborn lines of grep output with
no use of '/' as division operator)

The fact that even in this extreme case os.path.join is close on the tail
of '/' strongly backs up Ian's guess that, in most Python code, / as
division is rare compared to path joining.

Should we deprecate use of '/' and '//' for division in Python 3.0?

is-he-joking?-ly y'rs


John
___
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] / as path join operator (was: Re: The path module PEP)

[Steven Bethard]

John J Lee wrote:
> On Thu, 26 Jan 2006, Tony Meyer wrote:
> [...]
> > Well, if you include the much larger discussion on python-list,
> > people (including me) have said that removing __div__ is a good
> > idea.  If it's included in the PEP, please at least include a
> > justification and cover the problems with it.  The vast majority of
> > people (at least at the time) were either +0 or -0, not +1.  +0's are
> > not justification for including something.
>
> 
>
> FWLIW, I'm definitely +1 on using / as a path join operator.

My only fear with the / operator is that we'll end up with the same
problems we have for using % in string formatting -- the order of
operations might not be what users expect.  Since join is conceptually
an addition-like operator, I would expect:

Path('home') / 'a' * 5

to give me:

home/a

If I understand it right, it would actually give me something like:

home/ahome/ahome/ahome/ahome/a

I don't want to claim this is the most common use case, but I've
certainly seen auto-generated paths that look like 'a' * 20, and it
would be a pity if using the / operator for Path objects did the wrong
thing by default here...

STeVe
--
You can wordify anything if you just verb it.
--- Bucky Katt, Get Fuzzy
___
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] The path module PEP

[Tony Meyer]

[Ian Bicking]
> Paths are strings, that's in the PEP.

No, the PEP says that Path is a *subclass* of string ("Path extends  
from string").  In addition, it's a disputed part of the PEP (see  
elsewhere in this thread).

=Tony.Meyer
___
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] / as path join operator

[Nick Coghlan]

Steven Bethard wrote:
> John J Lee wrote:
>> On Thu, 26 Jan 2006, Tony Meyer wrote:
>> [...]
>>> Well, if you include the much larger discussion on python-list,
>>> people (including me) have said that removing __div__ is a good
>>> idea.  If it's included in the PEP, please at least include a
>>> justification and cover the problems with it.  The vast majority of
>>> people (at least at the time) were either +0 or -0, not +1.  +0's are
>>> not justification for including something.
>> 
>>
>> FWLIW, I'm definitely +1 on using / as a path join operator.
> 
> My only fear with the / operator is that we'll end up with the same
> problems we have for using % in string formatting -- the order of
> operations might not be what users expect.  Since join is conceptually
> an addition-like operator, I would expect:
> 
> Path('home') / 'a' * 5
> 
> to give me:
> 
> home/a
> 
> If I understand it right, it would actually give me something like:
> 
> home/ahome/ahome/ahome/ahome/a
> 
> I don't want to claim this is the most common use case, but I've
> certainly seen auto-generated paths that look like 'a' * 20, and it
> would be a pity if using the / operator for Path objects did the wrong
> thing by default here...

What if we used "subpath" as the name instead of joinpath?

The main appeal to me of the division operation is that it allows multiple 
path elements to be joined on a single line, but the joining method accepts an 
arbitrary number of arguments, which helps with that just as much, and doesn't 
raise precedence and readability questions.

The above example would be:

   Path('home').subpath('a'*5)

An example of retrieving a config file's full name:

Current:   os.path.join(HOME_DIR, APP_DIR, CONFIG_FILE)
Division:  HOME_DIR / APP_DIR / CONFIG_FILE
Subpath:   HOME_DIR.subpath(APP_DIR, CONFIG_FILE)

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] [Python-checkins] r42185 - python/trunk/Lib/test/test_socket_ssl.py

[Tim Peters]

[neal.norwitz]
> Modified:
>python/trunk/Lib/test/test_socket_ssl.py
> Log:
> There was a race condition where the connector would try to connect
> before the listener was ready (on gentoo x86 buildslave).  This
> caused the listener to not exit normally since nobody connected to it
> (waited in accept()).  The exception was raised in the other thread
> and the test failed.

Good catch!  Thank you.

> This fix doesn't completely eliminate the race, but should make it
> near impossible to trigger.  Hopefully it's good enough.

Which race do you have in mind?  The server socket doesn't need to do
.accept() before a client socket can connect -- the server socket only
needs to have done .listen() for a connection to succeed.

> +listener_ready = threading.Event()

...

[in the server]
>  s = socket.socket()
>  s.bind(('', PORT))
>  s.listen(5)
> +listener_ready.set()
>  s.accept()

...

[in the client]
>  def connector():
> +listener_ready.wait()
>  s = socket.socket()
>  s.connect(('localhost', PORT))

Because the server doesn't set listener_ready until after the server
has done listen(),  and the client waits for that event, it "should
be" 100% reliable that the client's connect() succeeds.

Or do you have some other race in mind?
___
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-checkins] r42185 - python/trunk/Lib/test/test_socket_ssl.py

[Neal Norwitz]

On 1/25/06, Tim Peters <[EMAIL PROTECTED]> wrote:
>
> Because the server doesn't set listener_ready until after the server
> has done listen(),  and the client waits for that event, it "should
> be" 100% reliable that the client's connect() succeeds.
>
> Or do you have some other race in mind?

That's what I was thinking of.  I thought you had to be accept()ing
prior to connect() working.  I thought listen() only sets the # of
outstanding connections allowed (basically internal buffer).  But if
the listen() is sufficient, I agree there is no race.

n
___
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-checkins] r42185 - python/trunk/Lib/test/test_socket_ssl.py

[Tim Peters]

[Neal Norwitz]
> That's what I was thinking of.  I thought you had to be accept()ing
> prior to connect() working.  I thought listen() only sets the # of
> outstanding connections allowed (basically internal buffer).  But if
> the listen() is sufficient, I agree there is no race.

listen() "should be" sufficient -- it allocates space for a connection
queue, and marks the socket as accepting connections.  accept() merely
does a blocking "pop" on the queue listen() created.

For fun ;-), run it in slow motion, by hand, on that box:  open Python
in one window, and create a server socket without doing accept().  In
another window, try to connect to the first socket's address.  The
connect should succeed at once.

Now socket docs are typically clear as mud, and it's possible that box
has a bad implementation.  "Thought experiments" can help:  if an
accept() were necessary before a connection could succeed, why would
listen() have a backlog argument at all?  Well, if everything else
were sane, it wouldn't ;-)
___
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] / as path join operator

[Trent Mick]

[Nick Coghlan wrote]
> What if we used "subpath" as the name instead of joinpath?

"append"?

not-a-big-fan-of-joinpath-either-ly yours,
Trent

-- 
Trent Mick
[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] yield back-and-forth?

[Morel Xavier]

Christian Tanzer wrote:
> How about:
> 
>   def main_generator():
>   ...
>   yield * sub_generator()
> 
> Ducking-ly yrs,
> 

I like that one, but I'd stick the star to the generator (e.g. yield 
*sub_generator), the meaning being to "unpack" the generator into the 
yield, same as unpacking a sequence passed as function parameters.

As an extension, the syntax may even (though I'm not sure it'd be a good 
idea to do so) work with any iterable, behaving the same way (yielding 
the successive values of the iterable object)
___
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] pystate.c changes for Python 2.4.2

[Gabriel Becedillas]

Thanks to everyone for the great support.
I've submitted a patch for this: 
http://sourceforge.net/tracker/index.php?func=detail&aid=1413181&group_id=5470&atid=305470.

___
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] / as path join operator

[Ian Bicking]

Steven Bethard wrote:
> My only fear with the / operator is that we'll end up with the same
> problems we have for using % in string formatting -- the order of
> operations might not be what users expect.  Since join is conceptually
> an addition-like operator, I would expect:
> 
> Path('home') / 'a' * 5
> 
> to give me:
> 
> home/a
> 
> If I understand it right, it would actually give me something like:
> 
> home/ahome/ahome/ahome/ahome/a

Both of these examples are rather silly, of course ;)  There's two 
operators currently used commonly with strings (that I assume Path would 
inherit): + and %.  Both actually make sense with paths too.

   filename_template = '%(USER)s.conf'
   p = Path('/conf') / filename_template % os.environ
which means:
   p = (Path('/conf') / filename_template) % os.environ

But probably the opposite is intended.  Still, it will usually be 
harmless.  Which is sometimes worse than usually harmful.

+ seems completely innocuous, though:

   ext = '.jpg'
   name = fields['name']
   image = Path('/images') / name + ext

It doesn't really matter what order it happens in there.  Assuming 
concatenation results in a new Path object, not a str.

-- 
Ian Bicking  |  [EMAIL PROTECTED]  |  http://blog.ianbicking.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] / as path join operator (was: Re: The path module PEP)

[Barry Warsaw]

On Thu, 2006-01-26 at 12:51 +1300, Tony Meyer wrote:
> [John J Lee]
> > But it's a very readable way to write a common operation.  Perhaps one
> > reason the discrepancy you point out doesn't bother me is that  
> > division is
> > the least-used of the +-*/ arithmetic operations.
> 
> Do you have evidence to back that up?  It seems a strange claim.   
> Outside of doing 'maths-y' work, I would think I'd use + most (but  
> for strings), then / (for percentages).

I haven't followed the entire thread (I'll try to find time to catch up)
but while I think using __div__ to mean path concatenation is cute, I'm
not sure I'd like to see it all over the place.  It does seem awfully
"FAST" ("facinating and stomach turning" to use a term from years ago).

What I don't like about os.path.join() having to import os and having to
type all those characters over and over again.  What I /like/ about
os.path.join is that you can give it a bunch of path components and have
it return the correctly joined path, e.g. os.path.join('a, 'b', 'c').
That seems more efficient than having to create a bunch of intermediate
objects.

All in all, I'd have to say I'm -0 on __div__ for path concatenation.

-Barry




signature.asc
Description: This is a digitally signed message part
___
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] The path module PEP

[Tony Meyer]

[Gustavo J. A. M. Carneiro]
> Plus, the names are full of redundancy.  Why abspath(), joinpath(),
> realpath(), splitall()?  Why not instead: absolute(), join(), real(),
> split() ?  Remember that they are all methods of a Path class, you  
> don't
> need to keep repeating 'path' all over the place.

+1 for all of those that aren't also string methods.

+0.9 for those that are string methods, although I suppose this  
depends on how much like a string a Path ends up like.

Other than join() (covered in the __div__ discussion), split() is an  
interesting case, since the default split-on-whitespace (str.split)  
doesn't make a whole lot of sense with a Path, but split-on-pathsep  
(os.path.split) does.  Does it make sense to be able to split a path  
on something else (like str.split), or should people just convert to/ 
from a string?  Should there be a maxsplit argument?

=Tony.Meyer
___
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] The path module PEP

[Barry Warsaw]

On Wed, 2006-01-25 at 18:10 -0600, Ian Bicking wrote:

> Paths are strings, that's in the PEP.
> 
> As an aside, I think it should be specified what (if any) string methods 
> won't be inherited by Path (or will be specifically disabled by making 
> them throw some exception).  I think .join() and __iter__ at least 
> should be disabled.

Whenever I see derived classes deliberately disabling base class
methods, I see red flags that something in the design of the hierarchy
isn't right.  While I understand that you want to be able to use Path
instances anywhere a string is currently used, I'm not sure that
deriving from str is the right thing.  Maybe deriving from basestring
would be better, but even then I'm not sure.  Is it possible that we
don't need Path objects to interchangeable with strings, but just that
we can get away with expanding a few critical functions (such as
open())?

> I think the use of underscores or squished words isn't as bit a deal as 
> the case of modules.  It's often rather ambiguous what a "word" really 
> is.  At least in English word combinations slowly and ambiguously float 
> towards being combined.  So abspath and abs_path both feel sufficiently 
> inside the scope of PEP 8 that precedence is worth maintaining. 
> rfc822's getallmatchingheaders method was going too far, but a little 
> squishing doesn't bother me, if it is consistent (and it's actually 
> easier to be consistent about squishing than underscores).

For something like "abspath" which is really an abbreviation + word, I
suppose squishing them isn't so bad.  The alternative is absolute_path()
which is certainly more readable if a bit of a pain to write.  It's a
trade-off that should be made for practical purposes.  I've definitely
come to prefer spellings like is_absolute over isabsolute, and in
general dislike squish words.

-Barry



signature.asc
Description: This is a digitally signed message part
___
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] / as path join operator

[Stephen J. Turnbull]

> "Steven" == Steven Bethard <[EMAIL PROTECTED]> writes:

Steven> My only fear with the / operator is that we'll end up with
Steven> the same problems we have for using % in string formatting
Steven> -- the order of operations might not be what users expect.

Besides STeVe's example, (1) I think it's logical to expect that

Path('home') / 'and/or'

points to a file named "and/or" in directory "home", not to a file
named "or" in directory "home/and".

(2) Note that '/' is also the path separator used by URIs, which RFC
2396 gives different semantics from Unix.  Most of my Python usage to
date has been heavily web-oriented, and I'd have little use for /
unless it follows RFC 2396.  By that, I mean that I would want the /
operator to treat its rhs as a relative reference, so the result would
be computed by the algorithm in section 5.2 of that RFC.  But this is
not correct (realpath) semantics on Unix.

-- 
School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp
University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN
   Ask not how you can "do" free software business;
  ask what your business can "do for" free software.
___
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] / as path join operator

[Barry Warsaw]

On Thu, 2006-01-26 at 11:40 +1000, Nick Coghlan wrote:

> The main appeal to me of the division operation is that it allows multiple 
> path elements to be joined on a single line, but the joining method accepts 
> an 
> arbitrary number of arguments, which helps with that just as much, and 
> doesn't 
> raise precedence and readability questions.

Or the need to employ ugliness like backslashes when you have to split
the join across multiple lines.

-Barry



signature.asc
Description: This is a digitally signed message part
___
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] The path module PEP

[Ian Bicking]

Barry Warsaw wrote:
> On Wed, 2006-01-25 at 18:10 -0600, Ian Bicking wrote:
> 
> 
>>Paths are strings, that's in the PEP.
>>
>>As an aside, I think it should be specified what (if any) string methods 
>>won't be inherited by Path (or will be specifically disabled by making 
>>them throw some exception).  I think .join() and __iter__ at least 
>>should be disabled.
> 
> 
> Whenever I see derived classes deliberately disabling base class
> methods, I see red flags that something in the design of the hierarchy
> isn't right.

IMHO the hierarchy problem is a misdesign of strings; iterating over 
strings is usually a bug, not a deliberately used feature.  And it's a 
particularly annoying bug, leading to weird results.

In this case a Path is not a container for characters.  Strings aren't 
containers for characters either -- apparently they are containers for 
smaller strings, which in turn contain themselves.  Paths might be seen 
as a container for other subpaths, but I think everyone agrees this is 
too ambigous and implicit.  So there's nothing sensible that __iter__ 
can do, and having it do something not sensible (just to fill it in with 
something) does not seem very Pythonic.

join is also a funny method that most people wouldn't expect on strings 
anyway.  But putting that aside, the real issue I see is that it is a 
miscognate for os.path.join, to which it has no relation.  And I can't 
possibly imagine what you'd use it for in the context of a path.


-- 
Ian Bicking  |  [EMAIL PROTECTED]  |  http://blog.ianbicking.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] The path module PEP

[Ian Bicking]

Gustavo J. A. M. Carneiro wrote:
>   On a slightly different subject, regarding path / path, I think it
> feels much more natural path + path.  Path.join is really just a string
> concatenation, except that it adds a path separator in the middle if
> necessary, if I'm not mistaken.

No, it isn't, which maybe is why / is bad.  os.path.join(a, b) basically 
returns the path as though b is interpreted to be relative to a.  I.e., 
os.path.join('/foo', '/bar') == '/bar'.  Not much like concatenation at 
all.  Plus string concatenation is quite useful with paths, e.g., to add 
an extension.

If a URI class implemented the same methods, it would be something of a 
question whether uri.joinpath('/foo/bar', 'baz') would return '/foo/baz' 
(and urlparse.urljoin would) or '/foo/bar/baz' (as os.path.join does). 
I assume it would be be the latter, and urljoin would be a different 
method, maybe something novel like "urljoin".


-- 
Ian Bicking  |  [EMAIL PROTECTED]  |  http://blog.ianbicking.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] / as path join operator

[Barry Warsaw]

On Wed, 2006-01-25 at 21:02 -0600, Ian Bicking wrote:

>ext = '.jpg'
>name = fields['name']
>image = Path('/images') / name + ext

Here's a good example of why I ultimately don't like __div__.  The last
line seems quite non-obvious to me.  It's actually jarring enough that I
have to stop and think about what it means because it /looks/ like
there's math going on.

OTOH, something like:

image = Path('', 'images', name) + ext

or even better

image = Path.join('', 'images', name) + ext

where .join is a staticmethod, seems much clearer.

-Barry



signature.asc
Description: This is a digitally signed message part
___
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] The path module PEP

[Barry Warsaw]

On Wed, 2006-01-25 at 22:30 -0600, Ian Bicking wrote:

> IMHO the hierarchy problem is a misdesign of strings; iterating over 
> strings is usually a bug, not a deliberately used feature.  And it's a 
> particularly annoying bug, leading to weird results.

Agreed.  I've written iteration code that has to special case
basestrings before and that's particularly ugly.

> In this case a Path is not a container for characters.  Strings aren't 
> containers for characters either -- apparently they are containers for 
> smaller strings, which in turn contain themselves.  Paths might be seen 
> as a container for other subpaths, but I think everyone agrees this is 
> too ambigous and implicit.  So there's nothing sensible that __iter__ 
> can do, and having it do something not sensible (just to fill it in with 
> something) does not seem very Pythonic.
> 
> join is also a funny method that most people wouldn't expect on strings 
> anyway.  But putting that aside, the real issue I see is that it is a 
> miscognate for os.path.join, to which it has no relation.  And I can't 
> possibly imagine what you'd use it for in the context of a path.

Good points, but to me that argues against having any inheritance
relationship between strings and Paths rather than having such a
relationship and disabling certain methods.  Thomas's post seemed more
on-target for me and I'd like to see that idea fleshed out in more
detail.  If it's proved to be an impossible (or merely an extremely
infeasible) task, then I think we can discuss the shortcut of deriving
from strings.  It just seems gross so I'd like to be sure there's no
better way.

-Barry



signature.asc
Description: This is a digitally signed message part
___
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-checkins] r42185 - python/trunk/Lib/test/test_socket_ssl.py

[Martin v. Löwis]

Neal Norwitz wrote:
> That's what I was thinking of.  I thought you had to be accept()ing
> prior to connect() working.  I thought listen() only sets the # of
> outstanding connections allowed (basically internal buffer).  But if
> the listen() is sufficient, I agree there is no race.

Actually, that's the whole point of listen(). Even if you initially do
accept() quickly, it might be that another connection request (SYN)
arrives between return of accept() and the next call to accept();
this is essentially the same as connection requests arriving before
the first accept() call.

The kernel will acknowledge the SYN packet immediately, and do that for
at most "number-of-backlog" incoming connections. Then, subsequent
accept() calls will immediately return.

Regards,
Martin
___
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] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15

[Tony Meyer]

Here's the draft for the first January summary.  If anyone has time to
send me/Steve comments/suggestions/corrections/additions, those will
be most welcome.  The Py_ssize_t threads were particularly over my
head.  As always, many thanks :)

=
Announcements
=


QOTF: Quote of the Fortnight


Guido, on the crashability of Python:

I'm not saying it's uncrashable. I'm saying that if you crash it,
it's a bug unless proven harebrained.

Contributing thread:

- `Include ctypes into core Python?
`_

[SJB]


Brett Cannon looking for Ph.D. ideas


Brett Cannon is looking for Python-related ideas to form the subject
of his PhD dissertation, under Eric Wohlstadter at the University of
British Columbia.  He has three areas in which he has possible funding
(XML integration, game scripting support, and AOP); he is open to
grants from anyone else interested in particular Python development. 
If anyone has suggestions for topics, Brett is listening!

So far:

* Phillip J. Eby mentioned that he has been doing some research on
implementing a non-traditional form of AOP in Python.
* Bill Janssen suggested a system to compile Python to AJAX.
* Steve Holden suggested a Python learning system.
* Ian Bicking suggested Boxer_ implemented for Python.
* Armin Rigo suggested PyPy related work.
* Jason Orendorff suggested collecting a downloadable corpus of Python
source code, and performing various analyses on it.
* Dennis Allison suggested interpreter structures for Python-like
languages that do not use a global interpreter lock, as well as
various other topics.

 .. _Boxer: http://dewey.soe.berkeley.edu/boxer.html

Contributing thread:

 - `Ph.D. dissertation ideas?
`__

[TAM]

-
2.4 Documentation with Commentary
-

Ian Bicking put an instance_ of his commenting system, Commentary_, up
against the full 2.4 documentation. If you'd like to see how the
Python docs look with user-added comments, now's your chance!

.. _instance: http://pythonpaste.org/comment/python24/
.. _Commentary: http://pythonpaste.org/commentary/

Contributing thread:

 - `[Doc-SIG] that library reference, again
`__

[SJB]

---
Builds of the Development Documentation
---

Be sure to keep yourself up to date with the newest Python
documentation - Neal Norwitz has arranged it so that the current
Python development documentation is now automatically generated every
12 hours and placed at http://docs.python.org/dev/.

Contributing thread:

 - `automated builds and tests
`__

[SJB]


PEPs now automatically installed


Martin v. Löwis has arranged for an automatic installation of PEPs_:
they will now get published in the subversion post-commit.

Contributing thread:

 - `Installing PEPs
`__

 .. _PEPs: http://www.python.org/peps

[TAM]

=
Summaries
=

---
Using buildbot to automate testing of Python builds
---

A buildbot_ has been setup to facilitate `automated testing of the
Python SVN`_.  There are currently five slaves setup:

* Linux x86 (gentoo 2.6, glibc 2.3)
* Linux AMD64 (gentoo 2.6, glibc 2.3)
* Solaris10 sparc
* OS X 10.3 G5
* OS X 10.4 G4

Ideally, all supported platforms will be added (including OS, version,
hardware, and various configurations); the slaves are testing the
trunk and the 2.4 branch.  Note that Window buildbot slaves have to
have an appropriate compiler (MS VC 7.1), otherwise it can't compile
the code; the Windows Python would also like to build several other
packages (like bz2 and Tcl/Tk).  A periodic "clean build" may also be
added; there was discussion whether this should be done via a patch to
the buildbot master, via an IRC command, or with a separate scheduler.

Martin v. Löwis would rather buildbot produced static pages than act
as a web server (for security reasons).  Brian Warner explained that
it once did, but was changed to make it easier to implement features
like the "Force Build" button.  An explanation of the security was
given, and it seems satisfactory at the moment.

The buildbot testing has already produced results: a compiler warning
on OS X 10.3 was noticed.  A discussion took place as to whether this
should be fixed (it should) and who could do it (Ronald Oussoren
volunteered, with help from Skip Montanaro).

Fredrik