[issue38568] [3.7.5 x86_64 Linux] f-string parsing results in EOL
Hobs added the comment:
It is a limitation of f-strings, though. We're not allowed to use
backslashes within the f-string expression in curly braces. So to do what
you want you have to create another variable containing the quote character:
```
>>> blah = '"hi"'
>>> blah
'"hi"'
>>> q = '"'
>>> f'{blah.strip(q)}'
'hi'
```
--Hobson
On Wed, Oct 23, 2019 at 12:21 PM Hobson Lane wrote:
> Not a bug. If you use quotes inside an f-string (or any other kind of
> string) they need to be escaped.
> --Hobson
>
>
> On Wed, Oct 23, 2019 at 12:09 PM Ying Wang wrote:
>
>>
>> New submission from Ying Wang :
>>
>> Hey,
>>
>> I encountered an interesting bug when trying to do string parsing using
>> f-strings. I am currently under the impression that within the curly braces
>> is any expression that can be successfully evaluated in a REPL. Here's the
>> error:
>>
>> ```bash
>> yingw787@yingw787-Oryx-Pro:~/src/gpudb-dev-v6.2.0/kio/kio/tests/regression/_data/csv$
>> python
>> Python 3.7.5 (default, Oct 15 2019, 21:38:37)
>> [GCC 5.4.0 20160609] on linux
>> Type "help", "copyright", "credits" or "license" for more information.
>> >>> blah = '"hi"'
>> >>> blah
>> '"hi"'
>> >>> f'{blah.strip('"')}'
>> File "", line 1
>> f'{blah.strip('"')}'
>>^
>> SyntaxError: EOL while scanning string literal
>> >>> '{0}'.format(blah.strip('"'))
>> 'hi'
>> >>>
>> ```
>>
>> I can use '.format()' for now, but it might be nice to align f-string
>> expr behavior w/ .format(). Please let me know if you need more
>> reproduction steps, or if you need a helping hand :)
>>
>> Thanks
>> Ying
>>
>> --
>> components: Interpreter Core
>> messages: 355254
>> nosy: yingw787
>> priority: normal
>> severity: normal
>> status: open
>> title: [3.7.5 x86_64 Linux] f-string parsing results in EOL
>> type: behavior
>> versions: Python 3.7
>>
>> ___
>> Python tracker
>> <https://bugs.python.org/issue38568>
>> ___
>> ___
>> New-bugs-announce mailing list
>> new-bugs-annou...@python.org
>> https://mail.python.org/mailman/listinfo/new-bugs-announce
>>
>
--
___
Python tracker
<https://bugs.python.org/issue38568>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38568] [3.7.5 x86_64 Linux] f-string parsing results in EOL
Hobs added the comment:
Not a bug. If you use quotes inside an f-string (or any other kind of
string) they need to be escaped.
--Hobson
On Wed, Oct 23, 2019 at 12:09 PM Ying Wang wrote:
>
> New submission from Ying Wang :
>
> Hey,
>
> I encountered an interesting bug when trying to do string parsing using
> f-strings. I am currently under the impression that within the curly braces
> is any expression that can be successfully evaluated in a REPL. Here's the
> error:
>
> ```bash
> yingw787@yingw787-Oryx-Pro:~/src/gpudb-dev-v6.2.0/kio/kio/tests/regression/_data/csv$
> python
> Python 3.7.5 (default, Oct 15 2019, 21:38:37)
> [GCC 5.4.0 20160609] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> blah = '"hi"'
> >>> blah
> '"hi"'
> >>> f'{blah.strip('"')}'
> File "", line 1
> f'{blah.strip('"')}'
>^
> SyntaxError: EOL while scanning string literal
> >>> '{0}'.format(blah.strip('"'))
> 'hi'
> >>>
> ```
>
> I can use '.format()' for now, but it might be nice to align f-string expr
> behavior w/ .format(). Please let me know if you need more reproduction
> steps, or if you need a helping hand :)
>
> Thanks
> Ying
>
> --
> components: Interpreter Core
> messages: 355254
> nosy: yingw787
> priority: normal
> severity: normal
> status: open
> title: [3.7.5 x86_64 Linux] f-string parsing results in EOL
> type: behavior
> versions: Python 3.7
>
> ___
> Python tracker
> <https://bugs.python.org/issue38568>
> ___
> ___
> New-bugs-announce mailing list
> new-bugs-annou...@python.org
> https://mail.python.org/mailman/listinfo/new-bugs-announce
>
--
nosy: +Hobson.Lane
___
Python tracker
<https://bugs.python.org/issue38568>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34896] Unable to install Python 3.5
Hobs added the comment: I'd suggest using Anaconda to install python and all python packages that you need. Once you have Anaconda installed you can type `conda install django` and that should work. Also I'd suggest sticking with the lastest version of python (3.7) that installs with anaconda rather than using python 3.5. Django (and other packages) may not be compatible with python 3.5. --Hobson On Thu, Oct 4, 2018 at 9:52 AM Ruchir Jha wrote: > > New submission from Ruchir Jha : > > Hi, I was trying to install Danjo to work on Python. However it was not > working fine hence I uninstalled the version 3.5 which I installed and > tried to install it again as the earlier version was used for Anaconda. > However even after multiple attempts to install Python its throws and error > 0x80070643 fatal error during python installation. I have restarted the > system and have also cleared the cache. I am working under strict deaadline > hence an urgent help will be highly appreciated > > -- > components: Installation > files: Python 3.5.0rc3 (64-bit)_20181004220550_000_core_JustForMe.log > messages: 327067 > nosy: ruchirjha > priority: normal > severity: normal > status: open > title: Unable to install Python 3.5 > type: crash > versions: Python 3.5 > Added file: https://bugs.python.org/file47849/Python 3.5.0rc3 > (64-bit)_20181004220550_000_core_JustForMe.log > > ___ > Python tracker > <https://bugs.python.org/issue34896> > ___ > ___ > New-bugs-announce mailing list > new-bugs-annou...@python.org > https://mail.python.org/mailman/listinfo/new-bugs-announce > -- nosy: +Hobson.Lane ___ Python tracker <https://bugs.python.org/issue34896> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23343] operator precedence table for `not x` has an operand, while the others do not
Hobs added the comment: Just noticed the other entries for not. Not a bug. -- resolution: -> not a bug status: open -> closed ___ Python tracker <http://bugs.python.org/issue23343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23343] operator precedence table for `not x` has an operand, while the others do not
New submission from Hobs: Shouldn't the [operator precedence table](https://docs.python.org/3.4/reference/expressions.html#operator-precedence), 5th row, 1st column, just say "`not`" rather than "`not` x"? The other rows are identified by the keyword for the operator and don't include any operand(s). Is there some other expression that includes `not` that should have a different position in the precedence table? -- assignee: docs@python components: Documentation messages: 234919 nosy: Hobson.Lane, docs@python priority: normal severity: normal status: open title: operator precedence table for `not x` has an operand, while the others do not type: enhancement versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue23343> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17057] Data model documentation grammar
New submission from Hobs: New-style and old-style class expalanation in the datamodel section has minor grammatical errors and one minor ambiguity that could be improved. http://docs.python.org/2/reference/datamodel.html#new-style-and-classic-classes * "independently of" should always be "indepenent of" * single hyphens (-) should be double-hyphens (--) for an m-dash * "flavour" should be "flavor" (used 100x more often in docs.python) * "only the symantics of..." is ambiguous. can't tell if 'only' modifies 'symantics' or 'new-style classes'? -- assignee: docs@python components: Documentation files: datamodel-reference-docs.patch keywords: patch messages: 180812 nosy: Hobson.Lane, docs@python priority: normal severity: normal status: open title: Data model documentation grammar type: enhancement versions: Python 2.7 Added file: http://bugs.python.org/file28876/datamodel-reference-docs.patch ___ Python tracker <http://bugs.python.org/issue17057> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11076] Iterable argparse Namespace
Hobs added the comment: Seems like a great idea. `foo(**dict(args))` is very useful. I tested `foo(**dict(iter(o.__dict__.items(` on python 2.7 Mac OSX for my foo and it worked well. -- nosy: +Hobson.Lane ___ Python tracker <http://bugs.python.org/issue11076> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3177] Add shutil.open
Hobs added the comment: shutil.whatever with os.startfile(..., 'edit'). That's why I thought an 'auto' option might be useful--to allow the caller to indicate that they want to respect the OS settings for open/run, if possible. -- ___ Python tracker <http://bugs.python.org/issue3177> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3177] Add shutil.open
Hobs added the comment: Then they or we can add Konqueror, etc to the options that are 'try'ed for the 'view' option. Worst case they get a terminal cat of the file instead of an error message or unintended action (like running a script). What exactly are you proposing to do when execute is False? That's exactly what the augmented launch function would do when the "open" or "view" option is chosen. Anything else for the other options like "edit" or "email" is just gravy (for application developers targeting the 90% of platforms that we could easily anticipate). Gnome/KDE Xdg-open, Android "Share", Windows Open, already do implement more than we need. Like your "execute" flag, I'm suggesting we bypass all that unpredictable open() stuff and allow the application developer to chose what happens when they launch a file. It would allow the app developer to stay out of the tug-of war between PC manufacturers, OS manufacturers, and Internet service providers trying to set "preferred applications" and steering customers to their products. But clearly you have passion for the boolean execute flag, and you probably have more experience with python standard libraries than I do, so go for it. I like your "execute" option. Just thought you'd like to extend it to include other options. I'm happy with my cross-platform home-rolled launch() function for my apps that can't afford to leave launch() actions up to chance. On Sat, May 26, 2012 at 4:00 PM, Larry Hastings wrote: > > Larry Hastings added the comment: > > > In Linux we could `try` nautilus then Mozilla > > (file://.../containing_folder) then fall back to a shell > > `cd && ls` if no browser is available, raising NotImplemented > > if all else fails... until someone implements for that > > user's platform particulars. > > Designing a cross-platform API based on abilities provided by only one of > those platforms, then waiving your hand and saying , is poor cross-platform > API design. OS X is 11 years old, GNOME is 13, KDE is 16, and none of the > above appear to be in a hurry to add this feature. And even on Windows, > which has had this feature for 17 years (IIRC it was introduced with > Windows 95)... it is hardly ever used. 99.999% of the time you simply want > to "open" the file using the user's preferred app. > > Since Windows users already have an API to access this extra functionality > on their platform (os.startfile) I assert that the cross-platform API > should only expose the functionality that's available across platforms. > Hence my proposal for "execute". > > -- > > ___ > Python tracker > <http://bugs.python.org/issue3177> > ___ > -- ___ Python tracker <http://bugs.python.org/issue3177> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3177] Add shutil.open
Hobs added the comment: In Linux we could `try` nautilus then Mozilla (file://.../containing_folder) then fall back to a shell `cd && ls` if no browser is available, raising NotImplemented if all else fails... until someone implements for that user's platform particulars. Likewise on OSX, Mac, even iOS, Android, etc. That way the API remains fixed and implementation can mature without breaking it, as people think of or develop new cross-platform actions that you and I can't even dream of now. A boolean `execute` flag is unnecessarily specialized (not generalized or flexible). --Hobson On May 25, 2012 5:08 PM, "Larry Hastings" wrote: > > Larry Hastings added the comment: > > > Could even add an `operation` parameter to let the caller > > select actions, > > [...] > > operation in ['auto', 'run', 'edit', 'display', 'browse', > > 'explore', 'share', 'send', 'like', 'email', 'open', 'xdg-open', > > ...] # can be incrementally added/implemented > > IIRC ShellExecute on Windows has support for verbs like this. But how > would we implement support for "explore" / "share" / "send" / "like" on Mac > OS X and Linux? > > The only flag I can think of supporting in a cross-platform way would be > "execute=True", which on Windows would mean try the verb "run" before > trying the default, and on OS X and Linux would mean look for the execute > bit / the "#!" signature and run it if possible first before using > "xdg-open". > > -- > > ___ > Python tracker > <http://bugs.python.org/issue3177> > ___ > -- ___ Python tracker <http://bugs.python.org/issue3177> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3177] Add shutil.open
Hobs added the comment:
Could even add an `operation` parameter to let the caller select actions,
including 'auto' implemented as Larry suggests. Sometimes you feel like
trusting the user's xdg-open preferences/settings. Sometimes you don't.
Easy enough to let the caller choose, rather than the OS.
operation in ['auto', 'run', 'edit', 'display', 'browse', 'explore',
'share', 'send', 'like', 'email', 'open', 'xdg-open', ...] # can
be incrementally added/implemented
Each op requires 1 conditional and gives a lot more utility without
requiring much more launch/action code that hasn't already been
tested/debugged on all relevant platforms. And the `operation` parameter is
a semi-standard used by MS, easing the transition for Win-devs migrating
gui code to python and linux (or cross-platform implementations).
On Fri, May 25, 2012 at 4:40 AM, Larry Hastings wrote:
>
> Larry Hastings added the comment:
>
> > 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.
>
> Well, so how about on UNIX shutil.launch (or whatever it's called) first
> checks to see if we're referring to a file. If we are, check to see if
> it's marked executable. If it is, execute it under a shell. Failing
> *that* we could run xdg-open where available.
>
> --
> nosy: +larry
>
> ___
> Python tracker
> <http://bugs.python.org/issue3177>
> ___
>
--
___
Python tracker
<http://bugs.python.org/issue3177>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3177] Add shutil.open
Hobs added the comment: Had no idea. Sounds like a good place for it. On Apr 28, 2012 6:54 AM, "Miki Tebeka" wrote: > > Miki Tebeka added the comment: > > Just to note there's http://pypi.python.org/pypi/desktop/0.4 out there. > > -- > nosy: +tebeka > > ___ > Python tracker > <http://bugs.python.org/issue3177> > ___ > -- ___ Python tracker <http://bugs.python.org/issue3177> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3177] Add shutil.open
Hobs 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" wrote:
>
> Chris Rebert 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
> <http://bugs.python.org/issue3177>
> ___
>
--
___
Python tracker
<http://bugs.python.org/issue3177>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3177] Add shutil.open
Hobs 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 wrote: > > Chris Rebert 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 > <http://bugs.python.org/issue3177> > ___ > -- ___ Python tracker <http://bugs.python.org/issue3177> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3177] Add shutil.open
Hobs 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 wrote:
>
> Chris Rebert 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
> <http://bugs.python.org/issue3177>
> ___
>
--
___
Python tracker
<http://bugs.python.org/issue3177>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14650] 1-character typo in shutil docstring
Hobs added the comment: Eric, the documentation (shutil.rst) looks fine. Just a code comment typo. -- ___ Python tracker <http://bugs.python.org/issue14650> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3177] Add shutil.open
Hobs 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 <http://bugs.python.org/issue3177> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3177] Add shutil.open
Hobs 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 <http://bugs.python.org/issue3177> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3177] Add shutil.open
Hobs 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 <http://bugs.python.org/issue3177> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue14650] 1-character typo in shutils doctext
New submission from Hobs : This patch fixes a 1-character typo in the docstring for shutil.disk_usage(). -- assignee: docs@python components: Documentation files: shutil_disk_usage_doc.patch keywords: patch messages: 159035 nosy: Hobson.Lane, docs@python, eric.araujo priority: normal severity: normal status: open title: 1-character typo in shutils doctext type: enhancement versions: Python 3.3 Added file: http://bugs.python.org/file25314/shutil_disk_usage_doc.patch ___ Python tracker <http://bugs.python.org/issue14650> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3177] Add shutil.open
Hobs 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 wrote: > > Éric Araujo 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 > d...@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 > <http://bugs.python.org/issue3177> > ___ > -- ___ Python tracker <http://bugs.python.org/issue3177> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3177] Add shutil.open
Hobs 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 wrote: > > R. David Murray 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 > <http://bugs.python.org/issue3177> > ___ > -- ___ Python tracker <http://bugs.python.org/issue3177> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3177] Add shutil.open
Hobs 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 <http://bugs.python.org/issue3177> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3177] Add shutil.open
Hobs 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 <http://bugs.python.org/issue3177> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3177] Add shutil.open
Hobs 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 <http://bugs.python.org/issue3177> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
