Re: [Python-Dev] building a module catalogue with buildbot

2006-01-24 Thread Fredrik Lundh
Neal Norwitz wrote:

> > > > Does that make sense?  We would just need /f's script in SVN.
> > >
> > > in python/Tools/something or sandbox/something ?
> >
> > python/Doc/tools/something?
>
> Fredrik were you still working on that?  I can make the changes to the
> bb master.  I thought Trent's suggested placement was good.

iirc, the script needed some minor tweaking (using os.path.splitext to
test for the module.so extension isn't a good idea), and I don't recall
if I've fixed that or not...

(probably not, since I never checked it in).

I'll take a look asap.





___
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] New Pythondoc by effbot

2006-01-24 Thread Fredrik Lundh
Brett Cannon wrote:

> And to /F, kudos from me.  I have been randomly thinking about it and
> I understand your desire for semantic markup now.

thanks.

> Hopefully something can get hammered out so that at least the Python
> 3 docs can premiere having been developed on by the whole community.

why wait for Python 3 ?

what's the current release plan for Python 2.5, btw?  I cannot find a
relevant PEP, and the "what's new" says "late 2005":

http://www.python.org/dev/doc/devel/whatsnew/contents.html





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

2006-01-24 Thread Thomas Wouters
On Sun, Jan 22, 2006 at 11:01:36PM -0800, Neal Norwitz wrote:

> * test_pty is brittle on solaris 10, sometimes it works, sometimes not

FWIW, it's brittle on Solaris 9, too, and the SF compilefarm has two of
those. I don't know if it's the same problem, but on Solaris 9, the slave
part of the tty/pty pair sometimes isn't a TTY (according to os.isatty.) The
buildbot's log doesn't list the solaris 10 test_pty failure though, just the
test_logging failure.

It looks like a timing issue; the first run succeeds, all subsequent runs
fail, for a while, anyway. I'll do some googling and browsing other
tty/pty-using code to see if there's anything we're not doing we should be
doing, but it looks like a platform bug that we can't fix... Not without
re-implementing os.isatty anyway ;P

-- 
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] New Pythondoc by effbot

2006-01-24 Thread Donovan Baarda
On Sat, 2006-01-21 at 19:15 -0500, Terry Reedy wrote:
> >> http://effbot.org/lib/os.path.join
> 
> On this page, 8 of 30 entries have a 'new in' comment.  For anyone with no 
> interest in the past, these constitute noise.  I wonder if for 3.0, the 

Even the past is relative... I find the "new in" doco absolutely
essential, because my "present" depends on what system I'm on, and some
of them are stuck in a serious time-warp. I do not have a time-machine
big enough to transport whole companies.

> timer can be reset and the docs start clean again.  To keep them backwards 
> compatible, they would also have to be littered with 'changed in 3.0' and 
> 'deleted in 3.0' entries.  Better, I think, to refer people to the last 2.x 
> docs and a separate 2.x/3.0 changes doc.

I also find "changed in" essential, but I don't mind not having "deleted
in"... it encourages developers stuck in those time-warps to avoid
features that get deleted in the future :-)

-- 
Donovan Baarda <[EMAIL PROTECTED]>
http://minkirri.apana.org.au/~abo/

___
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] building a module catalogue with buildbot

2006-01-24 Thread Fredrik Lundh
I wrote:

> Neal Norwitz wrote:
>
> > > > > Does that make sense?  We would just need /f's script in SVN.
> > > >
> > > > in python/Tools/something or sandbox/something ?
> > >
> > > python/Doc/tools/something?
> >
> > Fredrik were you still working on that?  I can make the changes to the
> > bb master.  I thought Trent's suggested placement was good.
>
> iirc, the script needed some minor tweaking (using os.path.splitext to
> test for the module.so extension isn't a good idea), and I don't recall
> if I've fixed that or not...
>
> (probably not, since I never checked it in).
>
> I'll take a look asap.

alright, I just checked in a

Doc/tools/listmodules.py

which attempts to produce a sorted list of all modules available in
a given python build.  by default, it prints the list to stdout, which
should be good enough for a "catalog" buildbot step.





___
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] When will regex really go away?

2006-01-24 Thread skip

I ran Fredrik's listmodules script in my current sandbox and got a
deprecation warning for the regex module.  According to PEP 4 it is already
obsolete.  I saw nothing there about the timeframe for actual removal.  Will
it ever go away?

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] When will regex really go away?

2006-01-24 Thread Guido van Rossum
On 1/24/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> I ran Fredrik's listmodules script in my current sandbox and got a
> deprecation warning for the regex module.  According to PEP 4 it is already
> obsolete.  I saw nothing there about the timeframe for actual removal.  Will
> it ever go away?

ASAP please!

PEP 4 lists these that were already obsolete in 2.0:

addpack, cmp, cmpcache, codehack, dircmp, dump, fmt, lockfile,
newdir, Para, poly, regex, regsub, tb, timing, util, whatsound,
tzmod, find, grep, packmail, ni, rand, soundex, cl, sv

of these, regex, regsub, and timing are still importable in 2.4 (I
don't have a 2.5 handy here at Google, and my home machine seems
inaccessible). ISTM these last three can safely be dropped now.

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


Re: [Python-Dev] [PATCH] Fix dictionary subclass semantics whenused as global dictionaries

2006-01-24 Thread Crutcher Dunnavant
Okay, but is there any reason not to include this in 2.5? There
doesn't seem to be any noticeable performance impact, and it does add
consistancy (and opens some really, really cool options up).

Does anyone have objections to 1402289?

On 1/12/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Crutcher Dunnavant wrote:
> > I sorta disagree about it not being broken. Adding a feature which
> > works for eval but not for exec seems pretty broken.
>
> You "seem" to have a different notion of "to be broken", then.
>
> Python is broken, if and only if
> - the interpreter crashes, for any Python input
> - the implementation does not do what the documentation says
>   it would do
> - the BDFL pronounces it is broken
>
> In this specific change, the change did precisely what the requestor
> of the feature wanted it to do (that eval could accept non-exact
> dicts was a new feature back then also)
>
> > It's difficult to
> > reason about what will happen in the exec context, so I can't see what
> > fixing it would endanger; but I'd deffinately like to see it for 2.5.
>
> It would make Python code run which is currently rejected with an
> exception. Therefore, it is a new feature (a behaviour change).
>
> Applications relying on that feature would have to specify that
> they require "2.4.3"; people would find that code that runs fine
> in 2.4.3 fails in 2.4.2. This is not acceptable.
>
> Regards,
> Martin
>


--
Crutcher Dunnavant <[EMAIL PROTECTED]>
monket.samedi-studios.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] When will regex really go away?

2006-01-24 Thread skip

Guido> PEP 4 lists these that were already obsolete in 2.0:

Guido> addpack, cmp, cmpcache, codehack, dircmp, dump, fmt,
Guido> lockfile, newdir, Para, poly, regex, regsub, tb, timing,
Guido> util, whatsound, tzmod, find, grep, packmail, ni, rand,
Guido> soundex, cl, sv

Guido> of these, regex, regsub, and timing are still importable in 2.4.

And in 2.5.  Regex and regsub both import with deprecation warnings.  Timing
imports without a peep.  None of the others import.

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


[Python-Dev] The path module PEP

2006-01-24 Thread BJörn Lindqvist
The last time this was discussed six months ago it seemed like most of
python-dev fancied Jason Orendorff's path module. But Guido wanted a
PEP and noone created one. So I decided to claim the fame and write
one since I also love the path module. :) Much of it is copy-pasted
from Peter Astrand's PEP 324, many thanks to him.


#
PEP: XXX
Title: path - Object oriented handling of filesystem paths
Version: $Revision:  $
Last-Modified: $Date: 2006-01-24 19:24:59 +0100 (Sat, 29 Jan 2005) $
Author: Björn Lindqvist <[EMAIL PROTECTED]>
Status: Dummo
Type: Standards Track (library)
Created: 24-Jan-2006
Content-Type: text/plain
Python-Version: 2.4


Abstract

This PEP describes a new class for handling paths in an object
oriented fashion.


Motivation

Dealing with filesystem paths is a common task in any programming
language, and very common in a high-level language like
Python. Good support for this task is needed, because:

- Almost every program uses paths to access files. It makes sense
  that a task, that is so often performed, should be as intuitive
  and as easy to perform as possible.

- It makes Python an even better replacement language for
  over-complicated shell scripts.

Currently, Python has a large number of different functions
scattered over half a dozen modules for handling paths. This makes
it hard for newbies and experienced developers to to choose the
right method.

The Path class provides the following enhancements over the
current common practice:

- One "unified" object provides all functionality from previous
  functions.

- Subclassability - the Path object can be extended to support
  paths other than filesystem paths. The programmer does not need
  to learn a new API, but can reuse his or her knowledge of Path
  to deal with the extended class.

- With all related functionality in one place, the right approach
  is easier to learn as one does not have to hunt through many
  different modules for the right functions.

- Python is an object oriented language. Just like files,
  datetimes and sockets are objects so are paths, they are not
  merely strings to be passed to functions. Path objects are
  inherently a pythonic idea.

- Path takes advantage of properties. Properties make for more
  readable code.

  if imgpath.ext == 'jpg':
  jpegdecode(imgpath)

  Is better than:

  if os.path.splitexit(imgpath)[1] == 'jpg':
  jpegdecode(imgpath)


Rationale

The following points summarizes the design:

- Path extends from string, therefore all code which expects
  string pathnames need not be modified and no existing code will
  break.

- A Path object can be created either by using the classmethod
  Path.cwd, by instantiating the class with a string representing
  a path or by using the default constructor which is equivalent
  with Path(".").

- The factory functions in popen2 have been removed, because I
  consider the class constructor equally easy to work with.

- Path provides for common pathname manipulation, pattern
  expansion, pattern matching and other high-level file operations
  including copying. Basically everything path related except for
  manipulation of file contents which file objects are better
  suited for.

- Platform incompatibilites are dealt with by not instantiating
  system specific methods.


Specification

This class defines the following public methods:

# Special Python methods.
def __new__(cls, init = os.curdir): ...
def __repr__(self): ...
def __add__(self, more): ...
def __radd__(self, other): ...
def __div__(self, rel): ...
def __truediv__(self, rel): ...

# Alternative constructor.
def cwd(cls): ...

# Operations on path strings.
def abspath(sef): ...
def normcase(self): ...
def normpath(self): ...
def realpath(self): ...
def expanduser(self): ...
def expandvars(self): ...
def dirname(self): ...
def basename(self): ...
def expand(self): ...
def splitpath(self): ...
def splitdrive(self): ...
def splitext(self): ...
def stripext(self): ...
def splitunc(self): ... [1]
def joinpath(self, *args): ...
def splitall(self): ...
def relpath(self): ...
def relpathto(self, dest): ...

# Properties about the path.
parent, name, namebase, ext, drive, uncshare[1]

# Operations that return lists of paths.
def listdir(self, pattern = None): ...
def dirs(self, pattern = None): ...
def files(self, pattern = None): ...
def walk(self, pattern = None): ...
def walkdirs(self, pattern = None): ...
def walkfiles(self, pat

Re: [Python-Dev] stabilizing builds

2006-01-24 Thread Gregory P. Smith
On Sun, Jan 22, 2006 at 11:01:36PM -0800, Neal Norwitz wrote:
> rather than later.  There are a bunch of tests that are not stable. 
> It would really help to get people knowledgeable about a particular
> subdomain to provide input into bugs/patches and produce patches too!
> 
> The areas that are known to have problems are listed here:
> http://wiki.python.org/moin/BuildBot
> 
> It would be nice to clean those issues up.  Does anyone have some time
> to spend to resolve the issues with Berkeley DB?  That's the one that
> annoys me most right now.  I have a patch that fixes at least one of
> the problems, but no idea if it's the correct solution or not. 
> http://python.org/sf/1407992

Nice!  It does fix the associate test problem on BerkeleyDB 3.3-4.1
and 4.2-4.4 continue to pass.  I committed it.  Good to have tests
passing again when using "old" but still common BerkeleyDBs.

> * BSD DB 4.1 and 3.2 fail

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.

___
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

2006-01-24 Thread Charles Cazabon
BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> 
> 1. Make all python files in the a directory executable:
[...]
> ==>
> for f in Path('/usr/home/guido/bin'):
> f.chmod(0755)

Iterating over a path string to read the contents of the directory possibly
pointed to by that string seems like "magic implicit" behaviour.  Perhaps
making it a method explicitly returning an iterator would by more Pythonic?

for f in Path(...).readDir():

> 4. Splitting a path into directory and filename:
[...]
> Path("/path/to/foo/bar.txt").splitpath()

Good.  But the opposite isn't done similarly:

> 6. Create directory paths:
[...]
> Path("foo") / "bar" / "baz"

Using "/" as "path concatenation operator" seems like un-Pythonic magic as
well (while "+" would be an improvement, it's still not a large one).  I would
think 

Path('foo').appendparts('bar', 'baz')

or similar would be more readable and obvious.

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


Re: [Python-Dev] The path module PEP

2006-01-24 Thread Eric Nieuwland
Good stuff. Some suggestions:

> def joinpath(self, *args): ...
I suggest append() or extend() as join*() sort of suggest join() as 
provided by strings, which does something quite different

> def splitall(self): ...
and this may renamed split(), as it is quite similar to split() as 
provided by strings

> # Properties about the path.
> parent, name, namebase, ext, drive, uncshare[1]
so we can drop basename(), dirname(), splitdrive(), and splitext()

> def dirs(self, pattern = None): ...
> def files(self, pattern = None): ...
can we add others()? (sockets, pipes, block and character devices)

--eric

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


Re: [Python-Dev] The path module PEP

2006-01-24 Thread Jason Orendorff
Thanks for doing this.  I'm not sure anyone that matters here is
actually keen on path, but I guess we'll see.  A few comments:

On 1/24/06, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> The following points summarizes the design:
>
> - Path extends from string, therefore all code which expects
>   string pathnames need not be modified and no existing code will
>   break.

Actually, I would prefer a Path that *didn't* subclass string, and a
new "%p" format-thingy in PyArg_ParseTuple().  %p would expect either
a Path object or a string.  Stdlib C functions that take paths would
be changed from using %s or %u to %p.  This would pretty much
eliminate the need for path objects to act like strings (except where
__cmp__, __hash__, and common sense dictate).

The only reason I didn't do this in path.py is that I don't have the
required write access to the Python source tree. ;)  Subclassing
str/unicode seemed like the next best thing.


> [...]omitted:
> * Function for opening a path - better handled by the builtin
>   open().

Aside:  I added this to support a few people who liked the idea of
"openable objects", meaning anything that has .open(), analogous to
"writeable objects" being anything with .write().  I don't use it
personally.

Examples 1 and 2 have errors.  In example 1, the "after" code should be:

  d = path('/usr/home/guido/bin')
  for f in d.files('*.py'):
  f.chmod(0755)

In example 2, the "before" code is missing a line -- the call to
os.path.walk().  (Actually it should probably use os.walk(), which
looks much nicer.)

I suspect you'll be asked to change the PEP to remove __div__ for
starters, in which case I propose using the Path constructor as the
replacement for os.path.join().  In that case, Path.joinpath can be
dropped.

-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

2006-01-24 Thread Ian Bicking
Charles Cazabon wrote:
> BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
> 
>>1. Make all python files in the a directory executable:
> 
> [...]
> 
>>==>
>>for f in Path('/usr/home/guido/bin'):
>>f.chmod(0755)
> 
> 
> Iterating over a path string to read the contents of the directory possibly
> pointed to by that string seems like "magic implicit" behaviour.  Perhaps
> making it a method explicitly returning an iterator would by more Pythonic?
> 
> for f in Path(...).readDir():

I believe .listdir() exists already as a method alternative.  I'm -0 on 
iteration as listdir.  Doing iteration like strings (over the 
characters) would be evil.

>>4. Splitting a path into directory and filename:
> 
> [...]
> 
>>Path("/path/to/foo/bar.txt").splitpath()
> 
> 
> Good.  But the opposite isn't done similarly:
> 
> 
>>6. Create directory paths:
> 
> [...]
> 
>>Path("foo") / "bar" / "baz"
> 
> 
> Using "/" as "path concatenation operator" seems like un-Pythonic magic as
> well (while "+" would be an improvement, it's still not a large one).  I would
> think 
> 
> Path('foo').appendparts('bar', 'baz')
> 
> or similar would be more readable and obvious.

.joinpath() does this.  Though .join() does something else entirely that 
it inherits from strings, something evil to do with a path, and I think 
that method should raise NotImplementedError.  + should not be 
overridden, because strings define that.

Some other str methods are harmless but pointless: center, expandtabs, 
ljust, zfill; title, capitalize, and istitle are iffy.  Also, are there 
any particular cases where string methods on a path produce an actual 
str, not another Path object?


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

2006-01-24 Thread Ian Bicking
Jason Orendorff wrote:
>>[...]omitted:
>>* Function for opening a path - better handled by the builtin
>>  open().
> 
> 
> Aside:  I added this to support a few people who liked the idea of
> "openable objects", meaning anything that has .open(), analogous to
> "writeable objects" being anything with .write().  I don't use it
> personally.

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

> I suspect you'll be asked to change the PEP to remove __div__ for
> starters, in which case I propose using the Path constructor as the
> replacement for os.path.join().  In that case, Path.joinpath can be
> dropped.

I'm -1 on this too.  This means people will be hardcoding the specific 
class they expect, so you can't pass in other classes.  E.g., this will 
fail:

   def read_config(home_dir):
   f = open(Path(home_dir, '.config_file'))
   c = f.read()
   f.close()
   return c

   read_config(URI('http://localhost/foo'))

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.  But barring /, .joinpath() should remain. 
Too bad there isn't a shorter name, except .join() which is taken.

I would also, though, note that there are some security issues.  When 
you use open() or other path-related functions, you *know* you are doing 
filesystem operations.  You can't be getting some weird object that does 
who-knows-what.  For the most part if you can get an arbitrary object 
into the system then the system is just broken, but I can imagine cases 
where this encourages people to do bad things.  I only bring this up 
because it reminds me of PHP allowed over-the-net includes, which always 
seemed like a bad idea.

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

2006-01-24 Thread Ian Bicking
BJörn Lindqvist wrote:
> * Functions for reading and writing a whole file - better handled
>   by file objects read() and write() methods.

I would be disappointed to see this left out, because I get really tired 
of this little dance:

   f = open(filename)
   c = f.read()
   f.close()
   return c

Then you can put a try:finally: in there too for extra correctness. 
Anyway, I write this code all the time, and it's really tiresome. 
open(filename).read() also works, but relies on Python's reference 
counting to be really reliable; maybe I shouldn't worry about that and 
use just that form.  But that bothers me too.  The same occurs during 
writing.

The original Path object has a bytes and text method (I think), which 
nicely distinguishes between the two cases.  This helps suggest better 
and more explicit handling of unicode, something that Python should work 
harder at making clear.


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

2006-01-24 Thread Nick Coghlan
Ian Bicking wrote:
> BJörn Lindqvist wrote:
>> * Functions for reading and writing a whole file - better handled
>>   by file objects read() and write() methods.
> 
> I would be disappointed to see this left out, because I get really tired 
> of this little dance:
> 
>f = open(filename)
>c = f.read()
>f.close()
>return c

Python 2.5 (well, once someone finds time to update mwh's patch):

   with open(filename) as f:
 return f.read()

Behaviour guaranteed by language definition ;)

Cheers,
Nick.

P.S. I too would really like to see this happen for 2.5.

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


[Python-Dev] Long-time shy failure in test_socket_ssl

2006-01-24 Thread Tim Peters
Has anyone else noticed this?  For a long time (possibly years), I see
an infrequent error in test_socket_ssl, like so (this is on WinXP
Pro):

test_socket_ssl
test test_socket_ssl crashed -- exceptions.TypeError: 'NoneType'
object is not callable

I haven't been able to provoke it by running test_socket_ssl in a
loop, and I don't have a guess about what's going wrong by eyeballing
the code.

test_rude_shutdown() is dicey, relying on a sleep() instead of proper
synchronization to make it probable that the `listener` thread goes
away before the main thread tries to connect, but while that race may
account for bogus TestFailed deaths, it doesn't seem possible that it
could account for the kind of failure above.
___
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] [PATCH] Fix dictionary subclass semantics whenused as global dictionaries

2006-01-24 Thread Martin v. Löwis
Crutcher Dunnavant wrote:
> Okay, but is there any reason not to include this in 2.5? There
> doesn't seem to be any noticeable performance impact, and it does add
> consistancy (and opens some really, really cool options up).

I see no reason, except perhaps the lack of volunteers to actually
patch the repository (along with the accompanying work).

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


Re: [Python-Dev] stabilizing builds

2006-01-24 Thread Martin v. Löwis
Thomas Wouters wrote:
> FWIW, it's brittle on Solaris 9, too, and the SF compilefarm has two of
> those. I don't know if it's the same problem, but on Solaris 9, the slave
> part of the tty/pty pair sometimes isn't a TTY (according to os.isatty.) The
> buildbot's log doesn't list the solaris 10 test_pty failure though, just the
> test_logging failure.

It occasionally failed in test_pty, too, with the very same error
message (that /dev/tty isn't a tty).

> It looks like a timing issue; the first run succeeds, all subsequent runs
> fail, for a while, anyway. I'll do some googling and browsing other
> tty/pty-using code to see if there's anything we're not doing we should be
> doing, but it looks like a platform bug that we can't fix... Not without
> re-implementing os.isatty anyway ;P

Couldn't there be a bug in openpty instead? Perhaps it is trying to
allocate the same device again, but fails to do so correctly, and fails
to recognize that it should use a different one instead.

Anyway, if you still think you need an OS 10 account, please let me
know, and I can give you an account to the machine the buildbot
runs on.

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


Re: [Python-Dev] The path module PEP

2006-01-24 Thread Oleg Broytmann
On Tue, Jan 24, 2006 at 09:22:01PM +0100, BJ?rn Lindqvist wrote:
> Path("foo") / "bar" / "baz"

   I really love this! But I am afraid it's too much a Unixism. (-:

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

2006-01-24 Thread Gustavo J. A. M. Carneiro
On Tue, 2006-01-24 at 21:22 +0100, BJörn Lindqvist wrote:
[...]

> # Operations on path strings.
> def abspath(sef): ...
> def normcase(self): ...
> def normpath(self): ...
> def realpath(self): ...
> def expanduser(self): ...
> def expandvars(self): ...
> def dirname(self): ...
> def basename(self): ...
> def expand(self): ...
> def splitpath(self): ...
> def splitdrive(self): ...
> def splitext(self): ...
> def stripext(self): ...
> def splitunc(self): ... [1]
> def joinpath(self, *args): ...
> def splitall(self): ...
> def relpath(self): ...
> def relpathto(self, dest): ...
[...etc...]

  If we wanted to take PEP 8 seriously, those method names should be
changed to words_separated_by_underscores.

  And BTW, what does splitunc do?  It really should have a more
descriptive name.

  Regards.

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

2006-01-24 Thread Ian Bicking
Ian Bicking wrote:
> I'm -1 on this too.  This means people will be hardcoding the specific 
> class they expect, so you can't pass in other classes.  E.g., this will 
> fail:
> 
>def read_config(home_dir):
>f = open(Path(home_dir, '.config_file'))
>c = f.read()
>f.close()
>return c
> 
>read_config(URI('http://localhost/foo'))

It occurs to me that it might be hopeless to expect substitution to work 
generally (at least without a specific thought on the matter) because I 
expect this form will be typical:

   def read_config(path):
   # convert string input to a path (has no effect on Path objects):
   path = Path(path)
   content = path.text()

Since people will be passing strings in to file-related functions for 
the forseeable future, so people will coerce that input to paths 
explicitly whenever they accept a path from a public function.

Now, if there were a way to make sure that "Path(x) is x" is true when x 
is already a Path, and maybe a way to coerce strings to a Path without 
coercing Path-like objects into Path objects, that would help resolve 
the problem.

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

2006-01-24 Thread Trent Mick
[Gustavo J. A. M. Carneiro wrote]
>   And BTW, what does splitunc do? 

http://en.wikipedia.org/wiki/Path_%28computing%29#Universal_Naming_Convention

> It really should have a more descriptive name.

No more that should "urllib" or "splitext".

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

2006-01-24 Thread Tony Meyer
> The last time this was discussed six months ago it seemed like most of
> python-dev fancied Jason Orendorff's path module. But Guido wanted a
> PEP and noone created one. So I decided to claim the fame and write
> one since I also love the path module. :) Much of it is copy-pasted
> from Peter Astrand's PEP 324, many thanks to him.

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:



=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

2006-01-24 Thread Fredrik Lundh
Gustavo J. A. M. Carneiro wrote:

> > # Operations on path strings.
> > def abspath(sef): ...
> > def normcase(self): ...
> > def normpath(self): ...
> > def realpath(self): ...
> > def expanduser(self): ...
> > def expandvars(self): ...
> > def dirname(self): ...
> > def basename(self): ...
> > def expand(self): ...
> > def splitpath(self): ...
> > def splitdrive(self): ...
> > def splitext(self): ...
> > def stripext(self): ...
> > def splitunc(self): ... [1]
> > def joinpath(self, *args): ...
> > def splitall(self): ...
> > def relpath(self): ...
> > def relpathto(self, dest): ...
> [...etc...]
>
>   If we wanted to take PEP 8 seriously, those method names should be
> changed to words_separated_by_underscores.
>   And BTW, what does splitunc do?  It really should have a more
> descriptive name.

when did you last use the os.path module ?





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


Re: [Python-Dev] The path module PEP

2006-01-24 Thread Ian Bicking
Gustavo J. A. M. Carneiro wrote:.
>>def splitall(self): ...
>>def relpath(self): ...
>>def relpathto(self, dest): ...
> 
> [...etc...]
> 
>   If we wanted to take PEP 8 seriously, those method names should be
> changed to words_separated_by_underscores.

There's a (unspecified?) convention that many standard/core objects or 
objects in the standard library use squishedwords for methods.  has_key 
is an anomoly, not the norm.

Also, many of these are direct translations of methods from os.path, and 
so the names offer familiarity.

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

2006-01-24 Thread Ian Bicking
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'm not strongly advocating any of the methods below be removed, but at 
least it seems like it should be discussed.  By not removing any it is 
easier to translate the os.path (and other) forms.  I imagine it will be 
a long time before those forms go away, though, so I don't know how 
useful it is to plan for a speedy and seamless transition.

BJörn Lindqvist wrote:
> This class defines the following public methods:
> 
> # Special Python methods.
> def __new__(cls, init = os.curdir): ...
> def __repr__(self): ...
> def __add__(self, more): ...
> def __radd__(self, other): ...
> def __div__(self, rel): ...
> def __truediv__(self, rel): ...
> 
> # Alternative constructor.
> def cwd(cls): ...
> 
> # Operations on path strings.
> def abspath(sef): ...
> def normcase(self): ...
> def normpath(self): ...
> def realpath(self): ...
> def expanduser(self): ...
> def expandvars(self): ...

This is equivalent to 
p.__class__(string.Template(p).safe_substitute(os.environ)).  Obviously 
that form is a lot longer, but maybe usefully more explicit.  Well, it 
is a *lot* longer.  But if string.Template's functionality becomes a 
method on str (is that the plan?) then this won't be so bad.  Also if 
string.Template returns an object of the same class as is passed in. 
Then maybe it'd just be p.safe_substitute(os.environ), which isn't bad 
at all.

Maybe if this used Windows conventions on that platform -- of %VAR% -- 
it would seem more useful.  Though I think $VAR should still work on 
both platforms regardless (just like / does).

> def dirname(self): ...
> def basename(self): ...

These are duplicated as properties.  basename and namebase are confusing 
alternatives to each other.

> def expand(self): ...

I see this is a combination of normpath, expanduser, and expandvars. 
Useful, certainly.  But there's also a lot of forms, and no one applies 
these operations consistently it seems.

> def splitpath(self): ...
> def splitdrive(self): ...
> def splitext(self): ...
> def stripext(self): ...

This is another new method, equivalent to .splitext()[0].  I'm not sure 
it's that important.

> def splitunc(self): ... [1]
> def joinpath(self, *args): ...
> def splitall(self): ...

And there's just so many splitting functions.  Could these somehow be 
combined?  Maybe returning a tuple/struct?  Or maybe just relying on 
properties.

> def relpath(self): ...
> def relpathto(self, dest): ...

These don't feel compellingly different according to the name.  I find 
the cwd fragile too, so maybe the first form offends me from that 
perspective too.  Just the explicit form feels sufficient to me, and 
unambiguous as both a reader and writer of code.

> # Properties about the path.
> parent, name, namebase, ext, drive, uncshare[1]

Actually, I see namebase is actually the name without an extension.  It 
seems ambiguous to me just from the names, and I'd rather both weren't 
there.  Though ext somehow seems useful and unambiguous in a way 
namebase isn't.  Not sure why.

It's unclear which of these should be Paths.  Of course parent should. 
None of the others?  When methods return paths and when they return 
strings is an important part of the spec.

> # Operations that return lists of paths.
> def listdir(self, pattern = None): ...
> def dirs(self, pattern = None): ...
> def files(self, pattern = None): ...
> def walk(self, pattern = None): ...
> def walkdirs(self, pattern = None): ...
> def walkfiles(self, pattern = None): ...

Notably these aren't like os.path.walk, I assume.  Which is fine by me.

> def match(self, pattern):
> def matchcase(self, pattern):

I don't see these methods in the path class, and I'm not sure what 
they'd do.

> def glob(self, pattern):
> 
> # Methods for retrieving information about the filesystem
> # path.
> def exists(self): ...
> def isabs(self): ...
> def isdir(self): ...
> def isfile(self): ...
> def islink(self): ...
> def ismount(self): ...
> def samefile(self, other): ... [1]
> def getatime(self): ...
> def getmtime(self): ...
> def getctime(self): ...
> def getsize(self): ...
> def access(self, mode): ... [1]
> def stat(self): ...
> def lstat(self): ...
> def statvfs(self): ... [1]

The stat and get* functions overlap too.  I.e., p.getmtime() and 
p

Re: [Python-Dev] Long-time shy failure in test_socket_ssl

2006-01-24 Thread Tim Peters
[Tim Peters]
> ...
> test_rude_shutdown() is dicey, relying on a sleep() instead of proper
> synchronization to make it probable that the `listener` thread goes
> away before the main thread tries to connect, but while that race may
> account for bogus TestFailed deaths, it doesn't seem possible that it
> could account for the kind of failure above.

Well, since it's silly to try to guess about one weird failure when a
clear cause for another kind of weird failure is known, I checked in
changes to do "proper" thread synchronization and termination in that
test.  Hasn't failed here since, but that's not surprising (it was
always a "once in a light blue moon" kind of thing).

I'm not sure how/whether this test is supposed to work with Jython --
perhaps the `thread.exit()` I removed could be important there.  The
test relies on that a socket gets closed when a socket object becomes
trash & is reclaimed; in CPython that's easy to control; I don't know
why the test didn't/doesn't simply do an explicit s.close() instead.
___
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] Know anyone interested in a Google internship?

2006-01-24 Thread Guido van Rossum
Sorry for the plug.

Google is looking to fill an unprecedented number of student intern
positions this summer, at several US locations (Mountain View, Santa
Monica, Kirkland (Wash.), and New York). If you're interested or know
someone interested, please see
http://www.google.com/jobs/intern.html. Candidates from outside the US
are welcome. The perks are incredible (just ask Brett Cannon, who's
coming back for the second year this summer :-).

We're not just looking for software development interns -- there are
also product management positions, and UI design and usability analyst
positions.

I can't guarantee that I'll be mentoring you, but if you end up using
Python in Mountain View, I'm sure we'll be interacting quite a bit!

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


Re: [Python-Dev] stabilizing builds

2006-01-24 Thread Thomas Wouters
On Tue, Jan 24, 2006 at 11:52:52PM +0100, "Martin v. Löwis" wrote:

> > It looks like a timing issue; the first run succeeds, all subsequent runs
> > fail, for a while, anyway. I'll do some googling and browsing other
> > tty/pty-using code to see if there's anything we're not doing we should be
> > doing, but it looks like a platform bug that we can't fix... Not without
> > re-implementing os.isatty anyway ;P

> Couldn't there be a bug in openpty instead? Perhaps it is trying to
> allocate the same device again, but fails to do so correctly, and fails
> to recognize that it should use a different one instead.

Well, a bug in openpty is what I started with. Python's posix.openpty() that
is, as Solaris doesn't have openpty. Openpty is emulated using code taken
almost verbatim from Solaris' pts(7D) manpage:

 fdm = open("/dev/ptmx", O_RDWR);  /* open master */
 grantpt(fdm); /* change permission of   slave */
 unlockpt(fdm);/* unlock slave */
 slavename = ptsname(fdm); /* get name of slave */
 fds = open(slavename, O_RDWR);/* open slave */
 ioctl(fds, I_PUSH, "ptem");   /* push ptem */
 ioctl(fds, I_PUSH, "ldterm"); /* push ldterm*/

(That's the manpage code.) This is also what openssh does (as far as I can
tell). Screen does it slightly differently; it does the ptsname() call
before the grantpt/unlockpt calls, but the open(slavename) after. If I make
posixmodule do that, it still fails on Solaris. Mucking with it more just
breaks it more.

The thing is, disabling the check that fails, whether the slave-tty returned
by os.openpty() is a tty, shows that the later test for the same thing
succeeds. The later test is done in a child created by pty.fork(). Disabling
the ptmx code on Solaris is probably the most reliable way to fix the
failing test; the pty module will fall back to old-style BSD pty code and
that works fine. But it's a bit of a shame not to use /dev/ptmx just because
the slave fd, when used directly (rather than in a child process) sometimes
doesn't seem to be a tty. They're still connected, it still seems to work
fine.

> Anyway, if you still think you need an OS 10 account, please let me
> know, and I can give you an account to the machine the buildbot
> runs on.

I think I've seen enough confusing situations for a while... I'm sure the
bug is the same on Solaris 10 ;P

-- 
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] New Pythondoc by effbot

2006-01-24 Thread Mike Brown
BJ> Why does it have to be "wiki-like"? Why can't it be a wiki? MediaWiki
> seem to work pretty well for a lot of software projects that have put
> their documentation in a wiki. Talk pages for commentary and primary
> pages for reviewed content.

And inconsistent formatting from article to article, limitations in indexing
options, no way to browse a set of documentation specific to a particular
Python release...

I personally like the PHP docs - http://www.php.net/manual/en/

They're not versioned, and users can't modify the indexes or API docs, but
they do get to add annotations. Annotations that reflect errors or major 
omissions from the docs can be reviewed by editors and folded into the docs
as needed. *shrug*
___
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?

2006-01-24 Thread Jeremy Hylton
On 1/24/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Sorry for the plug.
>
> Google is looking to fill an unprecedented number of student intern
> positions this summer, at several US locations (Mountain View, Santa
> Monica, Kirkland (Wash.), and New York). If you're interested or know
> someone interested, please see
> http://www.google.com/jobs/intern.html. Candidates from outside the US
> are welcome. The perks are incredible (just ask Brett Cannon, who's
> coming back for the second year this summer :-).
>
> We're not just looking for software development interns -- there are
> also product management positions, and UI design and usability analyst
> positions.
>
> I can't guarantee that I'll be mentoring you, but if you end up using
> Python in Mountain View, I'm sure we'll be interacting quite a bit!

And I'd be happy to work with folks in New York!

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