This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Hobson.Lane
Recipients Arfrever, Hobson.Lane, Roman.Evstifeev, benjamin.peterson, cvrebert, eric.araujo, ganadist, giampaolo.rodola, pitrou, r.david.murray, rosslagerwall, vstinner
Date 2012-04-23.15:52:08
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CACZ_DofbH4fRbTz5=0VeDczMwp7NxrL8S7=kfhZm8qR3ijT9hg@mail.gmail.com>
In-reply-to <1335189519.14.0.0959687899532.issue3177@psf.upfronthosting.co.za>
Content
@É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@bugs.python.org> wrote:

>
> Éric Araujo <merwok@netwok.org> 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@python.org 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@bugs.python.org>
> <http://bugs.python.org/issue3177>
> _______________________________________
>
History
Date User Action Args
2012-04-23 15:52:10Hobson.Lanesetrecipients: + Hobson.Lane, pitrou, vstinner, giampaolo.rodola, benjamin.peterson, eric.araujo, ganadist, Arfrever, r.david.murray, cvrebert, rosslagerwall, Roman.Evstifeev
2012-04-23 15:52:09Hobson.Lanelinkissue3177 messages
2012-04-23 15:52:08Hobson.Lanecreate