Off topic: 'strike a balance' - second language English
Summary: I look at the phrase 'strike a balance' in different languages, and rewrite some wikipedia text on accessibility. I found in https://en.wikipedia.org/wiki/Jargon#Accessibility_issues === There is a balance to be struck, as excessive removal of technical terminology from a document leads to an equally undesirable outcome—dumbing down. === Aside: Found while writing https://mail.python.org/pipermail/python-ideas/2018-August/052819.html. I wondered how the phrase 'strike a balance' would translate into other languages (which is an accessibility issue). Using google translate I did round-tripping and other loops. (Simply curiosity driven, no agenda.) === en: strike a balance fr: trouver un équilibre en: find a balance de: finde ein Gleichgewicht arabic: العثور على التوازن en: Find balance fi: Etsi tasapaino en: Find the balance de: Finde das Gleichgewicht === en: strike a balance al: të krijojë një ekuilibër en: create a balance basque: oreka sortu en: create balance ===
So what's good, when English is the reader's second (or third) language? Surely, here, it's best not to use the word 'strike'. (In English 'strike out' means 'remove', not 'find'.) To try this out, let's rewrite: === There is a balance to be struck, as excessive removal of technical terminology from a document leads to an equally undesirable outcome—dumbing down. == How about === There is a balance to be found [or made] ... === Or we could use 'balance' as a verb (rather than as a noun). === It can be hard to balance removal of technical terminology against retaining essential meaning. === Or even not use the word 'balance' === Harmony between removal of technical terminology and retaining essential meaning can be hard. === Which is the best way to write the sentence, for a second-language English speaker? English is my first (and by far best) language. So I lack the experience, to make a good judgement. However, as an English speaker, I prefer the last
Harmony between removal of technical terminology and retaining essential meaning can be hard.
By the way: the rewriting has changed the meaning. For this, how about
Removal of technical terminology may also remove essential meaning.
-- Jonathan
On 18/08/2018 10:34, Jonathan Fine wrote:
Jonathan, It is interesting that you picked up on "strike a balance" which has been a standard English phrase for a very long time rather than the much more resent, (and itself a form of jargon), "dumbing down". The other point is that the use of Jargon is often as a form of shorthand so as to avoid excessive verbosity, (or long windedness). So I would be tempted to go with something like: "The removal of technical terminology needs to be moderated to account for the risk of loss of the essential meaning or the meaning being lost due to excessive length. Where such terminology is widely accepted within a given specialisation it should be considered acceptable but should, ideally, be defined on first usage or with a cross reference to a definition." -- Steve (Gadget) Barnes Any opinions in this message are my personal opinions and do not reflect those of my employer. --- This email has been checked for viruses by AVG. https://www.avg.com
I would consider conciseness and accuracy most important. Using jargon but linking to accurate explanations would, in my not exactly humble opinion, be the best way to go about it.
We are (maybe) mingling two issues here -- there is an important distinction between idiomatic expressions ("striking a balance", "dumbing down") and technical terms (jargon). If you want to make it easier for non-native english speakers to understand -- minimal use of idiomatic expressions is a good idea. They really don't serve much real purpose, other than making the prose more colorful and friendly (to those that understand it). Sometimes a bit of brevity is gained, but not much. Technical jargon, on the other hand, can be very helpful for precision and compactness. (side note -- are all domain-specific technical term "jargon"? I tend to see "jargon" as having a negative connotation -- specifically that it isn't required for technical specificity. That is, "jargon" is language that is unnecessarily domain specific) I think it's pretty important to use the common domain specific terms in introductory texts -- how else will folks learn them? So I make a distinction between *using* a technical term, and *introducing* a technical term. In fact, in my PR on Jonathan's doc on None, I deliberately introduced the term "Singleton" -- not because it was necessary to understand the idea at hand, but because people are likely to encounter the term elsewhere. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
The technical writing course I went on as an engineer years ago recommenced "Controlled English" in documentation. Its good for none english speakers and the lack of colloquial expression means English speaks are not miss lead. As you say this is nothing to do with jargon.
Technical jargon, on the other hand, can be very helpful for precision and compactness.
It also means you will understand other people doing the same activity. Be they musicians or programmers.
(side note -- are all domain-specific technical term "jargon"? I tend to see "jargon" as having a negative connotation -- specifically that it isn't required for technical specificity. That is, "jargon" is language that is unnecessarily domain specific)
I found this definition: "Jargon. A special language belonging exclusively to a group, often a profession. Engineers, lawyers, doctors, tax analysts, and the like all use jargon to exchange complex information efficiently. Jargon is often unintelligible to those outside the group that uses it." Not all group members remember to avoid jargon when talking to people outside the group. If you are on the outside looking in at the people that will not explain in plain english you could well consider jargon as a bad thing.
I think it's pretty important to use the common domain specific terms in introductory texts -- how else will folks learn them? So I make a distinction between *using* a technical term, and *introducing* a technical term.
Yes.
In fact, in my PR on Jonathan's doc on None, I deliberately introduced the term "Singleton" -- not because it was necessary to understand the idea at hand, but because people are likely to encounter the term elsewhere.
Barry
On 8/20/2018 5:13 PM, Barry Scott wrote:
To me, 'jargon' refers more to in-group replacements for common words (slang) than to technical terms. 'Hack the bug' for 'Fix the program error' is an example of the former. 'Use a coroutine' uses a technical term that needs several sentences and some preliminary knowledge about functions to explain. In any case, docs should avoid slangy jargon and explain technical terms.
-- Terry Jan Reedy
Hi Earlier today, I did a search for 'documentation by example python' and found Example of great documentation in Python: Nick Loadholtes (copied) https://ironboundsoftware.com/blog/2017/12/11/great-documentation-python/ The example is: https://docs.python.org/3/library/random.html#examples-and-recipes So who to thank: Here's the history of the source for the doc page. https://github.com/python/cpython/commits/3.7/Doc/library/random.rst I don't have time right now to look at all the history. But most of the recent commits are from Raymond Hettinger. I'll give Nick's web page the last word. <conclusion> Make your docs work as hard as your code does. Clear examples will make your code stand out in a good way. Great documentation is out there, lets make more of it. Here’s what you need to create: * A plain language explanation of what your library does * The shortest possible code example * A quick list of any common issues * Links to where you can learn more details If you can create that for your code, you are doing a great service to us all. </conclusion> -- Jonathan
Nick Loadholtes wrote (elsewhere, quoted in this thread - by me).
Make your docs work as hard as your code does. Clear examples will make your code stand out in a good way.
With a bit more searching I found: <quote> https://www.reddit.com/r/Python/comments/70myto/whats_new_in_python_37_pytho... I'll disagree. Nothing is better than Mathworks documentation. I like documentation by example. Python gives you the dry, technically correct verbiage behind how something works. Matlab says: "Here, copy paste this and it'll work". To the point that the workspace is designed to automatically strip >>> from any copy and pasted commands. Even with most Python examples you can't just copy and paste a chunk of an example from the web or documentation because you need to clean off >>> first. </quote> It did me good, to read the resulting discussion on reddit. -- Jonathan
On 21/08/2018 17:55, Jonathan Fine wrote:
I would just like to point out that the ipython %paste magic very handily strips leading >, ... & + characters from the pasted block, (there is also some clever dedenting done). So taking the example code:
on the clipboard and in ipython entering %paste results in: In [2]: %paste
## -- End pasted text -- 6 Which is ideal. I personally find that many beginners get on a lot better in the iPython console than in the python one. -- Steve (Gadget) Barnes Any opinions in this message are my personal opinions and do not reflect those of my employer. --- This email has been checked for viruses by AVG. https://www.avg.com
Hi Steve You wrote:
[useful example, snipped]
Which is ideal. I personally find that many beginners get on a lot better in the iPython console than in the python one.
Thank you very much for this. I didn't know about this solution to the problem. Docs search for ipython brings up <quote> https://docs.python.org/3/tutorial/interactive.html One alternative enhanced interactive interpreter that has been around for quite some time is IPython, which features tab completion, object exploration and advanced history management. It can also be thoroughly customized and embedded into other applications. Another similar enhanced interactive environment is bpython. </quote> I've now played a little with (both look nice):
https://www.bpython-interpreter.org https://repl.it/repls/LightcoralMoralDistributedcomputing
Perhaps beginners would benefit from something better than the default, but simpler than ipython. But I don't have any experience to support this view. There's related prior art in the well-regarded https://codewith.mu/en/about. (Steve, I'd welcome your comments on this.) So thank you for bringing iPython's nifty %paste trick to my (and the thread's) attention. -- Jonathan
Chris Angelico wrote
Good question. The reddit user wrote. <quote> https://www.reddit.com/r/Python/comments/70myto/whats_new_in_python_37_pytho... Take this example for re.sub. [https://docs.python.org/3/library/re.html#re.sub] Trying that out requires 3 separate copy and pastes just to do one example. Or you have to put it in an intermediate file, clean it up then paste it in. The examples are also grouped by sub function not by what they do. </quote> I think the problem is the user didn't see the [>>>] toggle at the top right of the code block. I know I didn't just now, when I tried it just now. It was only the strength of your assertion, Chris, that made me go back and try again. <quote> https://docs.python.org/3/tutorial/introduction.html In the following examples, input and output are distinguished by the presence or absence of prompts (>>> and …): to repeat the example, you must type everything after the prompt, when the prompt appears; lines that do not begin with a prompt are output from the interpreter. Note that a secondary prompt on a line by itself in an example means you must type a blank line; this is used to end a multi-line command. </quote> No mention here, or elsewhere on the page, that [>>>] at the top right of a code example toggles the presence or absence of prompts. -- Jonathan
I wrote:
No mention here, or elsewhere on the page, that [>>>] at the top right of a code example toggles the presence or absence of prompts.
Now raised, and cross-referenced as an issue. https://bugs.python.org/issue34451 docs: tutorial/introduction doesn't mention toggle of prompts Perhaps discussion of this should move there. -- Jonathan
Hi Greg You (and a reddit user) wrote:
Matlab says: "Here, copy paste this and it'll work".
To the point that the workspace is designed to automatically strip >>> from any copy and pasted commands.
Maybe this is something Python's REPL should do?
Good idea. Maybe this is something that you (or someone else) should raise on bugs.python.org? And I expect that then, they'll ask for it to be discussed on python-ideas. So what do we get from the bounce? Well, you (or someone else) would be keeping an eye on this. (Aside: I'd like to be the someone else, but I don't have the time.). -- Jonathan
On Tue, Aug 21, 2018 at 3:07 PM, Jonathan Fine <jfine2358@gmail.com> wrote:
Maybe this is something Python's REPL should do?
Good idea.
I can't find (with very little effort) any documentation of this, but I have a vague recollection that the core devs want to keep the built-in REPL really simple -- more advanced features are for third party packages like iPython. I tend to agree -- while something like this: "making the built-in repl more friendly t copy-and-paste from examples" seems like a no brainer, the fact is that there are a LOT of features that would make it easier for newbies, and in the end, you'd end up with something like iPython. Honestly, Python does "suffer" a bit when in competition with commercial products, in that it is a language (and an implementation of that language), not an entire programming environment. So to use it, you need to figure out which Editor or IDE you want to use, what debugger, etc..... And the REPL, while being pretty key to interactive data analysis, is not a key feature of programming languages in general, even interpreted ones. So the solution is: use a third party solution for a complete environment suitable for your needs. For instance, for people doing data analysis, I recommend Anaconda -- then you get iPython and JUpyter (and Spyder) out of the box -- and away we go. maybe it's worth a note t pyton-dev to confirm my vague impression (or some more thorough googling for previous discussions) -- but I wouldn't put much effort into ideas for the REPL without confirming that the core dev are open to the concept. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Wed, 22 Aug 2018 09:38:57 -0700 Chris Barker via Python-ideas <python-ideas@python.org> wrote:
To me it sounds fine to improve the REPL. Especially, being able to paste examples without effort was a sore point for me until I finally switched to IPython. How much complexity and development work that would entail I don't know, though :-) Regards Antoine.
%edit -p
Bring up an editor and execute the resulting code.
-p: this will call the editor with the same data as the previous time it was used, regardless of how long ago (in your current session) it was.
https://ipython.readthedocs.io/en/stable/interactive/magics.html#magic-edit Something like this that calls $EDITOR with a temp file would be useful in the Python REPL as well. On Wednesday, August 22, 2018, Antoine Pitrou <solipsis@pitrou.net> wrote:
%doctest_mode works like the Python REPL (with '>>>' prompts and no pretty printing) https://ipython.readthedocs.io/en/stable/interactive/magics.html#magic-docte... On Wednesday, August 22, 2018, Wes Turner <wes.turner@gmail.com> wrote:
On Wed, Aug 22, 2018 at 06:01:05PM -0400, Wes Turner wrote:
%edit -p
Bring up an editor and execute the resulting code.
https://code.activestate.com/recipes/578926-call-out-to-an-external-editor/ -- Steve
On Wed, Aug 22, 2018 at 7:47 PM Mike Miller <python-ideas@mgmiller.net> wrote:
Happily, you know where to get IPython, and BPython, and PTPython. Different users have different desires for an enhanced REPL, and different good, free software, projects exist. I would tend to oppose most of these "fixes" to the basic Python REPL as "feature creep." Full featured interactive shells are great. I use IPython and Jupyter dozens of times every day myself. I love those. But they make specific decisions on what and how to enhance things, and have a huge range of configuration options. The `python` REPL should really be just good enough to use, and allow other projects to provide the richer experience (and to maintain all the code associated with making them powerful and flexible). Obviously, that's not saying categorically that "nothing can ever change" in the Python REPL. But most things I would lean against adding. It does basically as much as it should, with no more code than is necessary to do that. -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.
On Mon, Aug 20, 2018 at 09:07:20AM -0700, Chris Barker via Python-ideas wrote:
(side note -- are all domain-specific technical term "jargon"?
Yes. But not all jargon is a domain-specific technical term. https://en.wiktionary.org/wiki/jargon -- Steve
On 18/08/2018 10:34, Jonathan Fine wrote:
Jonathan, It is interesting that you picked up on "strike a balance" which has been a standard English phrase for a very long time rather than the much more resent, (and itself a form of jargon), "dumbing down". The other point is that the use of Jargon is often as a form of shorthand so as to avoid excessive verbosity, (or long windedness). So I would be tempted to go with something like: "The removal of technical terminology needs to be moderated to account for the risk of loss of the essential meaning or the meaning being lost due to excessive length. Where such terminology is widely accepted within a given specialisation it should be considered acceptable but should, ideally, be defined on first usage or with a cross reference to a definition." -- Steve (Gadget) Barnes Any opinions in this message are my personal opinions and do not reflect those of my employer. --- This email has been checked for viruses by AVG. https://www.avg.com
I would consider conciseness and accuracy most important. Using jargon but linking to accurate explanations would, in my not exactly humble opinion, be the best way to go about it.
We are (maybe) mingling two issues here -- there is an important distinction between idiomatic expressions ("striking a balance", "dumbing down") and technical terms (jargon). If you want to make it easier for non-native english speakers to understand -- minimal use of idiomatic expressions is a good idea. They really don't serve much real purpose, other than making the prose more colorful and friendly (to those that understand it). Sometimes a bit of brevity is gained, but not much. Technical jargon, on the other hand, can be very helpful for precision and compactness. (side note -- are all domain-specific technical term "jargon"? I tend to see "jargon" as having a negative connotation -- specifically that it isn't required for technical specificity. That is, "jargon" is language that is unnecessarily domain specific) I think it's pretty important to use the common domain specific terms in introductory texts -- how else will folks learn them? So I make a distinction between *using* a technical term, and *introducing* a technical term. In fact, in my PR on Jonathan's doc on None, I deliberately introduced the term "Singleton" -- not because it was necessary to understand the idea at hand, but because people are likely to encounter the term elsewhere. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
The technical writing course I went on as an engineer years ago recommenced "Controlled English" in documentation. Its good for none english speakers and the lack of colloquial expression means English speaks are not miss lead. As you say this is nothing to do with jargon.
Technical jargon, on the other hand, can be very helpful for precision and compactness.
It also means you will understand other people doing the same activity. Be they musicians or programmers.
(side note -- are all domain-specific technical term "jargon"? I tend to see "jargon" as having a negative connotation -- specifically that it isn't required for technical specificity. That is, "jargon" is language that is unnecessarily domain specific)
I found this definition: "Jargon. A special language belonging exclusively to a group, often a profession. Engineers, lawyers, doctors, tax analysts, and the like all use jargon to exchange complex information efficiently. Jargon is often unintelligible to those outside the group that uses it." Not all group members remember to avoid jargon when talking to people outside the group. If you are on the outside looking in at the people that will not explain in plain english you could well consider jargon as a bad thing.
I think it's pretty important to use the common domain specific terms in introductory texts -- how else will folks learn them? So I make a distinction between *using* a technical term, and *introducing* a technical term.
Yes.
In fact, in my PR on Jonathan's doc on None, I deliberately introduced the term "Singleton" -- not because it was necessary to understand the idea at hand, but because people are likely to encounter the term elsewhere.
Barry
On 8/20/2018 5:13 PM, Barry Scott wrote:
To me, 'jargon' refers more to in-group replacements for common words (slang) than to technical terms. 'Hack the bug' for 'Fix the program error' is an example of the former. 'Use a coroutine' uses a technical term that needs several sentences and some preliminary knowledge about functions to explain. In any case, docs should avoid slangy jargon and explain technical terms.
-- Terry Jan Reedy
Hi Earlier today, I did a search for 'documentation by example python' and found Example of great documentation in Python: Nick Loadholtes (copied) https://ironboundsoftware.com/blog/2017/12/11/great-documentation-python/ The example is: https://docs.python.org/3/library/random.html#examples-and-recipes So who to thank: Here's the history of the source for the doc page. https://github.com/python/cpython/commits/3.7/Doc/library/random.rst I don't have time right now to look at all the history. But most of the recent commits are from Raymond Hettinger. I'll give Nick's web page the last word. <conclusion> Make your docs work as hard as your code does. Clear examples will make your code stand out in a good way. Great documentation is out there, lets make more of it. Here’s what you need to create: * A plain language explanation of what your library does * The shortest possible code example * A quick list of any common issues * Links to where you can learn more details If you can create that for your code, you are doing a great service to us all. </conclusion> -- Jonathan
Nick Loadholtes wrote (elsewhere, quoted in this thread - by me).
Make your docs work as hard as your code does. Clear examples will make your code stand out in a good way.
With a bit more searching I found: <quote> https://www.reddit.com/r/Python/comments/70myto/whats_new_in_python_37_pytho... I'll disagree. Nothing is better than Mathworks documentation. I like documentation by example. Python gives you the dry, technically correct verbiage behind how something works. Matlab says: "Here, copy paste this and it'll work". To the point that the workspace is designed to automatically strip >>> from any copy and pasted commands. Even with most Python examples you can't just copy and paste a chunk of an example from the web or documentation because you need to clean off >>> first. </quote> It did me good, to read the resulting discussion on reddit. -- Jonathan
On 21/08/2018 17:55, Jonathan Fine wrote:
I would just like to point out that the ipython %paste magic very handily strips leading >, ... & + characters from the pasted block, (there is also some clever dedenting done). So taking the example code:
on the clipboard and in ipython entering %paste results in: In [2]: %paste
## -- End pasted text -- 6 Which is ideal. I personally find that many beginners get on a lot better in the iPython console than in the python one. -- Steve (Gadget) Barnes Any opinions in this message are my personal opinions and do not reflect those of my employer. --- This email has been checked for viruses by AVG. https://www.avg.com
Hi Steve You wrote:
[useful example, snipped]
Which is ideal. I personally find that many beginners get on a lot better in the iPython console than in the python one.
Thank you very much for this. I didn't know about this solution to the problem. Docs search for ipython brings up <quote> https://docs.python.org/3/tutorial/interactive.html One alternative enhanced interactive interpreter that has been around for quite some time is IPython, which features tab completion, object exploration and advanced history management. It can also be thoroughly customized and embedded into other applications. Another similar enhanced interactive environment is bpython. </quote> I've now played a little with (both look nice):
https://www.bpython-interpreter.org https://repl.it/repls/LightcoralMoralDistributedcomputing
Perhaps beginners would benefit from something better than the default, but simpler than ipython. But I don't have any experience to support this view. There's related prior art in the well-regarded https://codewith.mu/en/about. (Steve, I'd welcome your comments on this.) So thank you for bringing iPython's nifty %paste trick to my (and the thread's) attention. -- Jonathan
Chris Angelico wrote
Good question. The reddit user wrote. <quote> https://www.reddit.com/r/Python/comments/70myto/whats_new_in_python_37_pytho... Take this example for re.sub. [https://docs.python.org/3/library/re.html#re.sub] Trying that out requires 3 separate copy and pastes just to do one example. Or you have to put it in an intermediate file, clean it up then paste it in. The examples are also grouped by sub function not by what they do. </quote> I think the problem is the user didn't see the [>>>] toggle at the top right of the code block. I know I didn't just now, when I tried it just now. It was only the strength of your assertion, Chris, that made me go back and try again. <quote> https://docs.python.org/3/tutorial/introduction.html In the following examples, input and output are distinguished by the presence or absence of prompts (>>> and …): to repeat the example, you must type everything after the prompt, when the prompt appears; lines that do not begin with a prompt are output from the interpreter. Note that a secondary prompt on a line by itself in an example means you must type a blank line; this is used to end a multi-line command. </quote> No mention here, or elsewhere on the page, that [>>>] at the top right of a code example toggles the presence or absence of prompts. -- Jonathan
I wrote:
No mention here, or elsewhere on the page, that [>>>] at the top right of a code example toggles the presence or absence of prompts.
Now raised, and cross-referenced as an issue. https://bugs.python.org/issue34451 docs: tutorial/introduction doesn't mention toggle of prompts Perhaps discussion of this should move there. -- Jonathan
Hi Greg You (and a reddit user) wrote:
Matlab says: "Here, copy paste this and it'll work".
To the point that the workspace is designed to automatically strip >>> from any copy and pasted commands.
Maybe this is something Python's REPL should do?
Good idea. Maybe this is something that you (or someone else) should raise on bugs.python.org? And I expect that then, they'll ask for it to be discussed on python-ideas. So what do we get from the bounce? Well, you (or someone else) would be keeping an eye on this. (Aside: I'd like to be the someone else, but I don't have the time.). -- Jonathan
On Tue, Aug 21, 2018 at 3:07 PM, Jonathan Fine <jfine2358@gmail.com> wrote:
Maybe this is something Python's REPL should do?
Good idea.
I can't find (with very little effort) any documentation of this, but I have a vague recollection that the core devs want to keep the built-in REPL really simple -- more advanced features are for third party packages like iPython. I tend to agree -- while something like this: "making the built-in repl more friendly t copy-and-paste from examples" seems like a no brainer, the fact is that there are a LOT of features that would make it easier for newbies, and in the end, you'd end up with something like iPython. Honestly, Python does "suffer" a bit when in competition with commercial products, in that it is a language (and an implementation of that language), not an entire programming environment. So to use it, you need to figure out which Editor or IDE you want to use, what debugger, etc..... And the REPL, while being pretty key to interactive data analysis, is not a key feature of programming languages in general, even interpreted ones. So the solution is: use a third party solution for a complete environment suitable for your needs. For instance, for people doing data analysis, I recommend Anaconda -- then you get iPython and JUpyter (and Spyder) out of the box -- and away we go. maybe it's worth a note t pyton-dev to confirm my vague impression (or some more thorough googling for previous discussions) -- but I wouldn't put much effort into ideas for the REPL without confirming that the core dev are open to the concept. -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Wed, 22 Aug 2018 09:38:57 -0700 Chris Barker via Python-ideas <python-ideas@python.org> wrote:
To me it sounds fine to improve the REPL. Especially, being able to paste examples without effort was a sore point for me until I finally switched to IPython. How much complexity and development work that would entail I don't know, though :-) Regards Antoine.
%edit -p
Bring up an editor and execute the resulting code.
-p: this will call the editor with the same data as the previous time it was used, regardless of how long ago (in your current session) it was.
https://ipython.readthedocs.io/en/stable/interactive/magics.html#magic-edit Something like this that calls $EDITOR with a temp file would be useful in the Python REPL as well. On Wednesday, August 22, 2018, Antoine Pitrou <solipsis@pitrou.net> wrote:
%doctest_mode works like the Python REPL (with '>>>' prompts and no pretty printing) https://ipython.readthedocs.io/en/stable/interactive/magics.html#magic-docte... On Wednesday, August 22, 2018, Wes Turner <wes.turner@gmail.com> wrote:
On Wed, Aug 22, 2018 at 06:01:05PM -0400, Wes Turner wrote:
%edit -p
Bring up an editor and execute the resulting code.
https://code.activestate.com/recipes/578926-call-out-to-an-external-editor/ -- Steve
On Wed, Aug 22, 2018 at 7:47 PM Mike Miller <python-ideas@mgmiller.net> wrote:
Happily, you know where to get IPython, and BPython, and PTPython. Different users have different desires for an enhanced REPL, and different good, free software, projects exist. I would tend to oppose most of these "fixes" to the basic Python REPL as "feature creep." Full featured interactive shells are great. I use IPython and Jupyter dozens of times every day myself. I love those. But they make specific decisions on what and how to enhance things, and have a huge range of configuration options. The `python` REPL should really be just good enough to use, and allow other projects to provide the richer experience (and to maintain all the code associated with making them powerful and flexible). Obviously, that's not saying categorically that "nothing can ever change" in the Python REPL. But most things I would lean against adding. It does basically as much as it should, with no more code than is necessary to do that. -- Keeping medicines from the bloodstreams of the sick; food from the bellies of the hungry; books from the hands of the uneducated; technology from the underdeveloped; and putting advocates of freedom in prisons. Intellectual property is to the 21st century what the slave trade was to the 16th.
On Mon, Aug 20, 2018 at 09:07:20AM -0700, Chris Barker via Python-ideas wrote:
(side note -- are all domain-specific technical term "jargon"?
Yes. But not all jargon is a domain-specific technical term. https://en.wiktionary.org/wiki/jargon -- Steve
participants (15)
-
Antoine Pitrou -
Barry -
Barry Scott
-
Chris Angelico -
Chris Barker -
David Mertz -
Greg Ewing -
Jacco van Dorp -
Jonathan Fine -
Michael Selik -
Mike Miller -
Steve Barnes -
Steven D'Aprano -
Terry Reedy -
Wes Turner