[Python-Dev] DRAFT: python-dev Summary for 2006-01-01 through 2006-01-15

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

Re: [Python-Dev] [Python-checkins] r42185 - python/trunk/Lib/test/test_socket_ssl.py

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, th

Re: [Python-Dev] The path module PEP

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

Re: [Python-Dev] / as path join operator

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 sto

Re: [Python-Dev] The path module PEP

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, w

Re: [Python-Dev] The path module PEP

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 except

Re: [Python-Dev] / as path join operator

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

Re: [Python-Dev] / as path join operator

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

Re: [Python-Dev] The path module PEP

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

Re: [Python-Dev] The path module PEP

[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

Re: [Python-Dev] / as path join operator (was: Re: The path module PEP)

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

Re: [Python-Dev] / as path join operator

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

Re: [Python-Dev] pystate.c changes for Python 2.4.2

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/listi

Re: [Python-Dev] yield back-and-forth?

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 unpackin

Re: [Python-Dev] / as path join operator

[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/mailm

Re: [Python-Dev] [Python-checkins] r42185 - python/trunk/Lib/test/test_socket_ssl.py

[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

Re: [Python-Dev] [Python-checkins] r42185 - python/trunk/Lib/test/test_socket_ssl.py

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

Re: [Python-Dev] [Python-checkins] r42185 - python/trunk/Lib/test/test_socket_ssl.py

[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 i

Re: [Python-Dev] / as path join operator

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

Re: [Python-Dev] The path module PEP

[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

Re: [Python-Dev] / as path join operator (was: Re: The path module PEP)

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 th

Re: [Python-Dev] / as path join operator (was: Re: The path module PEP)

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

Re: [Python-Dev] The path module PEP

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

Re: [Python-Dev] The path module PEP

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(), re

Re: [Python-Dev] The path module PEP

[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

Re: [Python-Dev] The path module PEP

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,

Re: [Python-Dev] The path module PEP

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, peopl

Re: [Python-Dev] The path module PEP

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

Re: [Python-Dev] / as path join operator (was: Re: The path module PEP)

[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

Re: [Python-Dev] The path module PEP

[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 g

Re: [Python-Dev] The path module PEP

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

[Python-Dev] / as path join operator (was: Re: The path module PEP)

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

Re: [Python-Dev] The path module PEP

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 abus

Re: [Python-Dev] The path module PEP

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

Re: [Python-Dev] The path module PEP

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 >

Re: [Python-Dev] The path module PEP

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

Re: [Python-Dev] The path module PEP

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 __

Re: [Python-Dev] The path module PEP

[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().r

Re: [Python-Dev] The path module PEP

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

Re: [Python-Dev] The path module PEP

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

Re: [Python-Dev] The path module PEP

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]

Re: [Python-Dev] The path module PEP

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 be

Re: [Python-Dev] The path module PEP

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

Re: [Python-Dev] The path module PEP

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

Re: [Python-Dev] The path module PEP

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 the

Re: [Python-Dev] Know anyone interested in a Google internship?

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

Re: [Python-Dev] The path module PEP

[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 poi

Re: [Python-Dev] The path module PEP

[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 add

Re: [Python-Dev] stabilizing builds

"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 e