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
> some
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
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
>
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.
[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 th
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.
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 (unspecifi
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): ...
> >
> 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 As
[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]
_
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
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
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
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 tes
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
patc
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_
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)
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()
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
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 t
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 expe
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() a
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
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
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 PE
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
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:
> Cru
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 a
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-
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 ma
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"
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/
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.
w
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 sugg
34 matches
Mail list logo
