Re: Need reviews for my book on introductory python
On 27/01/2017 21:36, MRAB wrote: On 2017-01-27 21:18, mm0fmf wrote: On 27/01/2017 20:17, bob gailer wrote: On 1/25/2017 9:25 PM, Sandeep Nagar wrote: Hi, A few month ago I wrote a book on introductory python based on my experinces while teaching python to Bachelor students of engineering. It is now available in e-book and paperback format at Amazon. https://www.amazon.com/dp/1520153686 The book is written for beginners of python programming language and written in learn-by-doing manner. If some group members can review the same, it will be useful for myself to come up with an improved version. Who is the publisher of this book? I just took a look at the pages that can be viewed on Amazon. Many reactions. it is hard for me to write this, as it seems it would sound harsh, judgemental, unappreciative. But you did ask for a review, and this is my honest reaction. I find it hard to read a book written by a non-native speaker of English. I an constantly having to overlook what to me are spelling, grammatical and vocabulary errors. I HIGHLY recommend you find an editor who can fix these errors. Snap. I found it impossible to read and never got to the Python parts. It is not written in English. Most of the pronouns and conjunctions are missing. It looks like it has not been proof-read as words loose capitalisation, many are mis-spelt and grammar rules regarding plural cases and agreement are just ignored. "loose"? Don't you mean "lose"? (Or possible "lack"?) My spelling is not brilliant especially when typing live and so you have proved why books need proof-reading. In particular "lose" is what I meant. Python, the name of the language, is a proper noun and should be captialised. In the few pages I read, Python appears as "python" and "Python", randomly losing the capital letter. Lacking capitalisation would suggest to me that some or all words are consistently written without the capital letter such as always writing "united states of america". -- https://mail.python.org/mailman/listinfo/python-list
Is shutil.get_terminal_size useless?
shutil.get_terminal_size returns the wrong values when you pipe your output
to another process, even it you do so in a terminal. Consider this script:
import os
import shutil
print('shutil:', shutil.get_terminal_size(fallback=(999, 999)))
print('os:', os.get_terminal_size(0))
That uses two different methods to get the terminal size. If I run that in a
terminal in the normal way, it works fine, returning the correct size for
my terminal:
[steve@ando ~]$ python3.5 test_gts.py
shutil: os.terminal_size(columns=116, lines=29)
os: os.terminal_size(columns=116, lines=29)
But if I pipe the output to something else, the shutil version fails to
determine the correct terminal size, and falls back on the default:
[steve@ando ~]$ python3.5 test_gts.py | cat
shutil: os.terminal_size(columns=999, lines=999)
os: os.terminal_size(columns=116, lines=29)
while the os version gives the correct result.
Is shutil.get_terminal_size useless? When, if ever, should I use it in
preference to the os version? If the shutil version is broken, can it be
fixed?
Thanks to Bernardas Ališauskas:
http://granitosaurus.rocks/getting-terminal-size.html
--
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is shutil.get_terminal_size useless?
On Sat, Jan 28, 2017 at 7:03 PM, Steve D'Aprano wrote: > But if I pipe the output to something else, the shutil version fails to > determine the correct terminal size, and falls back on the default: > > > [steve@ando ~]$ python3.5 test_gts.py | cat > shutil: os.terminal_size(columns=999, lines=999) > os: os.terminal_size(columns=116, lines=29) > > > while the os version gives the correct result. I believe the problem here is your definition of "correct". When you inquire of the os module, you're asking, at a fairly low level, what the terminal window is sized to. But when you ask shutil, you're asking what a shell utility should do. Quite a few programs change in behaviour when piped into something else (for instance, 'ls' will often apply colour and columnate its text, but if you pipe it into grep, you don't want any of that), and shutil is acknowledging that different effect. Both are correct answers - to different questions. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Is shutil.get_terminal_size useless?
Steve D'Aprano wrote:
> shutil.get_terminal_size returns the wrong values when you pipe your
> output to another process, even it you do so in a terminal. Consider this
> script:
>
>
> import os
> import shutil
> print('shutil:', shutil.get_terminal_size(fallback=(999, 999)))
> print('os:', os.get_terminal_size(0))
>
>
> That uses two different methods to get the terminal size. If I run that in
> a terminal in the normal way, it works fine, returning the correct size
> for my terminal:
>
>
> [steve@ando ~]$ python3.5 test_gts.py
> shutil: os.terminal_size(columns=116, lines=29)
> os: os.terminal_size(columns=116, lines=29)
>
>
> But if I pipe the output to something else, the shutil version fails to
> determine the correct terminal size, and falls back on the default:
>
>
> [steve@ando ~]$ python3.5 test_gts.py | cat
> shutil: os.terminal_size(columns=999, lines=999)
> os: os.terminal_size(columns=116, lines=29)
>
>
> while the os version gives the correct result.
>
> Is shutil.get_terminal_size useless? When, if ever, should I use it in
> preference to the os version? If the shutil version is broken, can it be
> fixed?
One potential advantage of shutil.get_terminal_size() is that you can affect
it with an environment variable:
$ python3 test_gts.py | cat
shutil: os.terminal_size(columns=999, lines=999)
os: os.terminal_size(columns=72, lines=48)
$ COLUMNS=123 python3 test_gts.py | cat
shutil: os.terminal_size(columns=123, lines=999)
os: os.terminal_size(columns=72, lines=48)
I have the line
export LINES COLUMNS
in my .bashrc, so by default I see the physical size:
$ export COLUMNS LINES
$ python3 test_gts.py | cat
shutil: os.terminal_size(columns=72, lines=48)
os: os.terminal_size(columns=72, lines=48)
> Thanks to Bernardas Ališauskas:
>
> http://granitosaurus.rocks/getting-terminal-size.html
--
https://mail.python.org/mailman/listinfo/python-list
GUI
hay , i am new in the coding world,i would like to understand how a python program is communicating with GUI, for example, if i have a code that require the user to enter a value ,then this code will do some calculations and return a value to the user, how to do that? -- https://mail.python.org/mailman/listinfo/python-list
Re: Is shutil.get_terminal_size useless?
On Sat, 28 Jan 2017 07:27 pm, Chris Angelico wrote: > On Sat, Jan 28, 2017 at 7:03 PM, Steve D'Aprano > wrote: >> But if I pipe the output to something else, the shutil version fails to >> determine the correct terminal size, and falls back on the default: >> >> >> [steve@ando ~]$ python3.5 test_gts.py | cat >> shutil: os.terminal_size(columns=999, lines=999) >> os: os.terminal_size(columns=116, lines=29) >> >> >> while the os version gives the correct result. > > I believe the problem here is your definition of "correct". That would be the dictionary definition: Correct - conformable to truth; not faulty; free from error :-P > When you > inquire of the os module, you're asking, at a fairly low level, what > the terminal window is sized to. Right: I want to know what the terminal window is sized to. > But when you ask shutil, you're > asking what a shell utility should do. No, I'm asking what the terminal window is sized to. That's why the function is called get_terminal_size(), not what_should_a_shell_utility_do(). What should a shell utility do, under what circumstances? How can any function answer that? > Quite a few programs change in > behaviour when piped into something else (for instance, 'ls' will > often apply colour and columnate its text, but if you pipe it into > grep, you don't want any of that), Sure, and if I wanted to know if standard output was being piped to something else, I'd expect to call a function called something like where_is_std_out_being_piped_to(). The terminal size doesn't change just because I'm piping output to another process. Using the terminal size as a proxy for "being piped" is sheer insanity. That would be like calling len(some_string) and expecting it to return None if some_string was all uppercase. > and shutil is acknowledging that different effect. Before there can be a *different* effect, there needs to be an *original* effect, and I have no idea what effects you are referring to. Be precise, please. I don't dispute that there are times where a process may wish to change behaviour when being piped to something else. But that's a red herring: I'm asking what the terminal size is. I expect to get the terminal size, or perhaps an exception if there is no terminal, with an *optional* default, not a mandatory one. So far it sounds like shutil.get_terminal_size() is broken by design. Can somebody convince me it isn't? > Both are correct answers - to different questions. But I'm only asking one question: what's the terminal size? It sounds like your answer is just a long, round-about way of saying "Yes, it's useless. You cannot trust it to return the terminal size, even when there is a terminal." I haven't even asked what happens if it is called when there is no associated terminal... but now I'm afraid that if I do, it will return the number of CPUs in my computer or something... -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is shutil.get_terminal_size useless?
On Sat, 28 Jan 2017 07:39 pm, Peter Otten wrote: > One potential advantage of shutil.get_terminal_size() is that you can > affect it with an environment variable: > > $ python3 test_gts.py | cat > shutil: os.terminal_size(columns=999, lines=999) > os: os.terminal_size(columns=72, lines=48) > > $ COLUMNS=123 python3 test_gts.py | cat > shutil: os.terminal_size(columns=123, lines=999) > os: os.terminal_size(columns=72, lines=48) Unless your terminal *actually is* 123 columns wide, I don't see that as an advantage. I see that as "Hey look, we can fool shutil into returning absolute garbage instead of the terminal size!" I can already read environment variables using os.getenv() and os.environ, so this gives me no new functionality. > I have the line > > export LINES COLUMNS > > in my .bashrc, so by default I see the physical size: > > $ export COLUMNS LINES > $ python3 test_gts.py | cat > shutil: os.terminal_size(columns=72, lines=48) > os: os.terminal_size(columns=72, lines=48) But what happens if you resize the terminal while the process is running? Again, the os.get_terminal_size() correctly returns the updated size, while shutil.get_terminal_size() doesn't. -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is shutil.get_terminal_size useless?
On Sat, Jan 28, 2017 at 9:49 PM, Steve D'Aprano wrote: > The terminal size doesn't change just because I'm piping output to another > process. Using the terminal size as a proxy for "being piped" is sheer > insanity. In a sense, there _is no_ terminal size when you're being piped to another process. Likewise if you're running in some detached (non-terminal) context, or if you're being run over some remote link that hasn't transmitted terminal size info, etc, etc, etc, etc. It's not a proxy for "being piped" - it's that when your output isn't going to a terminal, asking "what is my terminal size" isn't particularly productive. Would you expect that a process started from systemd is told about the size of the terminal in which you ran "systemctl start servicename"? I doubt it. Would you expect a cronjob to use the terminal size when you most recently edited crontab? No. So why should a program that's being piped into something else automatically assume the size of the other program's terminal? You might well be a completely background process. You can still ask the concrete question about terminal size, and that's in the 'os' module. The 'shutil' module also looks at environment variables, and probably would be the place to respond to TELNET NAWS if that has any sort of primary-level support. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Is shutil.get_terminal_size useless?
On Sat, Jan 28, 2017 at 8:03 AM, Steve D'Aprano
wrote:
> print('shutil:', shutil.get_terminal_size(fallback=(999, 999)))
> print('os:', os.get_terminal_size(0))
[snip]
> But if I pipe the output to something else, the shutil version fails to
> determine the correct terminal size, and falls back on the default:
The high-level shutil wrapper uses sys.__stdout__, without falling
back on sys.__stdin__ or sys.__stderr__, so it has to rely on the
environment variables and/or fallback value when stdout isn't a
terminal. OTOH, in this case you're calling os.get_terminal_size(0) on
the STDIN file descriptor, which obviously works -- at least on Unix
-- because it's a tty. On Windows that generally won't work because
getting the screen size requires a handle for a screen buffer, not an
input buffer. In this case, os.get_terminal_size(2) would generally
work on Windows because stderr hasn't been redirected.
I just wrote an extended version of shutil.get_terminal_size that
tries six (minus two) ways to Sunday to get the terminal size,
starting with /dev/tty on Unix and CONOUT$ on Windows. It's needlessly
complicated by the Windows implementation of os.get_terminal_size,
which is strangely hard coded. os.get_terminal_size calls GetStdHandle
with a fake mapping of 0, 1, and 2 to the standard handles. It should
just call get_osfhandle on the given file descriptor. That way someone
could use something like the following:
with open('CONOUT$', 'r+') as conout:
size = os.get_terminal_size(conout.fileno())
which would be guaranteed to work if the process is attached to a
console. The current implementation forces one to temporarily modify a
standard handle, which has to be gated by a lock for thread safety.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is shutil.get_terminal_size useless?
Steve D'Aprano wrote: >> One potential advantage of shutil.get_terminal_size() is that you can >> affect it with an environment variable: >> >> $ python3 test_gts.py | cat >> shutil: os.terminal_size(columns=999, lines=999) >> os: os.terminal_size(columns=72, lines=48) >> >> $ COLUMNS=123 python3 test_gts.py | cat >> shutil: os.terminal_size(columns=123, lines=999) >> os: os.terminal_size(columns=72, lines=48) > > Unless your terminal *actually is* 123 columns wide, I don't see that as > an advantage. But the script does not write to the terminal and has no way (?) of knowing whether the pipe ends in the terminal or in a file. Assuming it does end in the terminal seems like a good default to me, and setting COLUMNS provides a uniform way to override that default. I prefer that to what e. g. aptitude does which uses the full width of the terminal window but falls back to 80 $ aptitude search foo p bygfoot - Fußball-Managerspiel ... $ aptitude search foo | grep python p python-foolscap - RPC-System auf Basis der Objektfähigkeiten p python-rfoo - Fast RPC package for Python (and a To get back well-behaved output you need both the envvar and a commandline option: $ aptitude search -w $COLUMNS foo | grep python p python-foolscap - RPC-System auf Basis der Objektfähigk > I see that as "Hey look, we can fool shutil into returning > absolute garbage instead of the terminal size!" There are valid reasons for temporarily altering the number of columns, like writing to a file or preparing a code sample. > I can already read environment variables using os.getenv() and os.environ, > so this gives me no new functionality. shutil.get_terminal_size() combines access to shell variables and the os, and IMHO that is a useful approach. -- https://mail.python.org/mailman/listinfo/python-list
Re: GUI
[email protected] wrote: > hay , i am new in the coding world,i would like to understand how a python > program is communicating with GUI, for example, if i have a code that > require the user to enter a value ,then this code will do some > calculations and return a value to the user, how to do that? A command line script adding two numbers will look like this: x = input_int("Enter x:") y = input_int("Enter y:") print("x + y =", x + y) This script will not continue to ask for y until the user has entered the value for x In a GUI you have to provide widgets that allow the user to interact with the GUI . Let's assume make_widget() creates an entry widget and shows it in a window. Then we can create the part of the GUI where the user enters the x and y value with: entry_x = make_widget() entry_y = make_widget() Now we need one more widget to show the result: entry_sum = make_widget() We also need a function that recalculates the contents of entry_sum whenever the user changes x or y: def recalculate_sum(): x = int(entry_x.get_value()) y = int(entry_y.get_value()) entry_sum.set_value(sigma) But when should this function run? We have to connect it to the widgets on whose changes it should react. Such a function is called "callback": # assume that every time the contents of entry_x/y change it calls # self.on_change() entry_x.on_change = recalculate_sum entry_y.on_change = recalculate_sum Finally you enter an infinite loop that waits for and handles GUI events, the most interesting being user activities like typing a digit into one of your widgets. run_event_loop() There a many GUIs, but they all tend to work in a way similar to the one sketched above. Here's a translation of the above pseudo-code to tkinter: import tkinter as tk def make_entry(caption, row): """Create a Label and an Entry. Return the StringVar associated with the Entry. """ # the text displayed to the left of the Entry label = tk.Label(root, text=caption) label.grid(row=row, column=0) var = tk.StringVar() # holds the text entered into the Entry entry = tk.Entry(root, textvariable=var) entry.grid(row=row, column=1, sticky=tk.EW) return var def calculate_sum(*args): """Callback invoked on changes of x or y The GUI passes some arguments (*args) that we are not interested in. """ try: x = int(var_x.get()) y = int(var_y.get()) sigma = x + y except ValueError as err: # if x or y aren't valid integers # show an error message instead of the sum sigma = err var_sum.set(sigma) # Create the main window root = tk.Tk() # Have the second column take all extra space root.columnconfigure(1, weight=1) var_x = make_entry("x", 0) var_y = make_entry("y", 1) var_sum = make_entry("x + y =", 2) # Tell the GUI to invoke calculate_sum() after every change of x or y var_x.trace("w", calculate_sum) var_y.trace("w", calculate_sum) root.mainloop() -- https://mail.python.org/mailman/listinfo/python-list
Update to Python 3 Cheat Sheet
Hi, I updated the cheat sheet on the aesthetic side. Parts bloc and their title are now more easily identified with colors (but its nice with B&W printing too). French and german versions have also been updated. See https://perso.limsi.fr/pointal/python:memento A+ L.Pointal. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is shutil.get_terminal_size useless?
On 2017-01-28, Steve D'Aprano wrote: > Right: I want to know what the terminal window is sized to. What do you mean by "the terminal"? Do you mean the device to which the program's output is connected? Since output is what you have control over, and what's width you might want to change, that's what makes sense to me. Or do you mean the device to which the program's input is connected? Or do you mean the controlling tty for the process group in which the program is running? > The terminal size doesn't change just because I'm piping output to > another process. Using the terminal size as a proxy for "being > piped" is sheer insanity. Why do you want to know what the terminal width is if it isn't to control the format of the output? That's why _I_ would want to know the terminal width. And in that case, the width of there stdout is going is what makes the most sense to me. > But I'm only asking one question: what's the terminal size? The library call you're making defines "the terminal" as the device to which stdout is connected. You apparently which to define "the terminal" differently. In which case you need to use a different library call. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Is shutil.get_terminal_size useless?
On 01/28/2017 04:00 AM, Steve D'Aprano wrote: >> $ COLUMNS=123 python3 test_gts.py | cat >> shutil: os.terminal_size(columns=123, lines=999) >> os: os.terminal_size(columns=72, lines=48) Interesting. On my machine with Python 3.4, calling os.get_terminal_size() and piping the output results in the exception OSError: [Errno 25] Inappropriate ioctl for device Which is what I'd expect, seeing as there's no tty and no terminal emulator. I'm not sure why you're not seeing that error also. > Unless your terminal *actually is* 123 columns wide, I don't see that as an > advantage. I see that as "Hey look, we can fool shutil into returning > absolute garbage instead of the terminal size!" Influencing the column width used by a program for output is very useful and is often used in shell scripting and piping data. This allows programs to just have to use one mechanism to determine line length, regardless of whether it's running on a tty or connected to a pipe. > I can already read environment variables using os.getenv() and os.environ, > so this gives me no new functionality. Sure but working through shutils provides a uniform way of getting the maximum column width. Furthermore using shutils is probably more portable. I'm not sure if you can override LINES or not, but even if you can't that's pointless. > But what happens if you resize the terminal while the process is running? > Again, the os.get_terminal_size() correctly returns the updated size, while > shutil.get_terminal_size() doesn't. For a program that's communicating with a tty, you just have to call shutil.get_terminal_size() again to get the updated size. For your piped process, the question doesn't make sense. You can't resize a pipe. The only process that can respond to terminal changes is the final process in your chain that's actually writing to the tty. If your process is talking to a pipe, then the only thing you can do is make an arbitrary decision about the line length (columns==999 means unlimited, otherwise limit to columns). Nothing else makes sense. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is shutil.get_terminal_size useless?
On Sat, 28 Jan 2017 10:50 pm, Chris Angelico wrote: > On Sat, Jan 28, 2017 at 9:49 PM, Steve D'Aprano > wrote: >> The terminal size doesn't change just because I'm piping output to >> another process. Using the terminal size as a proxy for "being piped" is >> sheer insanity. > > In a sense, there _is no_ terminal size when you're being piped to > another process. In which sense, and why do you think it is relevant? There clearly is a terminal, because that's where I'm running the code. Regardless of whether I pipe it to grep or cat or something else, the output from *that* process still ends up in the same terminal that I typed the command in. I acknowledge that there are cases where there is no terminal. As you say: > Likewise if you're running in some detached > (non-terminal) context, Then get_terminal_size() should raise, unless you explicitly ask for a default size. Likewise: > or if you're being run over some remote link > that hasn't transmitted terminal size info, I think that the possibility of having such a remote link is a failure of the remote protocol being used. (ssh? telnet?) But it is what it is. Perhaps there genuinely are circumstances where the terminal size exists but is unknowable -- but the example code isn't one of them. > etc, etc, etc, etc. It's > not a proxy for "being piped" - it's that when your output isn't going > to a terminal, asking "what is my terminal size" isn't particularly > productive. Then explain why os.get_terminal_size() returns the correct answer. The output might not be going to a terminal (not directly at least) but the question isn't "what's the size of the terminal that output is going to". The question is "what's the size of the terminal that this process is running in", and that has an answer regardless of where output is piped. > Would you expect that a process started from systemd is told about the > size of the terminal in which you ran "systemctl start servicename"? I > doubt it. I wouldn't make any assumptions at all about what systemd does. For all I know, it hard codes a size of (300, 100) into every single process because that's the size of terminals on Lennart's laptop. > Would you expect a cronjob to use the terminal size when you > most recently edited crontab? No. Of course not -- the terminal where you edited crontab is not where the process is running. Why would it be the least bit relevant? > So why should a program that's being > piped into something else automatically assume the size of the other > program's terminal? Because the other program is running in the same terminal as the first process. grep foo * | wc -l Both grep and wc are running in the same terminal. (Assuming there is any terminal at all.) > You might well be a completely background process. And if that background process is running in a terminal? What's your point? I'm not disputing that there are processes where no terminal exists at all. That's a red herring. os.get_terminal_size() returns the correct result. Why doesn't shutil? > You can still ask the concrete question about terminal size, You mean like a function called get_terminal_size()? > and that's in the 'os' module. The 'shutil' module also looks at > environment variables, Why? We already have ways to look at environment variables. The only complication here is that, perhaps, there may be more than one set of environment variables to compare, and some order that they should be preferred. It is often the Unix way that there might be two, or twenty-two *wink* different environment variables to communicate this information. But in this case, I'm not able to find anything other than the two standard variables, COLUMNS and LINES. Aside: technically these are shell variables, and they may not exist in arbitrary shells. They also need to be explicitly exported as environment variables to become visible to Python. See this StackOverflow question for more information: http://unix.stackexchange.com/questions/215584/whats-the-name-of-the-environment-variable-with-current-terminal-width -- Steve “Cheer up,” they said, “things could be worse.” So I cheered up, and sure enough, things got worse. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is shutil.get_terminal_size useless?
On 01/28/2017 09:03 AM, Michael Torrie wrote: > On 01/28/2017 04:00 AM, Steve D'Aprano wrote: >>> $ COLUMNS=123 python3 test_gts.py | cat >>> shutil: os.terminal_size(columns=123, lines=999) >>> os: os.terminal_size(columns=72, lines=48) > > Interesting. On my machine with Python 3.4, calling > os.get_terminal_size() and piping the output results in the exception > OSError: [Errno 25] Inappropriate ioctl for device Oh I see you are calling get_terminal_size() on file handle 0 which is standard in. Generally, I can't think of very many use cases for caring about the terminal size on the *input* side. Most times I only care about the output side, which if it's a pipe doesn't make a lot of sense to care about, other than maximum line length. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is shutil.get_terminal_size useless?
On 01/28/2017 09:15 AM, Steve D'Aprano wrote: > Then get_terminal_size() should raise, unless you explicitly ask for a > default size. Which it does if you call it on the standard out file handle, which is the default, and for most applications, the most useful. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is shutil.get_terminal_size useless?
On 01/28/2017 09:15 AM, Steve D'Aprano wrote: > Then explain why os.get_terminal_size() returns the correct answer. Basically you were asking two different questions there. shutil.get_terminal_size always asks the question of size of the terminal that the standard output file handle is connected to. Whereas, if I read this correctly, you asked os.get_terminal_size to query the size of the terminal attached to the *standard input* file handle. These are very different things. If you want to know the size of the terminal on the input side, use os.get_terminal_size(0), not shutil. By the way my comment about raising an exception a moment ago was about os.get_terminal_size(1). Apparently shutil is trying to be a convenience function and lets you specify a default size if there is no size to determine. > The output might not be going to a terminal (not directly at least) but the > question isn't "what's the size of the terminal that output is going to". > The question is "what's the size of the terminal that this process is > running in", and that has an answer regardless of where output is piped. In your specific case, the answer is to get the terminal size by querying os.get_terminal_size on standard in, since your standard out is not a tty. In most other situations the question doesn't make a lot of sense because there's no correlation between the terminal that the process is running in and the terminal the process's output is going to be piped to when a tty is not involved. For example: command1 | python3 test_gts.py | command2 In that case your process has no terminal on either end. Only command1 and command 2 do. -- https://mail.python.org/mailman/listinfo/python-list
Reviews of book on introductory Python (was: Need reviews for my book on introductory python)
mm0fmf wrote: > […] Python, the name of the language, is a proper noun and should be > captialised. In the few pages I read, Python appears as "python" and > "Python", randomly losing the capital letter. Lacking capitalisation > would suggest to me that some or all words are consistently written > without the capital letter such as always writing "united states of > america". I have not read the book, but it should be noted that lack of capitalisation can be intentional. For example, “Python” would refer to the programming language, while “python” would refer to the command/program with which the language compiler/interpreter is executed. The latter can appear in prose as well, and should, by contrast to the former, be set in a monospace type. If it is truly capitalised randomly, though, as indicated by the OP’s Subject header field value (until before now repeated by everyone else), then it is of course badly written. -- PointedEars Twitter: @PointedEars2 Please do not cc me. / Bitte keine Kopien per E-Mail. -- https://mail.python.org/mailman/listinfo/python-list
Re: Is shutil.get_terminal_size useless?
On 2017-01-28, Steve D'Aprano wrote: > On Sat, 28 Jan 2017 10:50 pm, Chris Angelico wrote: > >> On Sat, Jan 28, 2017 at 9:49 PM, Steve D'Aprano >> wrote: >>> The terminal size doesn't change just because I'm piping output to >>> another process. Using the terminal size as a proxy for "being piped" is >>> sheer insanity. >> >> In a sense, there _is no_ terminal size when you're being piped to >> another process. > > In which sense, and why do you think it is relevant? > > There clearly is a terminal, because that's where I'm running the > code. Regardless of whether I pipe it to grep or cat or something > else, the output from *that* process still ends up in the same > terminal that I typed the command in. I'm sorry, it's not at all obvious to me (or, apparently to the author of shutil.get_terminal_size) that the output is going to end up in the terminal where you typed the command. The output might just as easily end up in a file or in a completely different terminal (possibly on a different machine). > I acknowledge that there are cases where there is no terminal. And cases where there is a different terminal entirely. To me, the current behavior of shutil.get_terminal_size seems to be the most useful. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Is shutil.get_terminal_size useless?
On Sun, Jan 29, 2017 at 3:15 AM, Steve D'Aprano wrote: > On Sat, 28 Jan 2017 10:50 pm, Chris Angelico wrote: > >> On Sat, Jan 28, 2017 at 9:49 PM, Steve D'Aprano >> wrote: >>> The terminal size doesn't change just because I'm piping output to >>> another process. Using the terminal size as a proxy for "being piped" is >>> sheer insanity. >> >> In a sense, there _is no_ terminal size when you're being piped to >> another process. > > In which sense, and why do you think it is relevant? > > There clearly is a terminal, because that's where I'm running the code. > Regardless of whether I pipe it to grep or cat or something else, the > output from *that* process still ends up in the same terminal that I typed > the command in. No, not automatically. I've written plenty of programs that accept input via a pipe and don't display any of it. Just because someone types "command1 | command2", you can't assume that the terminal command2 is outputting to is the same size as the one command1 should be outputting to. >> etc, etc, etc, etc. It's >> not a proxy for "being piped" - it's that when your output isn't going >> to a terminal, asking "what is my terminal size" isn't particularly >> productive. > > Then explain why os.get_terminal_size() returns the correct answer. > > The output might not be going to a terminal (not directly at least) but the > question isn't "what's the size of the terminal that output is going to". > The question is "what's the size of the terminal that this process is > running in", and that has an answer regardless of where output is piped. Processes aren't always running "in" terminals, though. That's my point. A terminal is not a fundamental feature of a process. >> Would you expect a cronjob to use the terminal size when you >> most recently edited crontab? No. > > Of course not -- the terminal where you edited crontab is not where the > process is running. Why would it be the least bit relevant? So where *is* that process running? What terminal is it in? Don't you see how similar this is to the pipe situation - sure, there might be a terminal that the program was invoked from, but it's utterly irrelevant to how the program actually runs. >> You might well be a completely background process. > > And if that background process is running in a terminal? What's your point? Background processes don't have terminal access. Whether it's a daemon or something started as "commandname >/dev/null 2>/dev/null https://mail.python.org/mailman/listinfo/python-list
Re: Is shutil.get_terminal_size useless?
Chris Angelico : > Background processes don't have terminal access. Whether it's a daemon > or something started as "commandname >/dev/null 2>/dev/null &" from bash, it doesn't have access to a terminal. A nitpick: a process running in the background or a process with no open terminal file descriptor still does have a controlling terminal under Unix/Linux. http://man7.org/linux/man-pages/man4/tty.4.html> https://docs.python.org/3/library/fcntl.html#fcntl.ioctl> https://linux.die.net/man/2/setsid> https://docs.python.org/3/library/os.html#os.setsid> Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: Is Python SSL API thread-safe?
On 2017-01-22, Christian Heimes wrote: > OpenSSL and Python's ssl module are thread-safe. However IO is not > safe concerning reentrancy. You cannot safely share a SSLSocket > between threads without a mutex. Certain aspects of the TLS protocol > can cause interesting side effects. A recv() call can send data > across a wire and a send() call can receive data from the wire, > e.g. during re-keying. And it looks to me like the Python SSL module does all of that. It provides mutexes and thread ID and locking callbacks as described in the page below: https://www.openssl.org/docs/man1.0.2/crypto/threads.html According to that page above it's safe to share the socket between threads: OpenSSL can safely be used in multi-threaded applications provided that at least two callback functions are set, locking_function and threadid_func. They python ssl module code does that, so python ssl sockets should be thread safe. Can you explain why you disagree? Can you provide example code that demonstrates a failure? > In order to archive reentrancy, you have to do all IO yourself by > operating the SSL connection in non-blocking mode or with a > Memorio-BIO https://docs.python.org/3/library/ssl.html#ssl-nonblocking That section is about how to work with non-blocking sockets. I'm not using non-blocking sockets. -- Grant Edwards grant.b.edwardsYow! Now I'm concentrating at on a specific tank battle gmail.comtoward the end of World War II! -- https://mail.python.org/mailman/listinfo/python-list
Re: Is shutil.get_terminal_size useless?
On Sat, Jan 28, 2017 at 5:58 PM, Chris Angelico wrote:
> Processes in the middle of pipelines *do not have* terminals.
No, in the following case stderr is a terminal:
$ echo spam |
> python3 -c 'import os
> print(os.get_terminal_size(2))' |
> cat
os.terminal_size(columns=132, lines=43)
Let's also redirect stderr to the pipe:
$ echo spam |
> 2>&1 python3 -c 'import os
> print(os.get_terminal_size(2))' |
> cat
Traceback (most recent call last):
File "", line 2, in
OSError: [Errno 25] Inappropriate ioctl for device
Now let's open and use the controlling terminal instead:
$ echo spam |
> 2>&1 python3 -c 'import os
> fd = os.open("/dev/tty", os.O_RDONLY)
> print(os.get_terminal_size(fd))' |
> cat
os.terminal_size(columns=132, lines=43)
Now let's get rid of the terminal via setsid:
$ echo spam |
> 2>&1 setsid python3 -c 'import os
> fd = os.open("/dev/tty", os.O_RDONLY)
> print(os.get_terminal_size(fd))' |
> cat
Traceback (most recent call last):
File "", line 2, in
OSError: [Errno 6] No such device or address: '/dev/tty'
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is shutil.get_terminal_size useless?
On Sun, Jan 29, 2017 at 7:04 AM, eryk sun wrote:
> Now let's get rid of the terminal via setsid:
>
>$ echo spam |
> > 2>&1 setsid python3 -c 'import os
> > fd = os.open("/dev/tty", os.O_RDONLY)
> > print(os.get_terminal_size(fd))' |
> > cat
> Traceback (most recent call last):
> File "", line 2, in
> OSError: [Errno 6] No such device or address: '/dev/tty'
And you could have achieved the same result in any number of other
ways, too, like setting yourself up with the local boot system (true
of systemd, upstart, sysvinit, and probably of all others too), or
cron, or inetd, etc, etc, etc. You can definitely lose access to your
"controlling terminal".
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Is shutil.get_terminal_size useless?
Chris Angelico :
> On Sun, Jan 29, 2017 at 7:04 AM, eryk sun wrote:
>> Now let's get rid of the terminal via setsid:
>>
>>$ echo spam |
>> > 2>&1 setsid python3 -c 'import os
>> > fd = os.open("/dev/tty", os.O_RDONLY)
>> > print(os.get_terminal_size(fd))' |
>> > cat
>> Traceback (most recent call last):
>> File "", line 2, in
>> OSError: [Errno 6] No such device or address: '/dev/tty'
>
> And you could have achieved the same result in any number of other
> ways, too, like setting yourself up with the local boot system (true
> of systemd, upstart, sysvinit, and probably of all others too), or
> cron, or inetd, etc, etc, etc. You can definitely lose access to your
> "controlling terminal".
Eryk has a real, deeper point worth getting acquainted with.
(Although if I were to design an operating system, I don't know if I
would bother with controlling terminals, job control or chirping
modems.)
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: How coding in Python is bad for you
On Monday, January 23, 2017 at 9:24:56 AM UTC-8, [email protected] wrote: > The article is here http://lenkaspace.net/index.php/blog/show/111 > > Kindest regards. > > Mark Lawrence. I remember the old days of Python when it was just Perl's little brother. Sometimes I feel moments of amazement whenever someone makes this much of an effort to badmouth it (and this blog is definitely badmouthing it, very little of criticism is reasonable). Carl Banks -- https://mail.python.org/mailman/listinfo/python-list
Re: Is shutil.get_terminal_size useless?
On 2017-01-28, Marko Rauhamaa wrote: > (Although if I were to design an operating system, I don't know if I > would bother with controlling terminals, job control or chirping > modems.) I've been using serial ports on Unix for 35 years, and maintaining serial drivers for Linux for almost 20. Many days, it seems like the tty/serial API in Unix is the rug under which all the ugly dirt got swept... Then I think about X. and I guess the networking stuff gets ugly pretty fast when you look under the hood. It's really pretty impressive how orthogonal they did manage to make things. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
What are your opinions on .NET Core vs Python?
As you guys might know, .NET Core is up and running, promising a "cross-platform, unified, fast, lightweight, modern and open source experience" (source: .NET Core official site). What do you guys think about it? Do you think it will be able to compete with and overcome Python in the opensource medium? -- https://mail.python.org/mailman/listinfo/python-list
