Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Bugs

[issue3177] Add shutil.open

 

 

Python bugs RSS feed   Index | Next | Previous | View Threaded


report at bugs

Apr 22, 2012, 10:52 PM

Post #1 of 36 (266 views)
Permalink
[issue3177] Add shutil.open

Hobs <hobsonlane [at] gmail> added the comment:

@eric.araujo, @giampaolo.rodola,
(http://bugs.python.org/issue3177#msg140275)

I'm not sure I understand why this was moved to shutil.open. It seems appropriate to try to accomplish what os.startfile() does in a cross-platform way. Don't many of the other os.* calls do this--check os.name and then "do the right thing". This is the first os.* call I've found that doesn't work on linux (though I'm sure there are many others). Is the reason because the name 'startfile' is a Windows creation and sounds Windowsy? If so, shouldn't os.startfile() be renamed to something generic like os.launch() or .launchfile()? But then you'd have reverse-compatibility issues.

Why not just enhance os.startfile() so it doesn't barf if you try to use it on posix/mac? I'll try to contribute to the shutil.open() effort too.

----------
nosy: +Hobson.Lane

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 1:04 AM

Post #2 of 36 (267 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Chris Rebert <pybugs [at] rebertia> added the comment:

Here's a quick stab at 2/3rds of an implementation, and some docs.

----------
Added file: http://bugs.python.org/file25310/shutil_open.py

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 3:29 AM

Post #3 of 36 (258 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Hobs <hobsonlane [at] gmail> added the comment:

Test passes on Ubuntu Oneiric Linux and 'open' action appropriately defaults to launching an editor for my particular OS settings.

Tests on Windows in work.

----------
Added file: http://bugs.python.org/file25311/shutil_launch.py

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 3:39 AM

Post #4 of 36 (257 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Hobs <hobsonlane [at] gmail> added the comment:

Implement shutil.launch() & fix minor shutil.disk_usage() doctext typo

Name changed from shutil.open to shutil.launch due to namespace conflict with open() builtin within the shutil module and for users that do

from shutil import *

On Ubuntu Oneiric Linux shutil.launch() doctest passes and `./python -m test -j3` doesn't change (OS-appropriate tests all pass).

Windows tests in work. Need Mac testing too.

----------
Added file: http://bugs.python.org/file25312/shutil_open.patch

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 4:30 AM

Post #5 of 36 (257 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Chris Rebert <pybugs [at] rebertia> added the comment:

> # or os.name == 'mac' ???

Nope, that refers to retro Mac OS 9 (and probably lower). Mac OS X is 'posix' for os.name purposes.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 4:53 AM

Post #6 of 36 (257 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Chris Rebert <pybugs [at] rebertia> added the comment:

`operation` seems questionable. IMO, the verbs seem stronger / more important than mere optional suggestions (particularly "open" vs. "edit" for files with read-only viewers), and only Windows supports them (so anyone requiring that feature might as well just use startfile() directly). By virtue of this function being cross-platform, we're kinda limited to just supporting the lowest common denominator.

Hobs, can you explain `gui`?

Also, does startfile() raise exceptions for either of the basic error conditions ("no such file" and "no associated application")? If not, I believe using the lower-level ShellExecute (http://msdn.microsoft.com/en-us/library/windows/desktop/bb762153%28v=vs.85%29.aspx ) or similar Windows API function would allow us to report such errors, as the other platform implementations currently do.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 5:20 AM

Post #7 of 36 (260 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Changes by Ram Rachum <ram [at] rachum>:


----------
nosy: -cool-RR

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 5:25 AM

Post #8 of 36 (258 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Changes by R. David Murray <rdmurray [at] bitdance>:


----------
nosy: +r.david.murray

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 5:34 AM

Post #9 of 36 (258 views)
Permalink
[issue3177] Add shutil.open [In reply to]

R. David Murray <rdmurray [at] bitdance> added the comment:

Is the error raising PEP 3151 compliant?

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 5:49 AM

Post #10 of 36 (255 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Chris Rebert <pybugs [at] rebertia> added the comment:

No, it isn't. Changing the `IOError(errno.ENOENT, "...`s to `FileNotFoundError("...`s would half fix it.

The other half, the `OSError(errno.ENOSYS)`s, has a FIXME for what's the right error to raise in that case ("no application associated with files of this type"). I have no idea myself. None of the new PEP 3151 errors apply. Nor did any of the errnos strictly speaking AFAICT; ENOSYS was the closest approximation I could find. Thoughts? Custom error class? Different errno? Something else?

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 5:54 AM

Post #11 of 36 (257 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Antoine Pitrou <pitrou [at] free> added the comment:

> ENOSYS was the closest approximation I could find. Thoughts? Custom
> error class? Different errno? Something else?

Why not ValueError?

----------
nosy: +pitrou

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 6:58 AM

Post #12 of 36 (259 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Éric Araujo <merwok [at] netwok> added the comment:

Thanks for relaunching this!

> I'm not sure I understand why this was moved to shutil.open. It seems appropriate to try to accomplish what
> os.startfile() does in a cross-platform way. Don't many of the other os.* calls do this--check os.name and
> then "do the right thing".
They don’t. The os module is a thin wrapper on top of system functions. Cross-platform compat is not achieved with os.name checks but with platform-specific code in the C files. As Windows provides a call named startfile, it is exposed. When we want to provide a higher-level API on top of system calls, we use other modules such as shutil.

> fix minor shutil.disk_usage() doctext typo
Would you report this on another bug report or simply with a mail to the docs [at] python mailing list? Thanks.

> Name changed from shutil.open to shutil.launch due to namespace conflict with open() builtin within the shutil
> module and for users that do from shutil import *
I don’t think these are good arguments. A lot of modules expose a function named open: tarfile, codecs, tokenize... Python has namespaces, let’s use them. The argument about import * is not strong either in my opinion, because all our docs recommend against this idiom.

One argument against open is that the other open functions I mention above return a file object, like the builtin open. With this in mind I agree that a better name should be found. I dislike launch though because it brings to my mind the idea of running/executing a program, not opening it in the appropriate program.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 7:12 AM

Post #13 of 36 (257 views)
Permalink
[issue3177] Add shutil.open [In reply to]

R. David Murray <rdmurray [at] bitdance> added the comment:

Launch is far better than open for this, I think. If someone can come up with an even better name, that would be good. But I would not like to use open for this function, because it does not behave like other open functions.

The one exception I know of is webbrowser. Webbrowser uses open, but the recommended way to call it is webbrowser.open(), which makes it clear you are opening it in the webbrowser (and opening the webbrowser if needed). shutil.open would convey no such connotation, to my mind. (Only windows does extension based application opening from the *shell* as far as I know.)

Perhaps 'wmopen' (for Window Manager Open)?

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 8:25 AM

Post #14 of 36 (259 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Hobs <hobsonlane [at] gmail> added the comment:

Does no one like "os.startfile" as a home for this? Besides myself and the
original 2008 proposer, of course. Can anyone explain to us newbies why
it's a bad idea to have the cross-platform module do things identically
across platforms?

@David,

`shutils.wmopen` locks you into never implementing the shell application
launching option (`gui`=False in my crude implementation) that so many
projects need. Each project currently implements it in their own
nonstandard way (e.g. Mercurial and Bazaar), sometimes with not so `nice`
consequences.

You're right that only launching from Linux/Mac shell requires manual
selection of an app, but that's exactly the inconvenience that I was hoping
to solve. Many Ubuntu GUI apps use extensions and MIME-types (associated
with extensions) to recognize their files rather than probing magic
headers. Why shouldn't their shell apps be allowed a standard way to do the
same?

If I implemented *exactly* os.startfile() functionality across the 3 major
platforms, would that be enough to interest the community in an
os.startfile() refinement rather than a new shutils.launch()? I'd drop the
distracting `gui` option to make it completely identical, if that helps.
Or, if the community preferred I could *add* the `gui` option to
startfile() across the board so that even Windows users could have the
option of choosing to edit a file within their shell (if they've installed
such an editor, of course).

@Chris,

Thanks for the tip on where to find low level exception information in
Windows. Sounds like a good idea to try to be as identical to
os.startfile() as possible. But that's why I thought the `operation` option
would be attractive to the community.

I'll test on windows (unless someone else chimes in with Windows
experience) and see what I can learn about exceptions and what it would
take to make os.startfile() truly OS-agnostic, all the way down to each
exception raised.

`gui` allows the user to chose to launch a shell-based text editor (emacs,
vi/vim, nano, $EDITOR, based on user settings). It standardizes what bzr,
hg and other popular cross-platform python projects that launch shell
editors do already.

On Mon, Apr 23, 2012 at 10:12 PM, R. David Murray <report [at] bugs>wrote:

>
> R. David Murray <rdmurray [at] bitdance> added the comment:
>
> Launch is far better than open for this, I think. If someone can come up
> with an even better name, that would be good. But I would not like to use
> open for this function, because it does not behave like other open
> functions.
>
> The one exception I know of is webbrowser. Webbrowser uses open, but the
> recommended way to call it is webbrowser.open(), which makes it clear you
> are opening it in the webbrowser (and opening the webbrowser if needed).
> shutil.open would convey no such connotation, to my mind. (Only windows
> does extension based application opening from the *shell* as far as I know.)
>
> Perhaps 'wmopen' (for Window Manager Open)?
>
> ----------
>
> _______________________________________
> Python tracker <report [at] bugs>
> <http://bugs.python.org/issue3177>
> _______________________________________
>

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 8:26 AM

Post #15 of 36 (260 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Éric Araujo <merwok [at] netwok> added the comment:

Please trust us that this is our policy. os is a thin wrapper only.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 8:52 AM

Post #16 of 36 (261 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Hobs <hobsonlane [at] gmail> added the comment:

@Éric

Thanks for clearing up my misunderstanding of os and shutil. I get it now.

I'm sure you know this, and it's clear you agree with changing the name,
but just to add fire to your resolve, the difference between shutil.open()
and the other `*.open()` modules you mention is that most of the others
began their life with `open()` in their namespace (I think). A new `open()`
in shutil, this late in its life, would break a *lot* of old code,
sometimes invisibly. Apps might launch invisibly on servers with X-windows
configured to display remotely, fail to raise exceptions, and leave a lot
of admins dumbfounded and cursing the python standard library migration.
Seems like pretty draconian punishment for bad (but not forbidden or
deprecated) idioms. I'd rather not have my code be one of the rocks in that
stoning. A few would surely fly my way.

On Mon, Apr 23, 2012 at 9:58 PM, Éric Araujo <report [at] bugs> wrote:

>
> Éric Araujo <merwok [at] netwok> added the comment:
>
> Thanks for relaunching this!
>
> > I'm not sure I understand why this was moved to shutil.open. It seems
> appropriate to try to accomplish what
> > os.startfile() does in a cross-platform way. Don't many of the other
> os.* calls do this--check os.name and
> > then "do the right thing".
> They don’t. The os module is a thin wrapper on top of system functions.
> Cross-platform compat is not achieved with os.name checks but with
> platform-specific code in the C files. As Windows provides a call named
> startfile, it is exposed. When we want to provide a higher-level API on
> top of system calls, we use other modules such as shutil.
>
> > fix minor shutil.disk_usage() doctext typo
> Would you report this on another bug report or simply with a mail to the
> docs [at] python mailing list? Thanks.
>
> > Name changed from shutil.open to shutil.launch due to namespace conflict
> with open() builtin within the shutil
> > module and for users that do from shutil import *
> I don’t think these are good arguments. A lot of modules expose a
> function named open: tarfile, codecs, tokenize... Python has namespaces,
> let’s use them. The argument about import * is not strong either in my
> opinion, because all our docs recommend against this idiom.
>
> One argument against open is that the other open functions I mention above
> return a file object, like the builtin open. With this in mind I agree
> that a better name should be found. I dislike launch though because it
> brings to my mind the idea of running/executing a program, not opening it
> in the appropriate program.
>
> ----------
>
> _______________________________________
> Python tracker <report [at] bugs>
> <http://bugs.python.org/issue3177>
> _______________________________________
>

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 9:09 AM

Post #17 of 36 (258 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Hobs <hobsonlane [at] gmail> added the comment:

New patch incorporates improvements from pitrou, cvrebert, r.david.murray, eric.araujo, cool-RR

----------
Added file: http://bugs.python.org/file25315/shutil_open.patch

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 9:12 AM

Post #18 of 36 (258 views)
Permalink
[issue3177] Add shutil.open [In reply to]

R. David Murray <rdmurray [at] bitdance> added the comment:

Initially this issue was about implementing a startfile-equivalent on posix. But if you have to add a gui option to startfile to not lanuch a GUI, and your real goal is a consistent way to launch non-gui programs on posix, then I don't see that this is about implementing startfile, and the enhancement should *definitely* not go in os.

Setting that aside for a moment, let me say something about the wrapper argument. There *is* a lot of compatibility code in os. We do have to jump through hoops to get posix equivalent functionality on Windows. So doing the reverse to get windows-equivalent functionality on posix would seem fair turnabout.

However, it is also true that those hoops we jump through for windows involve calling Windows APIs (the equivalent of the posix system calls we are wrapping). So while the hoops aren't necessarily all that "thin", they are wrappers around APIs at the OS level (thus the name of the module). In this case the hoops are not system calls. So even disregarding my initial comments above, while I don't think the argument is quite as clear cut as Éric does, I do think in this case the code, which is *not* operating at the C API level, does not belong in OS.

Finally, I'm still against shutil.open as the name. It does not suggest to me that an application is being run. (Neither does 'startfile', by the way).

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 9:15 AM

Post #19 of 36 (258 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Sven Marnach <sven [at] marnach> added the comment:

The semantics of "associated application" change considerably from operating system to operating system. As an example, ``os.startfile("a.py")`` will usually run `a.py` in the Python interpreter, while ``xdg-open a.py`` it will usually open the source code in an editor on Linux. This might reduce the overall usefulness of the proposed ``shutil.launch()`` function.

----------
nosy: +smarnach

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 9:30 AM

Post #20 of 36 (259 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Éric Araujo <merwok [at] netwok> added the comment:

> The semantics of "associated application" change considerably from
> operating system to operating system. As an example,
> ``os.startfile("a.py")`` will usually run `a.py` in the Python
> interpreter, while ``xdg-open a.py`` it will usually open the source
> code in an editor on Linux.

Outch. I think the behavior should be more similar than that, i.e. that the function should use startfile with the edit action on Windows.

About the name: I thought about “edit”; it really means open_file_in_editor. BTW shutil feels the wrong place for this but I don’t think we have anything better.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 9:34 AM

Post #21 of 36 (257 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Hobs <hobsonlane [at] gmail> added the comment:

Last patch was invalid and untested.

New patch passes `make patchtest`, but still doing the full test suite on Windows and Linux.

Still unsure if I raised the right exceptions with the right arguments.

----------
Added file: http://bugs.python.org/file25317/shutil_open.patch

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 10:35 AM

Post #22 of 36 (258 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Hobs <hobsonlane [at] gmail> added the comment:

I'll be happy to code, test, and use the new ____.____() function wherever it ends up and whatever it is named... but...

> Initially this issue was about implementing a startfile-equivalent on
> posix. But if you have to add a gui option to startfile to not lanuch > a GUI, and your real goal is a consistent way to launch non-gui
> programs on posix

Actually, my real goal was a consistent way of launching any editor or viewer (or even interpreter) on any platform with graceful fallback from the caller's preferred action to the others. I wanted my application that called the new idiomatic standard library function to do something smarter (in my mind) than what OSes do by default and more consistent and robust than what hg and bzr do by design. Perhaps the fallback should only be within the read/write/execute "silos", but that should be configurable as well, defaulting to do the safe thing (fallback within editors or within viewers only).

GUI viewer (IE, then Firefox, then Chrome, then Safari)
GUI editor (notepad, then ...)
shell editor ($EDITOR, then vim, then vi, then nano, etc)
shell viewer (less, then more, then cat)

Obviously this isn't feasible. At least not for my first patch.

----------
Added file: http://bugs.python.org/file25319/shutil_open.patch

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 10:53 AM

Post #23 of 36 (259 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Chris Rebert <pybugs [at] rebertia> added the comment:

>> ENOSYS was the closest approximation I could find. Thoughts? Custom
>> error class? Different errno? Something else?
>
> Why not ValueError?

Because the value they provided was perfectly valid (the file/directory *did* exist), so the caller's request was reasonable. It's the system(/ its (lack of) configuration) that failed the caller in finding an opener application. The "fix" after encountering the exception is to add an association to the system configuration (and/or install a new application), not to pass a different path to the function.

IMO, it feels like an EnvironmentError or RuntimeError of some sort; hence the current use of OSError.
(Or NotImplementedError, but we're already using that exception to indicate a different failure condition, so that's out.)

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 10:58 AM

Post #24 of 36 (258 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Chris Rebert <pybugs [at] rebertia> added the comment:

Hobs, why is exit code 4 of xdg-open (which the manpage describes as the extremely generic "The action failed.") interpreted as FileNotFoundError in your new version?

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 11:05 AM

Post #25 of 36 (260 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Hobs <hobsonlane [at] gmail> added the comment:

Because that's how I caused the exception in
Ubuntu--shutil.launch('file_that_doesnt_exist'). That's why I changed the
message to "file may not exist" for both 2 and 4, but should probably prove
that 2 sometimes happens when the file does exist (like with permission or
visiblity/hidden errors in some OSes).

Interestingly I got it to quietly, insidiously fail on Ubuntu by passing it
a path to an empty file named empty.exe with the executeable bit set (but
permissions and executable bit didn't seem to make a difference). No app
was launched (or too quickly disappeared for me to see) and shutil.launch()
did not complain.

On Tue, Apr 24, 2012 at 1:58 AM, Chris Rebert <report [at] bugs>wrote:

>
> Chris Rebert <pybugs [at] rebertia> added the comment:
>
> Hobs, why is exit code 4 of xdg-open (which the manpage describes as the
> extremely generic "The action failed.") interpreted as FileNotFoundError in
> your new version?
>
> ----------
>
> _______________________________________
> Python tracker <report [at] bugs>
> <http://bugs.python.org/issue3177>
> _______________________________________
>

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 11:09 AM

Post #26 of 36 (173 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Chris Rebert <pybugs [at] rebertia> added the comment:

Also:

The FileNotFoundErrors quote the path twice:
Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53)
>>> path = "/foo/bar"
>>> print "Path '%s' may not exist" % repr(path)
Path ''/foo/bar'' may not exist

The ValueError error message isn't grammatically correct and doesn't account for the possibility that the path is a directory (consider the case of a Unix system where the GUI file manager has been uninstalled; directories would then fail to open). May I suggest my original message?: "No application is associated with files/directories of the given type"

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 11:21 AM

Post #27 of 36 (173 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Chris Rebert <pybugs [at] rebertia> added the comment:

The xdg-open source code (http://cgit.freedesktop.org/xdg/xdg-utils/tree/scripts/xdg-open ) shows that exit code 4 is used whenever an invocation of another opener script (e.g. kde-open, gnome-open) fails for any reason besides said script not being installed. So I'm not so sure we can jump to the conclusion that 4 automatically means FileNotFound.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 11:33 AM

Post #28 of 36 (172 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Hobs <hobsonlane [at] gmail> added the comment:

Yea, I hosed up the path quoting in a misguided attempt at shortening for
80-col line-wrapping. Yours is better, will revert.

On Tue, Apr 24, 2012 at 2:09 AM, Chris Rebert <report [at] bugs>wrote:

>
> Chris Rebert <pybugs [at] rebertia> added the comment:
>
> Also:
>
> The FileNotFoundErrors quote the path twice:
> Python 2.7.1 (r271:86832, Jul 31 2011, 19:30:53)
> >>> path = "/foo/bar"
> >>> print "Path '%s' may not exist" % repr(path)
> Path ''/foo/bar'' may not exist
>
> The ValueError error message isn't grammatically correct and doesn't
> account for the possibility that the path is a directory (consider the case
> of a Unix system where the GUI file manager has been uninstalled;
> directories would then fail to open). May I suggest my original message?:
> "No application is associated with files/directories of the given type"
>
> ----------
>
> _______________________________________
> Python tracker <report [at] bugs>
> <http://bugs.python.org/issue3177>
> _______________________________________
>

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 11:45 AM

Post #29 of 36 (172 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Chris Rebert <pybugs [at] rebertia> added the comment:

>> The semantics of "associated application" change considerably from
>> operating system to operating system. As an example,
>> ``os.startfile("a.py")`` will usually run `a.py` in the Python
>> interpreter, while ``xdg-open a.py`` it will usually open the source
>> code in an editor on Linux.
>
> Outch. I think the behavior should be more similar than that, i.e. that the function should use startfile with the edit action on Windows.

It's a universal problem on all 3 platforms. Given a script file argument, a generic "open" (as opposed to "edit") procedure will either run the script or open it in an editor, depending entirely upon the user's system configuration. Same thing happens when double-clicking a script in the file manager, which is IMO what we're trying to emulate here.

It sounds like some people want a generic "(text) edit" procedure, which IMO is different enough to warrant a separate bug since there are different/more design issues to tackle (e.g. if someone edit()s an image file (or a file of uncertain type) on Unix, what application is opened, and how is that determined?). And no peeking at Mercurial's code; it's under GPLv2, whereas Python is under BSD/MIT-like licensing, making them incompatible.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 12:37 PM

Post #30 of 36 (173 views)
Permalink
[issue3177] Add shutil.open [In reply to]

R. David Murray <rdmurray [at] bitdance> added the comment:

I'm not a lawyer (duh), but my understanding is that *looking* at GPL code (as opposed to proprietary code, where someone might sue you about it and not looking is a good defense) is OK, you just can't copy it.

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 12:47 PM

Post #31 of 36 (174 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Antoine Pitrou <pitrou [at] free> added the comment:

> I'm not a lawyer (duh), but my understanding is that *looking* at GPL
> code (as opposed to proprietary code, where someone might sue you
> about it and not looking is a good defense) is OK, you just can't copy
> it.

You could probably copy a one- or two-liner, especially if it's not a
very creative one.
By that I mean that putting "i = i + 1" under the GPL is not enough to
prevent anyone else to write the same line of code :-)

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 2:12 PM

Post #32 of 36 (178 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Changes by STINNER Victor <victor.stinner [at] gmail>:


----------
nosy: -haypo

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 23, 2012, 4:53 PM

Post #33 of 36 (171 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Changes by Chris Rebert <pybugs [at] rebertia>:


Added file: http://bugs.python.org/file25332/shutil_open.patch

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 24, 2012, 12:14 AM

Post #34 of 36 (176 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Hobs <hobsonlane [at] gmail> added the comment:

I can see why this partial implementation of `operation` in this ver seems
useless. But it is a placeholder for eventually providing Linux/Mac users
with the same functionality as windows. The os.startfile() or
shutil.launch() function can easily fill the gap left by the OS, which is
what os does for lots of other missing OS features on one platform or
another.

I'll delete the OS9 ('mac') test comment and leave an implementation for
those platforms up to others?

`gui` is for software that intends to launch user's $EDITOR, vi, nano,
emacs, etc. This is intended to generalize startfile to encompass a common
pattern, e.g. in bzr, hg. Perhaps it doesn't belong in ver1 until we sort
out all the other uncomfortable things about this patch.

I'll test all the windows and linux exception possabilities and get back to
you on what exceptions startfile() normally raises, and whether this
implementation of shutil.launch() raises comparable exceptions.

Cheers,
H
On Apr 23, 2012 7:53 PM, "Chris Rebert" <report [at] bugs> wrote:

>
> Chris Rebert <pybugs [at] rebertia> added the comment:
>
> `operation` seems questionable. IMO, the verbs seem stronger / more
> important than mere optional suggestions (particularly "open" vs. "edit"
> for files with read-only viewers), and only Windows supports them (so
> anyone requiring that feature might as well just use startfile() directly).
> By virtue of this function being cross-platform, we're kinda limited to
> just supporting the lowest common denominator.
>
> Hobs, can you explain `gui`?
>
> Also, does startfile() raise exceptions for either of the basic error
> conditions ("no such file" and "no associated application")? If not, I
> believe using the lower-level ShellExecute (
> http://msdn.microsoft.com/en-us/library/windows/desktop/bb762153%28v=vs.85%29.aspx) or similar Windows API function would allow us to report such errors, as
> the other platform implementations currently do.
>
> ----------
>
> _______________________________________
> Python tracker <report [at] bugs>
> <http://bugs.python.org/issue3177>
> _______________________________________
>

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 27, 2012, 3:54 PM

Post #35 of 36 (172 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Miki Tebeka <miki.tebeka [at] gmail> added the comment:

Just to note there's http://pypi.python.org/pypi/desktop/0.4 out there.

----------
nosy: +tebeka

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com


report at bugs

Apr 27, 2012, 5:15 PM

Post #36 of 36 (172 views)
Permalink
[issue3177] Add shutil.open [In reply to]

Hobs <hobsonlane [at] gmail> added the comment:

Had no idea. Sounds like a good place for it.
On Apr 28, 2012 6:54 AM, "Miki Tebeka" <report [at] bugs> wrote:

>
> Miki Tebeka <miki.tebeka [at] gmail> added the comment:
>
> Just to note there's http://pypi.python.org/pypi/desktop/0.4 out there.
>
> ----------
> nosy: +tebeka
>
> _______________________________________
> Python tracker <report [at] bugs>
> <http://bugs.python.org/issue3177>
> _______________________________________
>

----------

_______________________________________
Python tracker <report [at] bugs>
<http://bugs.python.org/issue3177>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/list-python-bugs%40lists.gossamer-threads.com

Python bugs RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.