Re: [Python-Dev] PEP 433: second try

2013-01-30 Thread Victor Stinner 
2013/1/30 Larry Hastings :
> Here is a new version of my PEP 433.
> [...]
>  * ``os.get_cloexec(fd)``
>  * ``os.set_cloexec(fd, cloexec=True)``
>  * ``sys.getdefaultcloexec()``
>  * ``sys.setdefaultcloexec(cloexec=True)``
>
> Passing no judgment on the PEP otherwise, just a single observation: the
> "cloexec" parameter to "sys.setdefaultcloexec" should not have a default.

Oh, it's a mistake: sys.setdefaultcloexec() has one parameter and it
is mandatory:
sys.setdefaultcloexec(cloexec)

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 433: second try

2013-01-30 Thread Victor Stinner 
> Disable inheritance by default
> (...)
> * It violates the principle of least surprise.  Developers using the
>   os module may expect that Python respects the POSIX standard and so
>   that close-on-exec flag is not set by default.

Oh, I just saw that Perl is "violating POSIX" since Perl 1:
close-on-exec flag in set on new created file descriptors if their
number is greater than $SYSTEM_FD_MAX (which is usually 2).

So Python would not be the only language providing a convinient
default behaviour ;-) (And Ruby 2 will also set close-on-exec by
default.)

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 433: second try

2013-01-30 Thread Hrvoje Niksic 

On 01/30/2013 01:00 PM, Victor Stinner wrote:

Disable inheritance by default
(...)
* It violates the principle of least surprise.  Developers using the
  os module may expect that Python respects the POSIX standard and so
  that close-on-exec flag is not set by default.


Oh, I just saw that Perl is "violating POSIX" since Perl 1:
close-on-exec flag in set on new created file descriptors if their
number is greater than $SYSTEM_FD_MAX (which is usually 2).


I haven't checked the source, but I suspect this applies only to file 
descriptors opened with open(), not to explicit POSIX::* calls.  (The 
documentation of the latter doesn't mention close-on-exec at all.) 
Perl's open() contains functionality equivalent to Python's open() and 
subprocess.Popen(), the latter of which already closes on exec by default.


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

[Python-Dev] Fwd: I was just thinking that os.path could use some love...

2013-01-30 Thread Guido van Rossum 
Thoughts on os.path? What happened to the idea of a new path object?

--Guido


-- Forwarded message --
From: Talin 
Date: Wed, Jan 30, 2013 at 12:34 PM
Subject: Re: I was just thinking that os.path could use some love...
To: Guido van Rossum 


On Wed, Jan 30, 2013 at 11:33 AM, Guido van Rossum  wrote:
>
> Hmm... Mind if I just forward to python-dev? IIRC there's been some
> discussion about a newfangled path object, but I lost track of where
> the discussion went. (Or you can post there yourself. :-)


Sure - forward away. Is this the same as the path object idea that was
floated 5 years ago? I've yet to see any set of convenience methods
for paths that are so compelling as to be worth all of the time and
energy needed to update all of the various APIs which now expect paths
to be passed in as strings.
>
>
> On Wed, Jan 30, 2013 at 11:13 AM, Talin  wrote:
> > I just realized that os.path hasn't changed in a long time. Here's a couple
> > of ideas for additions:
> >
> > os.path.splitall(path) - splits all path components into a tuple - so for
> > example, 'this/is/a/path' turns into ('this', 'is', 'a', 'path'). If there's
> > a trailing slash, the last item in the tuple will be a zero-length string.
> > The main reason for having this in os.path is so that we can remain
> > separator-character-agnostic.
>
> Would it also return a leading empty string if the path starts with /?
> What about Windows C: or //host/ prefixes???
>
I would say that it should only split on directory separators, not any
other kind of delimiter, so that each component is a valid filesystem
identifier. Further, the operation should be reversible by calling
os.path.join(*dirnames). So it's a little more complex than just
string.split('/').

Part of the reason for wanting the splitall function is to implement
the common prefix function - you take all the paths, bust them into
tuples, look for the longest tuple prefix, and then join the result
back into a path. This means that
os.path.join(*os.path.splitall(path)) must reproduce the original path
exactly.

>
> > An alternative would be to add an optional 'maxsplits' parameter to
> > os.path.split. Default would be 1; 0 = unlimited. Main disadvantage would be
> > that no one would ever use values 2, 3, etc... but it would be more
> > compatible with other split apis.
> >
> > A version of os.path.commonprefix that always produces valid paths (and
> > works by path component, not character-by-character).
> >
> > I can probably think of others if I look at some other path manipulation
> > apis. llvm::sys::path has a bunch if I recall...
> >
> > --
> > -- Talin
>
>
>
> --
> --Guido van Rossum (python.org/~guido)




--
-- Talin


-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fwd: I was just thinking that os.path could use some love...

2013-01-30 Thread Victor Stinner 
> Thoughts on os.path? What happened to the idea of a new path object?

I don't know if it's related, but there are two new interesting
projects: pathlib and walkdir.

http://pypi.python.org/pypi/pathlib
https://pathlib.readthedocs.org/en/latest/

http://pypi.python.org/pypi/walkdir
http://walkdir.readthedocs.org/en/latest/
http://bugs.python.org/issue13229

Victor
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fwd: I was just thinking that os.path could use some love...

2013-01-30 Thread R. David Murray 
http://bugs.python.org/issue11344 evolved into a patch for 'splitpath',
similar to splitall.  Antoine's pathlib (PEP 428) is also mentioned
at the end, which is probably what Guido is thinking of.

--David

On Wed, 30 Jan 2013 13:26:08 -0800, Guido van Rossum  wrote:
> Thoughts on os.path? What happened to the idea of a new path object?
> 
> --Guido
> 
> 
> -- Forwarded message --
> From: Talin 
> Date: Wed, Jan 30, 2013 at 12:34 PM
> Subject: Re: I was just thinking that os.path could use some love...
> To: Guido van Rossum 
> 
> 
> On Wed, Jan 30, 2013 at 11:33 AM, Guido van Rossum  wrote:
> >
> > Hmm... Mind if I just forward to python-dev? IIRC there's been some
> > discussion about a newfangled path object, but I lost track of where
> > the discussion went. (Or you can post there yourself. :-)
> 
> 
> Sure - forward away. Is this the same as the path object idea that was
> floated 5 years ago? I've yet to see any set of convenience methods
> for paths that are so compelling as to be worth all of the time and
> energy needed to update all of the various APIs which now expect paths
> to be passed in as strings.
> >
> >
> > On Wed, Jan 30, 2013 at 11:13 AM, Talin  wrote:
> > > I just realized that os.path hasn't changed in a long time. Here's a 
> > > couple
> > > of ideas for additions:
> > >
> > > os.path.splitall(path) - splits all path components into a tuple - so for
> > > example, 'this/is/a/path' turns into ('this', 'is', 'a', 'path'). If 
> > > there's
> > > a trailing slash, the last item in the tuple will be a zero-length string.
> > > The main reason for having this in os.path is so that we can remain
> > > separator-character-agnostic.
> >
> > Would it also return a leading empty string if the path starts with /?
> > What about Windows C: or //host/ prefixes???
> >
> I would say that it should only split on directory separators, not any
> other kind of delimiter, so that each component is a valid filesystem
> identifier. Further, the operation should be reversible by calling
> os.path.join(*dirnames). So it's a little more complex than just
> string.split('/').
> 
> Part of the reason for wanting the splitall function is to implement
> the common prefix function - you take all the paths, bust them into
> tuples, look for the longest tuple prefix, and then join the result
> back into a path. This means that
> os.path.join(*os.path.splitall(path)) must reproduce the original path
> exactly.
> 
> >
> > > An alternative would be to add an optional 'maxsplits' parameter to
> > > os.path.split. Default would be 1; 0 = unlimited. Main disadvantage would 
> > > be
> > > that no one would ever use values 2, 3, etc... but it would be more
> > > compatible with other split apis.
> > >
> > > A version of os.path.commonprefix that always produces valid paths (and
> > > works by path component, not character-by-character).
> > >
> > > I can probably think of others if I look at some other path manipulation
> > > apis. llvm::sys::path has a bunch if I recall...
> > >
> > > --
> > > -- Talin
> >
> >
> >
> > --
> > --Guido van Rossum (python.org/~guido)
> 
> 
> 
> 
> --
> -- Talin
> 
> 
> -- 
> --Guido van Rossum (python.org/~guido)
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: 
> http://mail.python.org/mailman/options/python-dev/rdmurray%40bitdance.com
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fwd: I was just thinking that os.path could use some love...

2013-01-30 Thread Skip Montanaro 
> Thoughts on os.path? What happened to the idea of a new path object?

You old pot stirrer! 

I wonder about this from time-to-time as well, so was just interested
enough to wander over to PyPI and see what I could dig up.  There are
a couple path module/package implementations on PyPI.  Nothing jumped
out at me as the One True Way.   I think you are probably thinking of
Jason Orendorff's path.py module:

http://pypi.python.org/pypi/path.py

There are also two PEPs:

http://www.python.org/dev/peps/pep-0355/
http://www.python.org/dev/peps/pep-0428/

The former was rejected.  The latter still seems to have legs, and an
implementation:

http://pypi.python.org/pypi/pathlib/0.7

Skip
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Fwd: I was just thinking that os.path could use some love...

2013-01-30 Thread Cameron Simpson 
On 30Jan2013 13:26, Guido van Rossum  wrote:
| Thoughts on os.path? What happened to the idea of a new path object?  [...]
| From: Talin  [...]
| On Wed, Jan 30, 2013 at 11:33 AM, Guido van Rossum  wrote:
| > Hmm... Mind if I just forward to python-dev? IIRC there's been some
| > discussion about a newfangled path object, but I lost track of where
| > the discussion went. (Or you can post there yourself. :-)
| 
| Sure - forward away. Is this the same as the path object idea that was
| floated 5 years ago? I've yet to see any set of convenience methods
| for paths that are so compelling as to be worth all of the time and
| energy needed to update all of the various APIs which now expect paths
| to be passed in as strings.

Speaking for myself, I've been having some usefulness with making "URL"
objects that are subclasses of str. That lets me pass them to all the
things that already expect strs, while still having convenience methods.

Combined with a little factory function to make a "URL" from a bare
str should it be needed, it has worked fairly well. It is certainly not
seamless all the time...

Eg:
  U = URL(s)# returns s if already an instance of _URL
  len(U)# I'm still a string
  U.startswith("http:")
  U.scheme  # eg "http"
  U.hrefs   # fetch content, parse as HTML, return links

Just a thought on supporting code expecting strings.

Cheers,
-- 
Cameron Simpson 

Outside of a dog, a book is a man's best friend.  Inside of a dog, it's too
dark to read. - Groucho Marx
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] I was just thinking that os.path could use some love...

2013-01-30 Thread Glyph 
On Jan 30, 2013, at 2:01 PM, Cameron Simpson  wrote:

> Speaking for myself, I've been having some usefulness with making "URL"
> objects that are subclasses of str. That lets me pass them to all the
> things that already expect strs, while still having convenience methods.

str subclasses are problematic.  One issue is that it will still allow for 
invalid manipulations.  If you prohibit them, then manipulations that take 
multiple steps will be super inconvenient.  If you allow them, then you end up 
with half-formed values that will error out sometimes, or generate corrupt data 
that shouldn't be allowed to exist (trivial example; a NUL character in the 
middle of a file path).  Also, automatic coercion will sometimes surprise you 
and give you a value which is of the wrong type if you forget a method or two.

Also URL and file paths have a common interface, but are not totally the same.

Basically, everybody wants to say "composition is better than inheritance, 
except for *this* case, where inheritance seems super convenient".  That's how 
it gets you!  Inheritance _is_ super convenient, but it's also super confusing. 
 Resist the temptation :-).

Once again (I see my previous reply went straight to the sender, not the whole 
list) I recommend  as an abstraction that has 
worked very well in a wide variety of situations.

-glyph___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] mingw32 port

2013-01-30 Thread Matthias Klose 
[No, I'm not interested in the port myself]

patches for a mingw32 port are floating around on the web and the python bug
tracker, although most of them as a set of patches in one issue addressing
several things, and which maybe outdated for the trunk. at least for me
re-reading a big patch in a new version is more work than having the patches in
different issues. So proposing to break down the patches in independent ones,
dealing with:

 - mingw32 support (excluding any cross-build support). tested with
   a native build with srcdir == builddir. The changes for distutils
   mingw32 support should be a separate patch. Who could review these?
   Asked Martin, but didn't get a reply yet.

 - patches to cross-build for mingw32.

 - patches to deal with a srcdir != builddir configuration, where the
   srcdir is read-only (please don't mix with the cross-build support).

All work should be done on the tip/trunk.

So ok to close issue16526, issue3871, issue3754 and suggest in the reports to
start over with more granular changes?

  Matthias
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] mingw32 port

2013-01-30 Thread R. David Murray 
On Thu, 31 Jan 2013 00:49:38 +0100, Matthias Klose  wrote:
> So ok to close issue16526, issue3871, issue3754 and suggest in the reports to
> start over with more granular changes?

+1 from me.  Over time I've suggested to at least two people, maybe
more, who wanted to see some action on these that the way to make
progress on it was to break everything down into the to smallest
independent patches possible. So far no one has followed through on
it, obviously.

[And no, I'm not interested in the port myself, either :)]

--David
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com