Re: why does memory consumption keep growing?
On Fri, 6 Oct 2017 04:51 pm, Chris Angelico wrote: > On Fri, Oct 6, 2017 at 4:14 PM, Gregory Ewing > wrote: >> Steve D'Aprano wrote: >>> >>> Plus the downtime and labour needed to install the memory, if the computer >>> will even take it. >> >> >> Obviously we need an architecture that supports hot-swappable >> robot-installable RAM. Isn't there a firmware update to the RAM that will double the available memory? > Cloud computing is the answer. > > If you don't believe me, just watch the sky for a while - new clouds > get added without the sky turning off and on again. Yeah, but they also disappear without notice, just when you need them the most. And there's no privacy, they leak private information constantly: everyone in the area knows exactly how many clouds you have and what they're doing. There's even a website that tells you what clouds have been ordered and where they're going: http://www.bom.gov.au/ -- 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: problem with Python 3.6 + PyX
Please install below. in my case, it is resolved. sudo apt install texinfo sudo apt install texlive-binaries 2017년 2월 11일 토요일 오전 8시 49분 36초 UTC+9, stalker5 님의 말: > Yes, I have a Tex engine on my system. > How can i fix the problem with the PATH ? > Even if i execute the .py script directly by python (I mean :not inside > a LateX file) pyx need to reach the TeX system ? > Is there a config file to fix the PATH ? Where ? > > Thanks a lot !! Ciao > -- > Olivier > > > PyX requires TeX to render textual glyphs into the image. Do you have it > > installed? If so, is it "reachable" by your $PATH variable? > > > > A quick test to re-render my PyX-based images with Python 3.6 didn't reveal > > any problem... > > > > ciao, lele. > > -- https://mail.python.org/mailman/listinfo/python-list
Re: why does memory consumption keep growing?
Chris Angelico wrote: > On Fri, Oct 6, 2017 at 4:14 PM, Gregory Ewing > wrote: >> Steve D'Aprano wrote: >>> >>> Plus the downtime and labour needed to install the memory, if the >>> computer will even take it. >> >> >> Obviously we need an architecture that supports hot-swappable >> robot-installable RAM. >> > > Cloud computing is the answer. It's raining RAM! Hallelujah! It's raining RAM! Aye mem! > If you don't believe me, just watch the sky for a while - new clouds > get added without the sky turning off and on again. > > ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On Fri, 6 Oct 2017 12:37 pm, Ben Bacarisse wrote:
>> But in fairness, if the author of the `sort` command had a commitment to
>> friendliness in their programs, they could have `sort` only print a message
>> when it is reading from stdin and writing to stdout,
>
> I think you mean "when reading from a terminal". In the example given
> sort /is/ reading from stdin and writing to stdout.
Indeed I did, it was a slip of the brain.
What are the right ways for a Python script to detect these sorts of
situations?
(1) Standard input is coming from a pipe;
(2) Stdin is being read from a file;
(3) Stdin is coming from a human at a terminal;
I get these. How did I do?
# 1 detect input coming from a pipe.
import sys
import os
from stat import S_ISFIFO
if S_ISFIFO(os.fstat(0).st_mode):
print("Reading from a pipe")
# 2 detect input coming from a regular file.
from stat import S_ISREG
if S_ISREG(os.fstat(0).st_mode):
print("Reading from a file.")
# 3 detect a terminal, hopefully with a human typing at it
if os.isatty(0):
print("Oy noddy, wake up and type something, I'm waiting for you!")
I feel a bit weird about using the magic constant 0 here. Is that guaranteed
to be stdin on all platforms? Or should I be using sys.stdin.fileno()?
--
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: stop/start windows services -python command
On 6 October 2017 at 04:52, Prabu T.S. wrote: > On Thursday, October 5, 2017 at 9:00:19 PM UTC-4, MRAB wrote: >> On 2017-10-06 01:37, Prabu T.S. wrote: >> > On Thursday, October 5, 2017 at 8:33:02 PM UTC-4, MRAB wrote: >> >> On 2017-10-05 23:32, Prabu T.S. wrote: >> >> > On Thursday, October 5, 2017 at 6:16:44 PM UTC-4, Prabu T.S. wrote: >> >> >> hello all,what is the command to stop and start windows services ? >> >> >> i can't install win32serviceutil bec am using latest python version. >> >> > >> >> > Please advice on this >> >> > >> >> Ask Google: windows services start stop command line >> > >> > asking for python. >> > >> Again, ask Google: windows services start stop python >> >> Those results talk about "win32serviceutil", which is not part of the >> standard library, but part of pywin32, which you can download. > > i tried pywin32, but its not compatible with python 3.6. Is there anyway i > can implement start and stop services in python 3.6 version. pywin32 *is* available for Python 3.6. Either from https://sourceforge.net/projects/pywin32/files/pywin32/Build%20220/ (a wininst installer, which is not compatible with pip but which nevertheless can be installed in your system Python) or from http://www.lfd.uci.edu/~gohlke/pythonlibs/ which hosts a lot of wheels for Windows,or as pypiwin32 from PyPI (https://pypi.python.org/pypi/pypiwin32/220). It's possible to find at least some of these via Google searches, too. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On Fri, Oct 6, 2017 at 7:09 PM, Steve D'Aprano
wrote:
> What are the right ways for a Python script to detect these sorts of
> situations?
>
> (1) Standard input is coming from a pipe;
>
> (2) Stdin is being read from a file;
>
> (3) Stdin is coming from a human at a terminal;
>
> I get these. How did I do?
>
> # 3 detect a terminal, hopefully with a human typing at it
> if os.isatty(0):
> print("Oy noddy, wake up and type something, I'm waiting for you!")
This ought to be the only one that matters. It's the closest thing you
have to "we're working in interactive mode". Generally speaking, you
shouldn't care about the difference between a pipe and a file; and
remember, you can have stdin be anything else, too (eg a Unix or TCP
socket).
> I feel a bit weird about using the magic constant 0 here. Is that guaranteed
> to be stdin on all platforms? Or should I be using sys.stdin.fileno()?
I believe it is. At any rate, any system that doesn't have 0/1/2 =
in/out/err is likely to have far more differences than this sort of
thing will cope with, so you won't be able to support it that easily.
So go ahead and assume.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On 2017-10-06 08:09, Steve D'Aprano wrote:
> What are the right ways for a Python script to detect these sorts of
> situations?
>
> (1) Standard input is coming from a pipe;
>
> (2) Stdin is being read from a file;
>
> (3) Stdin is coming from a human at a terminal;
>
> I get these. How did I do?
>
>
> # 1 detect input coming from a pipe.
> import sys
> import os
> from stat import S_ISFIFO
> if S_ISFIFO(os.fstat(0).st_mode):
> print("Reading from a pipe")
>
>
> # 2 detect input coming from a regular file.
> from stat import S_ISREG
> if S_ISREG(os.fstat(0).st_mode):
> print("Reading from a file.")
>
> # 3 detect a terminal, hopefully with a human typing at it
> if os.isatty(0):
> print("Oy noddy, wake up and type something, I'm waiting for you!")
I'd do it the same way.
> I feel a bit weird about using the magic constant 0 here. Is that guaranteed
> to be stdin on all platforms?
It is guaranteed on POSIX compatible OSs. I think it is also guaranteed
on Windows, Don't know about VMS or the IBM OSs.
> Or should I be using sys.stdin.fileno()?
I'm not conviced that this is much more portable: A platform where stdin
doesn't use file descriptor 0 under the hood might not even use simple
integers as file descriptors at all.
hp
--
_ | Peter J. Holzer| Fluch der elektronischen Textverarbeitung:
|_|_) || Man feilt solange an seinen Text um, bis
| | | h...@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
--
https://mail.python.org/mailman/listinfo/python-list
Re: why does memory consumption keep growing?
On 6 October 2017 at 06:51, Chris Angelico wrote: > Cloud computing is the answer. > > If you don't believe me, just watch the sky for a while - new clouds > get added without the sky turning off and on again. The sky reboots every 24 hours, and the maintenance window's about 8-12 hours. Not exactly high availability. But apparently in the arctic regions they are experimenting with a 24x7 version of the sky for short periods of the year... Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On 6 October 2017 at 09:36, Peter J. Holzer wrote:
> On 2017-10-06 08:09, Steve D'Aprano wrote:
>> What are the right ways for a Python script to detect these sorts of
>> situations?
>>
>> (1) Standard input is coming from a pipe;
>>
>> (2) Stdin is being read from a file;
>>
>> (3) Stdin is coming from a human at a terminal;
>>
>> I get these. How did I do?
>>
>>
>> # 1 detect input coming from a pipe.
>> import sys
>> import os
>> from stat import S_ISFIFO
>> if S_ISFIFO(os.fstat(0).st_mode):
>> print("Reading from a pipe")
>>
>>
>> # 2 detect input coming from a regular file.
>> from stat import S_ISREG
>> if S_ISREG(os.fstat(0).st_mode):
>> print("Reading from a file.")
>>
>> # 3 detect a terminal, hopefully with a human typing at it
>> if os.isatty(0):
>> print("Oy noddy, wake up and type something, I'm waiting for you!")
>
> I'd do it the same way.
>
>> I feel a bit weird about using the magic constant 0 here. Is that guaranteed
>> to be stdin on all platforms?
>
> It is guaranteed on POSIX compatible OSs. I think it is also guaranteed
> on Windows, Don't know about VMS or the IBM OSs.
All of these work on Windows, I just tested. Which surprised me, as I
thought things like S_ISFIFO were Unix specific. Today I learned...
(I'd probably still use sys.stdin.fileno() as it's more
self-documenting).
Paul
--
https://mail.python.org/mailman/listinfo/python-list
Re: why does memory consumption keep growing?
On 10/05/2017 05:42 PM, Fetchinson . via Python-list wrote: On 10/5/17, Chris Angelico wrote: On Fri, Oct 6, 2017 at 8:06 AM, Fetchinson . via Python-list wrote: import mystuff mystuff.some_more_expensive_stuff( x ) del mystuff del x You're not actually deleting anything. When you say "del x", all you're doing is removing the *name* x. Especially, deleting an imported module basically does nothing; it's a complete waste of time. Modules are kept in their own special cache. Meaning that if mystuff has some leaky stuff in it, there is no way for me to recover? Even if deleting mystuff actually removed it the objects that it created would still exist. Import mystuff once at the top of your script. Importing over and over just costs CPU and could, in fact, be contributing to your leak. Also, I am pretty sure that the two del statements don't do anything that ending the loop doesn't already do anyway. Your best option is to find the leak. -- D'Arcy J.M. Cain Vybe Networks Inc. http://www.VybeNetworks.com/ IM:da...@vex.net VoIP: sip:da...@vybenetworks.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
Chris Angelico :
> On Fri, Oct 6, 2017 at 7:09 PM, Steve D'Aprano
> wrote:
>> What are the right ways for a Python script to detect these sorts of
>> situations?
>>
>> (1) Standard input is coming from a pipe;
>> (2) Stdin is being read from a file;
>> (3) Stdin is coming from a human at a terminal;
>>
>> I get these. How did I do?
>>
>> # 3 detect a terminal, hopefully with a human typing at it
>> if os.isatty(0):
>> print("Oy noddy, wake up and type something, I'm waiting for you!")
>
> This ought to be the only one that matters. It's the closest thing you
> have to "we're working in interactive mode". Generally speaking, you
> shouldn't care about the difference between a pipe and a file; and
> remember, you can have stdin be anything else, too (eg a Unix or TCP
> socket).
Generally, you shouldn't condition the program too much on such
environmental details, although it is done. For example, the "ls"
command outputs the directory listing in a (colorful) multi-column
format when stdout is a terminal and in a (b/w) one-file-per-line format
otherwise.
Since such guesswork often goes wrong, the program should provide
command-line options to specify the operating mode explicitly. The "ls"
command has "--color" and "--format". The "ssh" command has "-o
BatchMode=yes" and so on.
Again, the Unix way is to preferably stay silent by default. If you want
the program to chat, there is "--verbose".
Marko
--
https://mail.python.org/mailman/listinfo/python-list
Re: Suggestions on storing, caching, querying json
On Thursday, 5 October 2017 15:13:43 UTC+11, Sayth Renshaw wrote: > HI > > Looking for suggestions around json libraries. with Python. I am looking for > suggestions around a long term solution to store and query json documents > across many files. > > I will be accessing an api and downloading approx 20 json files from an api a > week. Having downloaded this year I have over 200 files already. So it will > grow at a reasonable rate. > > What I have initially done is store them into a mongo db. Now I am wondering > if this is useful or prudent since other than querying the json I wont have > much use of other mongo features. > > When querying the json files though queries will utilise multiple json files > at once, not just retrieving a single record. The usage is for data analysis. > > Is there a good json storage option, with caching and optimal querying etc. > > Regarding querying I did find a library for json searching called ObjectPath > written in Python http://objectpath.org/reference.html > > Looking to leverage your experience. > > Cheers > > Sayth There is a new extension for redis ReJson and redis-py for using redis and python as a json store. http://rejson.io/ and https://github.com/andymccurdy/redis-py. Not sure if this has much more upside than mongo other than having a more fmailiar query language like JsonPath http://rejson.io/path/ Cheers Sayth -- https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On 6 October 2017 at 10:14, Marko Rauhamaa wrote: > Generally, you shouldn't condition the program too much on such > environmental details, although it is done. For example, the "ls" > command outputs the directory listing in a (colorful) multi-column > format when stdout is a terminal and in a (b/w) one-file-per-line format > otherwise. Agreed that any behaviour of the program should be explicitly controllable by command line arguments and/or configuration. But IMO, it's perfectly OK for the *default* behaviour to be affected by the environment, as long as that's done in a way that provides a good user experience. Of course, what constitutes a "good UX" is a judgement call... (Personally I think ls goes too far in how different it is in the interactive case, for example). Paul > > Since such guesswork often goes wrong, the program should provide > command-line options to specify the operating mode explicitly. The "ls" > command has "--color" and "--format". The "ssh" command has "-o > BatchMode=yes" and so on. > > Again, the Unix way is to preferably stay silent by default. If you want > the program to chat, there is "--verbose". > > > Marko > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
Re: stop/start windows services -python command
On Thu, 05 Oct 2017 17:37:11 -0700, Prabu T.S. wrote: > On Thursday, October 5, 2017 at 8:33:02 PM UTC-4, MRAB wrote: >> On 2017-10-05 23:32, Prabu T.S. wrote: >> > On Thursday, October 5, 2017 at 6:16:44 PM UTC-4, Prabu T.S. wrote: >> >> hello all,what is the command to stop and start windows services ? i >> >> can't install win32serviceutil bec am using latest python version. >> > >> > Please advice on this >> > >> Ask Google: windows services start stop command line > > asking for python. if you know the command line call to shut down the service then you can use the subprocess module to call it -- In the long run, every program becomes rococco, and then rubble. -- Alan Perlis -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 06/10/2017 02:07, Steve D'Aprano wrote: On Fri, 6 Oct 2017 09:57 am, Marko Rauhamaa wrote: Waiting for input isn't "hangs". That's an ignorant and foolish thing to say, more suited for a wet-behind-the-ears newbie than somebody who claims to be a long-time old-school programmer. That's what it looks like. Is it doing something, or waiting for me to do something, or did it just hang? The Unix commandline interface is not designed to be user-friendly for newbies (or experts, for that matter). It is terse, often *painfully* so (would it have killed the author to have spelled `umount` correctly?), the UI is inconsistent, and it has a very steep learning curve -- a lot of effort is required to make a little bit of progress. OK. I'm not out to change Unix (not right now). But this style of utility was suggested as a way to write interactive input loops in Python programs, which you might expect to be friendlier. That it is, to assume from the outset that you're reading from a file, not a keyboard. And the user typing in data also has to pretend they are entering data in a file, complete with an EOF marker. That is what I object to. It is anyway not really acceptable these days for a long list of data to simply be typed in like that without any feedback at all. And 100% dependent on your typing Ctrl-D at the end and not Ctrl-C by mistake. This is not still the 1970s. But in fairness, if the author of the `sort` command had a commitment to friendliness in their programs, they could have `sort` only print a message when it is reading from stdin and writing to stdout, much as `ls` defaults to outputting control characters but automatically swaps to replacing them with ? when writing to a terminal. Surely this is a common problem that has long since been solved? You have a interactive program - even with proper prompts and feedback - and one day you want to run it as a script. (And properly, by being given the same of an actual file rather than using crude redirection.) But you don't want hundreds of dialogue lines scrolling up the screen while it's doing so. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
Chris Angelico writes:
> On Fri, Oct 6, 2017 at 7:09 PM, Steve D'Aprano
> wrote:
>> What are the right ways for a Python script to detect these sorts of
>> situations?
>>
>> (1) Standard input is coming from a pipe;
>>
>> (2) Stdin is being read from a file;
>>
>> (3) Stdin is coming from a human at a terminal;
>>
>> I get these. How did I do?
>>
>> # 3 detect a terminal, hopefully with a human typing at it
>> if os.isatty(0):
>> print("Oy noddy, wake up and type something, I'm waiting for you!")
>
> This ought to be the only one that matters. It's the closest thing you
> have to "we're working in interactive mode". Generally speaking, you
> shouldn't care about the difference between a pipe and a file; and
> remember, you can have stdin be anything else, too (eg a Unix or TCP
> socket).
Yes. I'd say the key differences is whether the input is seekable or
not. A program might legitimately choose different algorithms based on
that property of the input, but whether it's an actual file or an actual
pipe is less likely to be interesting.
>> I feel a bit weird about using the magic constant 0 here. Is that guaranteed
>> to be stdin on all platforms? Or should I be using
>> sys.stdin.fileno()?
A general solution to the (rather odd) complaint about silent waiting
should really check any input fileno to see if a prompt is needed. You
could argue, though, that anyone who's re-arranged a program's input so
that some non-zero input fileno is attached to a terminal won't need the
prompt!
--
Ben.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On Fri, 6 Oct 2017 09:33 pm, Ben Bacarisse wrote: > A general solution to the (rather odd) complaint about silent waiting > should really check any input fileno to see if a prompt is needed. You > could argue, though, that anyone who's re-arranged a program's input so > that some non-zero input fileno is attached to a terminal won't need the > prompt! I'm afraid I don't quite know if I'm understanding you or not. I think you mean to say I should look at sys.stdin.fileno(), and if it is 0, then write a prompt, and if not, just read from stdin (possibly blocking, waiting for input). Is that right? But aren't there circumstances where fileno 0 isn't attached to a terminal, and writing a prompt would be inappropriate? -- 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: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On Fri, Oct 6, 2017 at 9:48 AM, Paul Moore wrote:
> On 6 October 2017 at 09:36, Peter J. Holzer wrote:
>> On 2017-10-06 08:09, Steve D'Aprano wrote:
>>
>>> # 1 detect input coming from a pipe.
>>> import sys
>>> import os
>>> from stat import S_ISFIFO
>>> if S_ISFIFO(os.fstat(0).st_mode):
>>> print("Reading from a pipe")
>>>
>>> # 2 detect input coming from a regular file.
>>> from stat import S_ISREG
>>> if S_ISREG(os.fstat(0).st_mode):
>>> print("Reading from a file.")
>>>
>>> # 3 detect a terminal, hopefully with a human typing at it
>>> if os.isatty(0):
>>> print("Oy noddy, wake up and type something, I'm waiting for you!")
[...]
> All of these work on Windows, I just tested. Which surprised me, as I
> thought things like S_ISFIFO were Unix specific. Today I learned...
The fstat implementation for Windows calls GetFileType to look for
FILE_TYPE_CHAR (i.e. S_IFCHR) and FILE_TYPE_PIPE (i.e. S_IFIFO).
The C runtime's isatty() on Windows checks for for a character device,
not a console. If we're using this to test for interactive mode, we'll
get a false positive on Windows if StandardInput is redirected to the
DOS "NUL" device (i.e. NT "\Device\Null") or a COM port (rarely).
As to using fd 0 instead of stdin.fileno(), for a non-console process
(e.g. pythonw.exe), the C runtime doesn't initialize the standard file
descriptors beyond their static definitions, and isatty(0) will return
true even though it's not a valid file descriptor (i.e. the mapped
Windows handle is INVALID_HANDLE_VALUE). We need to rely on the C
stdin FILE stream being invalid, in which case sys.stdin is set to
None.
--
https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 05/10/17 19:45, bartc wrote: Yes, I tried typing 'sort' in Linux, where it apparently hangs (same on Windows actually). The reason: because it might have killed someone to have added a message saying what you are expected to type and how to end it. (Namely, press Ctrl-D start at the start of a line in Linux, and Ctrl-Z followed by Enter, I think also at the start, in Windows.) Actually it might. Linux tools are written not to assume that stdin and stdout are the console, because they frequently aren't. Extra puff written to stdout at best makes it harder to use in a pipeline, and at worst makes it useless; tools that do that tend not to get used. -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Re: why does memory consumption keep growing?
On Fri, Oct 6, 2017 at 8:05 PM, D'Arcy Cain wrote: > On 10/05/2017 05:42 PM, Fetchinson . via Python-list wrote: >> >> On 10/5/17, Chris Angelico wrote: >>> >>> On Fri, Oct 6, 2017 at 8:06 AM, Fetchinson . via Python-list >>> wrote: import mystuff mystuff.some_more_expensive_stuff( x ) del mystuff del x >>> >>> You're not actually deleting anything. When you say "del x", all >>> you're doing is removing the *name* x. Especially, deleting an >>> imported module basically does nothing; it's a complete waste of time. >>> Modules are kept in their own special cache. >> >> >> Meaning that if mystuff has some leaky stuff in it, there is no way >> for me to recover? > > > Even if deleting mystuff actually removed it the objects that it created > would still exist. Import mystuff once at the top of your script. Importing > over and over just costs CPU and could, in fact, be contributing to your > leak. Importing an already-imported module is as simple as: mystuff = sys.modules["mystuff"] So it's not contributing to the leak, but it's also not helping anything. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On Fri, Oct 6, 2017 at 8:27 PM, Paul Moore wrote: > On 6 October 2017 at 10:14, Marko Rauhamaa wrote: >> Generally, you shouldn't condition the program too much on such >> environmental details, although it is done. For example, the "ls" >> command outputs the directory listing in a (colorful) multi-column >> format when stdout is a terminal and in a (b/w) one-file-per-line format >> otherwise. > > Agreed that any behaviour of the program should be explicitly > controllable by command line arguments and/or configuration. But IMO, > it's perfectly OK for the *default* behaviour to be affected by the > environment, as long as that's done in a way that provides a good user > experience. Of course, what constitutes a "good UX" is a judgement > call... (Personally I think ls goes too far in how different it is in > the interactive case, for example). Yeah, agreed. That said, though, there are even more ways for interactive mode to be configured. Your .bashrc quite probably has something like: alias ls='ls --color=auto' So if you type "ls" at the shell prompt, you get colour, but if you type "/bin/ls", you don't. The "=auto" part does what you're saying (using the tty-ness of stdout to control whether or not colour is used), but it's not even active unless you're using bash aliases. Generally, you should not have to worry about the behaviour of a program being drastically different if you append "| cat" to the command line. Which means you don't want TOO much difference between interactive mode and non-interactive mode, which in turn limits the extent of these changes to the defaults. It wants to be small changes only. Everything else should be controlled with options, not magic. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 06/10/2017 12:04, Rhodri James wrote: On 05/10/17 19:45, bartc wrote: Yes, I tried typing 'sort' in Linux, where it apparently hangs (same on Windows actually). The reason: because it might have killed someone to have added a message saying what you are expected to type and how to end it. (Namely, press Ctrl-D start at the start of a line in Linux, and Ctrl-Z followed by Enter, I think also at the start, in Windows.) Actually it might. Linux tools are written not to assume that stdin and stdout are the console, because they frequently aren't. Extra puff written to stdout at best makes it harder to use in a pipeline, and at worst makes it useless; tools that do that tend not to get used. A lot of people aren't getting it. The internal utilities used within an operating system, primarily intended for file or redirected i/o with no live interaction, should be distinct from those designed to be used directly with a live user. Or is it against the rules of Unix to have two different versions of a program? Then you might have 'sort' for the non-interactive version, and 'isort' or whatever for the interactive. Except you simply wouldn't use an interactive version of any program that reads an arbitrary long list of uninterrupted data, no matter how the ending is indicated. You'd use a text editor, enter the lines at your leisure, go back and forth to check and edit as needed, THEN you would submit that file to 'sort'. As an actual input file. So I can't see the point of using that same pattern of input usage (reading from stream, file, pipe whatever until interrupted with an EOF signal) for a true interactive program that is used in a sensible manner. (Say, an FTP program, which has a prompt, lots of commands, and usually instant feedback. An actual dialogue. A program like 'python' might fit the bill too. Here, you can give it the name of a file, OR say nothing, and it will take input from stdin. Funnily enough, you now get a message, and a prompt. And when entering multiple lines of code, you get a prompt before each line. You can also terminate the sequence by entering a blank line. So it IS possible to do it properly after all!) -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On Fri, Oct 6, 2017 at 9:32 PM, bartc wrote: > (And properly, by being given the same of an actual file rather than using > crude redirection.) Why do you call redirection "crude"? Do you not understand the value of generic solutions that work with all programs, rather than having every program implement its own "take input from file" parameter? You can disagree with the Unix philosophy all you like, but when you insult it, you just make yourself look like an idiot. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On Fri, Oct 6, 2017 at 10:41 PM, bartc wrote: > On 06/10/2017 12:04, Rhodri James wrote: >> >> On 05/10/17 19:45, bartc wrote: >>> >>> Yes, I tried typing 'sort' in Linux, where it apparently hangs (same on >>> Windows actually). The reason: because it might have killed someone to have >>> added a message saying what you are expected to type and how to end it. >>> (Namely, press Ctrl-D start at the start of a line in Linux, and Ctrl-Z >>> followed by Enter, I think also at the start, in Windows.) >> >> >> Actually it might. Linux tools are written not to assume that stdin and >> stdout are the console, because they frequently aren't. Extra puff written >> to stdout at best makes it harder to use in a pipeline, and at worst makes >> it useless; tools that do that tend not to get used. > > > A lot of people aren't getting it. > > The internal utilities used within an operating system, primarily intended > for file or redirected i/o with no live interaction, should be distinct from > those designed to be used directly with a live user. > > Or is it against the rules of Unix to have two different versions of a > program? > > Then you might have 'sort' for the non-interactive version, and 'isort' or > whatever for the interactive. > > Except you simply wouldn't use an interactive version of any program that > reads an arbitrary long list of uninterrupted data, no matter how the ending > is indicated. You'd use a text editor, enter the lines at your leisure, go > back and forth to check and edit as needed, THEN you would submit that file > to 'sort'. As an actual input file. > > So I can't see the point of using that same pattern of input usage (reading > from stream, file, pipe whatever until interrupted with an EOF signal) for a > true interactive program that is used in a sensible manner. What you REALLY mean is that you can't see the point of an interactive sort command. It doesn't fit into your workflow. And that's fine. It's not something you'd use very often. There are other programs, however, that behave exactly the same whether used in batch mode or interactive mode, and where you would do exactly the same thing as I described - provide input, and hit Ctrl-D to mark that you're done. And since every one of these programs is written to read from stdin until EOF, you can use them all in exactly the same way - type at keyboard, hit Ctrl-D when done. > A program like 'python' might fit the bill too. Here, you can give it the > name of a file, OR say nothing, and it will take input from stdin. > > Funnily enough, you now get a message, and a prompt. And when entering > multiple lines of code, you get a prompt before each line. You can also > terminate the sequence by entering a blank line. > > So it IS possible to do it properly after all!) Actually, Python's interactive mode is completely different from its file input mode. You're not really comparing like things here. Python's incremental interpreter is *by nature* interactive, and redirecting its input does not produce the same result as running "python3 filename.py" would. Can you find yourself a better example? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On 6 October 2017 at 12:42, Chris Angelico wrote: > Generally, you should not have to worry about the behaviour of a > program being drastically different if you append "| cat" to the > command line. Which means you don't want TOO much difference between > interactive mode and non-interactive mode, which in turn limits the > extent of these changes to the defaults. It wants to be small changes > only. Everything else should be controlled with options, not magic. Yep. My real beef with ls is multi-column vs single-column. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On Fri, 6 Oct 2017 11:11 pm, Paul Moore wrote: > On 6 October 2017 at 12:42, Chris Angelico wrote: >> Generally, you should not have to worry about the behaviour of a >> program being drastically different if you append "| cat" to the >> command line. Which means you don't want TOO much difference between >> interactive mode and non-interactive mode, which in turn limits the >> extent of these changes to the defaults. It wants to be small changes >> only. Everything else should be controlled with options, not magic. > > Yep. My real beef with ls is multi-column vs single-column. > Paul You don't think multiple columns in interactive mode is useful? I'm surprised, because I find it invaluable. I would hate for `ls` to default to printing everything in one long column. I suppose I could define an alias, but then every time I'm on a different computer or running as a different user, I'd end up with the annoying default single column again. -- 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: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On 2017-10-06 12:33, Ben Bacarisse wrote:
> Chris Angelico writes:
>
>> On Fri, Oct 6, 2017 at 7:09 PM, Steve D'Aprano
>> wrote:
>>> What are the right ways for a Python script to detect these sorts of
>>> situations?
>>>
>>> (1) Standard input is coming from a pipe;
>>>
>>> (2) Stdin is being read from a file;
>>>
>>> (3) Stdin is coming from a human at a terminal;
>>>
>>> I get these. How did I do?
>>>
>>> # 3 detect a terminal, hopefully with a human typing at it
>>> if os.isatty(0):
>>> print("Oy noddy, wake up and type something, I'm waiting for you!")
>>
>> This ought to be the only one that matters. It's the closest thing you
>> have to "we're working in interactive mode". Generally speaking, you
>> shouldn't care about the difference between a pipe and a file; and
>> remember, you can have stdin be anything else, too (eg a Unix or TCP
>> socket).
>
> Yes. I'd say the key differences is whether the input is seekable or
> not. A program might legitimately choose different algorithms based on
> that property of the input, but whether it's an actual file or an actual
> pipe is less likely to be interesting.
>
>>> I feel a bit weird about using the magic constant 0 here. Is that guaranteed
>>> to be stdin on all platforms? Or should I be using
>>> sys.stdin.fileno()?
>
> A general solution to the (rather odd) complaint about silent waiting
> should really check any input fileno to see if a prompt is needed. You
> could argue, though, that anyone who's re-arranged a program's input so
> that some non-zero input fileno is attached to a terminal won't need the
> prompt!
stdin is ALWAYS fileno 0, whether the input is attached to a tty or not.
The only situation where sys.stdin.fileno() != 0 is when sys.stdin has
been reassigned from within python.
$ python -c 'import sys; print(sys.stdin.fileno())' < /dev/zero
0
This should be true for all platforms, or at least all platforms python
supports.
>
>
>
--
Thomas Jollans
--
https://mail.python.org/mailman/listinfo/python-list
Re: How to determine lowest version of Python 3 to run?
On Oct 5, 2017, at 3:34 PM, Christopher Reimer wrote: > >> On Oct 5, 2017, at 1:11 PM, Irmen de Jong wrote: >> >>> On 10/05/2017 04:23 AM, Christopher Reimer wrote: >>> >>> I'm leaning towards installing the latest minor version of each available >>> major version, running tox to run the unit tests against each one, and >>> seeing what blows up. >> >> Perhaps you can use the service of Travis (travis-ci.org) to avoid >> installing the Python >> versions yourself. They have lots of older versions available to run tests >> on. >> >> Irmen >> -- >> https://mail.python.org/mailman/listinfo/python-list > > Travis might be a bit of an overkill for my project. Someone suggested docker > containers and there is a docker plugin for tox that looks promising. > > Chris R. > -- > https://mail.python.org/mailman/listinfo/python-list So I got tox and tox-docker installed. When I went to install Docker for Windows, it wouldn't work because Hyper-V wasn't available on Windows 10 Home. After paying Microsoft $99 for the privilege, I got Windows 10 Pro installed and Docker started working. I've read that all the cool programming kids are using Docker these days. I certainly hope it was worth the cost. O_o Chris R. -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 06/10/2017 12:51, Chris Angelico wrote: On Fri, Oct 6, 2017 at 10:41 PM, bartc wrote: > What you REALLY mean is that you can't see the point of an interactive > sort command. It doesn't fit into your workflow. And that's fine. It's > not something you'd use very often. There are other programs, however, > that behave exactly the same whether used in batch mode or interactive > mode, and where you would do exactly the same thing as I described - > provide input, and hit Ctrl-D to mark that you're done. Examples? And is there any reason why you wouldn't use a text editor to capture your input first? I can see myself noticing an error I'd made 10 lines up, which is now too late to change, and I've still got 100 lines to go. What to do? I just can't anyone wanting to use programs that work in the way you suggest. Not outside of a student exercise (read N numbers and display the average), where getting the input correct isn't so important. > And since > every one of these programs is written to read from stdin until EOF, > you can use them all in exactly the same way - type at keyboard, hit > Ctrl-D when done. So they're all at it! That doesn't mean it's a good way of doing things. So it IS possible to do it properly after all!) Actually, Python's interactive mode is completely different from its file input mode. You're not really comparing like things here. Python's incremental interpreter is *by nature* interactive, and redirecting its input does not produce the same result as running "python3 filename.py" would. Can you find yourself a better example? I gave the FTP example. (Which actually, in my version, doesn't work properly when trying redirect input into it. You have to give an actual file name.) But what's wrong with the Python example? It detects when it's given a file (as as actual parameter, or redirected), and when it's used interactively, and adapts its behaviour accordingly. It just needs a bit of effort. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Introducing the "for" loop
On Thu, Oct 5, 2017 7:45 PM, breamore...@gmail.com wrote: > On Friday, October 6, 2017 at 2:05:58 AM UTC+1, Irv Kalb wrote: >> >> The range function is discussed after that. >> > >FWIW range isn't a function in Python 3. From https://docs.python.org/3/library/functions.html#func-range "Rather than being a function, range is actually an immutable sequence type, as documented in Ranges and Sequence Types ? list, tuple, range.". > > > Despite the documentation, I would still be tempted to say that range is a function. Taking duck-typing to the meta-level, every time I use range, I use its name followed by a pair of parentheses enclosing one to three parameters, and I get back an immutable sequence object. It sure looks like a function to me. I would similarly say that map is a function, or an iterator generator I write myself with yield statements is a function, both of which also return sequences. It is not clear to me what the difference really is between my conception and the official definition -- is it a question about whether it returns a first-class object? Or more simply, what is the clear and obvious distinction that I can give to my non-scientific laypeople about why range isn't a function, if it looks like one? Oh, and since I think this was snipped from the thread mentioning textbook usage, I'll just toss in my note that I am using an on-line textbook developed by zyBooks.com, and those guys are nice enough to actually collaborate with the instructor about what goes into the text, and in what order. I actually like that they choose to present lists and dictionaries before any control structures, because a lot of interesting simple programming problems can be solved by making use of those structures -- like simple table-lookup applications. A C++ teacher really cannot present arrays before control structures, because there is nothing in the language to manipulate the arrays (without appealing to the libraries). But with these objects as built-in's, we can encourage nice and simple code without unnecessarily complicated control structures. Unfortunately, it seems the zyBooks authors still succumb to the same temptations as any other programmer who learned control structures before data structures. Soon after introducing those control structures, they have an exercise to do a string translation, using an ugly 12-way if-else construct nested within a loop where a dictionary would very easily trim the if-else and str.translate() would eliminate the loop. (This is fresh in my mind because I plan to illustrate both their solution and mine in my very next class) Roger Christman Pennsylvania State University -- https://mail.python.org/mailman/listinfo/python-list
Re: OT I before E [was Re: Lies in education [was Re: The "loop and a half"]]
On Oct 5, 2017 2:02 PM, "Roel Schroeven" wrote: Thomas Jollans schreef op 5/10/2017 10:30: On 2017-10-05 06:47, Steve D'Aprano wrote: > >> On Thu, 5 Oct 2017 02:54 pm, Chris Angelico wrote: >> >>> (There are exceptions even to the longer form of the rule, but only a >>> handful. English isn't a tidy language.) >>> >> Even with the longer version of the rule, there are so few applicable >> cases, >> and enough difficulty in applying the rule correctly, that the rule is not >> worth the breath it takes to say it. >> > > Maybe we should just all switch to Dutch on this list. Might be easier. > Certainly more consistent. > Although that way may not be obvious at first unless you're Dutch. (or Flemish) There are a lot of exceptions, weird rules and other difficulties in Dutch as well; we native speakers just don't notice them that much. -- The saddest aspect of life right now is that science gathers knowledge faster than society gathers wisdom. -- Isaac Asimov Roel Schroeve Esperanto. https://en.m.wikipedia.org/wiki/Esperanto_grammar Thanks, Cem Karan -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 06/10/2017 12:45, Chris Angelico wrote: On Fri, Oct 6, 2017 at 9:32 PM, bartc wrote: (And properly, by being given the same of an actual file rather than using crude redirection.) Why do you call redirection "crude"? Do you not understand the value of generic solutions that work with all programs, rather than having every program implement its own "take input from file" parameter? You can disagree with the Unix philosophy all you like, but when you insult it, you just make yourself look like an idiot. Redirection is used on Windows too. I use output redirection quite frequently (to capture the output of 'dir' for example). I don't rely on > and < in my own programs. Where there's complex, mixed output, the bulk of it - the data - needs to go to a proper file, while the screen shows messages. If you don't like the word 'crude', try 'lazy'. Take this example of the gcc C compiler: > gcc -E program.c This preprocesses the code and shows the result. Typical programs will have many thousands of lines of output, but it just dumps it to the console. You /have/ to use '>' to use it practically (Windows doesn't really have a working '|' system.) Another compiler might simply write the output to a file 'program.i'. BTW if I try: > gcc https://mail.python.org/mailman/listinfo/python-list
Re: Pedagogical style [was Re: The "loop and a half"]
On Thu, Oct 5, 2017 8:18 PM, Ben Bacarisse wrote: > Steve D'Aprano writes: > >> There's no link to the original paper, only to secondary sources that discuss >> it, e.g.: >> >> http://phys.org/pdf128266927.pdf > > >> [1] Anecdotes are not data, but for what it is worth, just in the last two >> days I came across two examples of this. Teaching a boy in Year 10 maths >> about logarithms, he struggled with purely algebraic questions involving >> solving exponential equations by using logs, but when given a concrete >> problem involving an investment he was able to solve it immediately. >> >> The second example involved a girl in Year 8 maths, who again struggled with >> abstract questions about adding and multiplying fractions. In particular, she >> overgeneralised from fraction multiplication to addition, thinking that 1/4 + >> 1/4 must add to 2/8. But when put into concrete geometric terms, showing >> physical shapes divided into quarters, she could instantly tell that 1/4 plus >> 1/4 must be 1/2. >> >> As I said, anecdotes are not data, but when research claims to show that >> apples fall upwards in contradiction to anecdotal evidence that they fall >> downwards, we would be wise to be cautious before accepting the research as >> fact. > >I think the paper is this one: > >http://faculty.psy.ohio-state.edu/sloutsky/pdf/KSH-published.pdf > >(You can find more recent papers by searching the Ohio State University >site.) > >>From what I've read, your anecdotes are not in contradiction to the >paper's claims. > > Thank you for finding the paper, since I too was skeptical that the abstraction-first approach would really he profitable. I remember all those years in the public schools where everyone dreaded the 'word problems' in the math text. The abstractions rarely translated intuitively into the concrete for many of my classmates. And after reading this paper, I remain skeptical about its results. I cannot help but think that the experiment it constructs is inherently flawed. The claim is that this is an exercise in equivalence classes, obeying the same rules as modulo-3 arithmetic. There is the symbolic abstract model with the circles and diamonds, the fabricated children's game, and the 'concrete' problems with the liquid containers (shown in the paper), tennis balls, and pizza slices (not explicitly described). The paper argues that those who were given the concrete models to start with did not understand the children's game, simply because they could not transfer their knowledge to the new environment without the abstract thought. That's not a flaw in the student; that's a flaw in the model. Looking at the liquid picture, one can very easily see the concrete values 1, 2, and 3, and can easily recognize the modular arithmetic involved. It sounds to me that the same thing would be true for the tennis balls and pizza slices. And then he tells this group that the children's game is exactly analogous to what they have already experienced. So here they are, all ready to do some more modulo-3 addition, and the rug gets pulled out from under them.There is no visible quantity of 1, 2, or 3 in those circles and diamonds; and probably no 1, 2, or 3 in the children's game either. How is it any surprise that they did not figure out the children's game as quickly? Roger Christman Pennsylvania State University -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 2017-10-06 11:41, bartc wrote: > On 06/10/2017 12:04, Rhodri James wrote: >> On 05/10/17 19:45, bartc wrote: >>> Yes, I tried typing 'sort' in Linux, where it apparently hangs (same >>> on Windows actually). The reason: because it might have killed someone >>> to have added a message saying what you are expected to type and how >>> to end it. (Namely, press Ctrl-D start at the start of a line in >>> Linux, and Ctrl-Z followed by Enter, I think also at the start, in >>> Windows.) >> >> Actually it might. Linux tools are written not to assume that stdin and >> stdout are the console, because they frequently aren't. Extra puff >> written to stdout at best makes it harder to use in a pipeline, and at >> worst makes it useless; tools that do that tend not to get used. > > A lot of people aren't getting it. > > The internal utilities used within an operating system, primarily > intended for file or redirected i/o with no live interaction, should be > distinct from those designed to be used directly with a live user. > > Or is it against the rules of Unix to have two different versions of a > program? > > Then you might have 'sort' for the non-interactive version, and 'isort' > or whatever for the interactive. How would that stop your clueless user from invoking sort and thinking that it hangs? Short of putting it into /usr/lib or so, but that would make it hard to use in a pipe. I can see some merit in the idea that filters could print a short help message when reading from a terminal, but creating a second "interactive" version of each filter with a different name seems to be utterly pointless to me. hp -- _ | Peter J. Holzer| Fluch der elektronischen Textverarbeitung: |_|_) || Man feilt solange an seinen Text um, bis | | | h...@hjp.at | die Satzbestandteile des Satzes nicht mehr __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel -- https://mail.python.org/mailman/listinfo/python-list
Re: Pedagogical style [was Re: The "loop and a half"]
On 2017-10-05, Steve D'Aprano wrote: > In fairness to Stefan, we should also include iteration and > assignment as concepts being learned, but in this case they are > directly connected to the immediate problem rather than at best > only indirectly, and distantly, related. Teaching the iteration protocol before using and being comfortable with iterating creates major burdern. The student doesn't know what it supposed to *do*. On the other hand, if iteration is already second nature, then the protocal can be comprehended, and hopefully understood as a building block of something the student relies on. I had this exact experience learning C++ with Accelerated C++ by Koenig & Moo. Pointers, for example, usually taught long before the STL, here became just another form of random access iterator and the aura of mystery they formerly held in my mind evaporated. > So the bottom line is: > > - Stefan's approach requires the student to learn fifteen concepts > to get poor-quality Python code; > > - the idiomatic approach requires the student to learn five concepts > to get high-quality Python code (for this toy problem). The Koenig & Moo method was to first teach high-level, generalizable tools and much later show how to implement them yourself. I can't think of anything else as correct after having experienced it, but nevertheless other approaches have been used with success for years. And Stefan's way of thinking about and asking questions about Python has been of great interest to me, and provided entertainment and enlightenment. -- Neil Cerutti -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 2017-10-06 12:38, bartc wrote: > On 06/10/2017 12:51, Chris Angelico wrote: > > What you REALLY mean is that you can't see the point of an interactive > > sort command. It doesn't fit into your workflow. And that's fine. It's > > not something you'd use very often. There are other programs, however, > > that behave exactly the same whether used in batch mode or interactive > > mode, and where you would do exactly the same thing as I described - > > provide input, and hit Ctrl-D to mark that you're done. > > Examples? > > And is there any reason why you wouldn't use a text editor to capture > your input first? I can see myself noticing an error I'd made 10 lines > up, which is now too late to change, and I've still got 100 lines to go. > What to do? > > I just can't anyone wanting to use programs that work in the way you > suggest. Not outside of a student exercise (read N numbers and display > the average), where getting the input correct isn't so important. I regularly use at least cat, wc and od this way (plus a few of my own utilities like utf8dump). I'm sure I've used sort this way, too, though rather rarely. I usually don't type the input but paste it in, but the program can't distinguish that: All it sees is some input from the terminal at stdin. hp -- _ | Peter J. Holzer| Fluch der elektronischen Textverarbeitung: |_|_) || Man feilt solange an seinen Text um, bis | | | h...@hjp.at | die Satzbestandteile des Satzes nicht mehr __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel -- https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On 6 October 2017 at 13:22, Steve D'Aprano wrote: >> Yep. My real beef with ls is multi-column vs single-column. >> Paul > > You don't think multiple columns in interactive mode is useful? I'm surprised, > because I find it invaluable. Interactively, I use ls -l 99.9% of the time. When I use raw ls, the column format is OK, but the fact that the number of columns varies depending on the filename length is really annoying (one really long filename can really mess the layout up). > I would hate for `ls` to default to printing everything in one long column. I > suppose I could define an alias, but then every time I'm on a different > computer or running as a different user, I'd end up with the annoying default > single column again. And that's precisely why carefully defining the defaults is both crucial and hard :-) I don't think the designers of ls necessarily got it wrong. But I'm one of the (small, presumably) group who find it sub-optimal. That's OK - you can't please all of the people all of the time and all that :-) What *really* bugs me is colour settings that default to dark blues on a black background. Someone, presumably an admin who set the system up, worked on a light-background system, and defined defaults that are good for them. And which are illegible for every single one of the actual users who have black-background ssh clients. Add the fact that I work on shared admin accounts, where setting non-default preferences is considered an antisocial act (even when they are "better" ;-)) and I spend my life squinting at screens, or typing "unalias ls" to remove the --color setting. Luckily (for everyone who has to listen to me rant), this is "just" annoyingly badly configured systems, and not baked in program defaults. Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: newb question about @property
On 05/10/2017 14:13, Steve D'Aprano wrote: On Thu, 5 Oct 2017 10:51 pm, bartc wrote: Am I allowed to say that it all seems a bit of a mess? You may or may not be pleased to learn that there's a push to create a "record like" or "struct like" datatype for Python 3.7 or 3.8, tentatively called a "Data Class" for now. https://www.python.org/dev/peps/pep-0557/ Yeah, maybe (looks a bit over-ambitious to me; why is it necessary to have typed fields? Or to do relative compares?) But it reminds me a bit of the xkcd cartoon about the 14 competing standards becoming 15... -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 06/10/2017 14:11, Peter J. Holzer wrote:
On 2017-10-06 12:38, bartc wrote:
On 06/10/2017 12:51, Chris Angelico wrote:
What you REALLY mean is that you can't see the point of an interactive
sort command. It doesn't fit into your workflow. And that's fine. It's
not something you'd use very often. There are other programs, however,
that behave exactly the same whether used in batch mode or interactive
mode, and where you would do exactly the same thing as I described -
provide input, and hit Ctrl-D to mark that you're done.
Examples?
And is there any reason why you wouldn't use a text editor to capture
your input first? I can see myself noticing an error I'd made 10 lines
up, which is now too late to change, and I've still got 100 lines to go.
What to do?
I just can't anyone wanting to use programs that work in the way you
suggest. Not outside of a student exercise (read N numbers and display
the average), where getting the input correct isn't so important.
I regularly use at least cat, wc and od this way (plus a few of my own
utilities like utf8dump). I'm sure I've used sort this way, too, though
rather rarely. I usually don't type the input but paste it in,
Exactly. Probably no one ever uses these programs with actual live input
with the possibility of uncorrectable errors getting through.
So not a good reason to use that coding pattern to write programs which
ARE designed for live, interactive input:
print ("Enter blank expression to quit.")
while 1:
buffer=input("Expr: ")
if buffer == "": break
try:
print (eval(buffer))
except:
print ("Error")
print ("Done")
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: Introducing the "for" loop
On 6 October 2017 at 13:44, ROGER GRAYDON CHRISTMAN wrote: > Despite the documentation, I would still be tempted to say that range is a > function. > Taking duck-typing to the meta-level, every time I use range, I use its name > followed > by a pair of parentheses enclosing one to three parameters, and I get back an > immutable sequence object. It sure looks like a function to me. > > I would similarly say that map is a function, or an iterator generator I write > myself > with yield statements is a function, both of which also return sequences. > It is not clear to me what the difference really is between my conception > and the official definition -- is it a question about whether it returns a > first-class object? > > Or more simply, what is the clear and obvious distinction that I can give to > my > non-scientific laypeople about why range isn't a function, if it looks like > one? Technically, range (and the other examples you mentioned) is a "callable". The concept of a callable is closer to the intuitive meaning of "function" than the things Python technically calls functions. And most code accepts callables rather than functions (i.e., there's little if anything that rejects range because it's a callable not a function). Duck typing means that you can take class C: pass c = C() and replace it with class C_impl: pass def C(): return C_impl() c = C() and there's little or no difference. In the first, C is a class. In the second it's a (factory) function. You can tell the difference, via introspection. But it's unlikely you'd care in practice. As to the technical differences, you can use type() to tell: >>> def f(): pass ... >>> class F: pass ... >>> type(f) >>> type(F) >>> type(range) >>> type(map) >>> type(open) Note the last - built in functions are implemented in C, and behave slightly differently than *either* functions or classes. But you're unlikely to ever care. One example: >>> f.attr = 1 >>> open.attr = 1 Traceback (most recent call last): File "", line 1, in AttributeError: 'builtin_function_or_method' object has no attribute 'attr' functions defined in Python can have user-defined attributes, builtins can't. Embrace duck typing, and only care about what you can do, not what type of object you're doing it to ;-) Paul -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 6 October 2017 at 13:56, bartc wrote:
> If you don't like the word 'crude', try 'lazy'. Take this example of the gcc
> C compiler:
>
> > gcc -E program.c
>
> This preprocesses the code and shows the result. Typical programs will have
> many thousands of lines of output, but it just dumps it to the console. You
> /have/ to use '>' to use it practically (Windows doesn't really have a
> working '|' system.)
No you don't. Ignoring the fact that "windows doesn't really have a
working '|' system" (which is an oversimplification, by the way) the
following all work:
Python:
data = subprocess.check_output(["gcc", "-E", "program.c"])
Powershell:
$x = (gcc -E program.c)
cmd:
for /f %i in ('gcc -E program.c') do ...
If gcc -E wrote its output to a file, you'd have to read that file,
manage the process of deleting it after use (and handle possible
deletion of it if an error occurred), etc.
Writing to stdout is very often a good design. Not always, but nothing
is ever 100% black and white, but sufficiently often that building an
OS based on the idea (Unix) was pretty successful :-)
Paul
--
https://mail.python.org/mailman/listinfo/python-list
Re: Good virtualenv and packaging tutorials for beginner?
Leam Hall writes: > Folks on IRC have suggested using virtualenv to test code under > different python versions. Sadly, I've not found a virtualenv tutorial > I understand. Anyone have a link to a good one? I recently used http://www.simononsoftware.com/virtualenv-tutorial-part-2/ to set up one. I was mostly trying to see if I could use it to install current Python 3 to an oldish Debian system. Worked fine. -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 2017-10-06 15:48, Dennis Lee Bieber wrote:
> {Okay -- I've probably inspired someone to create an OS where one uses a
> leading "-" to "undo" the normal action of the following command}
For clarity, I think it should be +mount! and -mount! to mount and
unmount, and +mount? to see what's mounted.
+dir! is mkdir
-dir! is rmdir
dir? is ls
Beautiful.
+move! and -move! do the same thing, but with the arguments reversed.
For clarity.
--
https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 06/10/2017 14:35, Paul Moore wrote:
On 6 October 2017 at 13:56, bartc wrote:
If you don't like the word 'crude', try 'lazy'. Take this example of the gcc
C compiler:
> gcc -E program.c
This preprocesses the code and shows the result. Typical programs will have
many thousands of lines of output, but it just dumps it to the console. You
/have/ to use '>' to use it practically (Windows doesn't really have a
working '|' system.)
No you don't. Ignoring the fact that "windows doesn't really have a
working '|' system" (which is an oversimplification, by the way) the
following all work:
Python:
data = subprocess.check_output(["gcc", "-E", "program.c"])
Powershell:
$x = (gcc -E program.c)
cmd:
for /f %i in ('gcc -E program.c') do ...
If gcc -E wrote its output to a file, you'd have to read that file,
manage the process of deleting it after use (and handle possible
deletion of it if an error occurred), etc.
But if I use the -S option (show assembly listing) that DOES output to a
file (program.s).
If I use -fdump-tree-all, that also goes to a file (various).
Writing to stdout is very often a good design. Not always, but nothing
is ever 100% black and white, but sufficiently often that building an
OS based on the idea (Unix) was pretty successful :-)
The first computer I used was via a teletype printing on paper. If every
operation producing an arbitrarily open-ended amount of output defaulted
to the terminal, then it would have been totally impractical (in time
taken and the amount of paper used).
Even with today's consoles, 80,000 lines whizzing up the screen (when
program.c contains '#include '), while not taking quite that
long, still seems crazy to have as the default operating mode.
But you will say, Ah but you will never see it because it will nearly
always be piped into another program.
And that reinforces the point I keep making: many of these are internal
utilities never intended to be used as properly interactive commands.
Fine, but why keep bringing them up as models of how to write true
interactive programs?
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 2017-10-06 13:24, bartc wrote:
> On 06/10/2017 14:11, Peter J. Holzer wrote:
>> On 2017-10-06 12:38, bartc wrote:
>>> On 06/10/2017 12:51, Chris Angelico wrote:
What you REALLY mean is that you can't see the point of an interactive
sort command. It doesn't fit into your workflow. And that's fine. It's
not something you'd use very often. There are other programs, however,
that behave exactly the same whether used in batch mode or interactive
mode, and where you would do exactly the same thing as I described -
provide input, and hit Ctrl-D to mark that you're done.
>>>
>>> Examples?
>>>
>>> And is there any reason why you wouldn't use a text editor to capture
>>> your input first? I can see myself noticing an error I'd made 10 lines
>>> up, which is now too late to change, and I've still got 100 lines to go.
>>> What to do?
>>>
>>> I just can't anyone wanting to use programs that work in the way you
>>> suggest. Not outside of a student exercise (read N numbers and display
>>> the average), where getting the input correct isn't so important.
>>
>> I regularly use at least cat, wc and od this way (plus a few of my own
>> utilities like utf8dump). I'm sure I've used sort this way, too, though
>> rather rarely. I usually don't type the input but paste it in,
>
> Exactly. Probably no one ever uses these programs with actual live input
> with the possibility of uncorrectable errors getting through.
>
> So not a good reason to use that coding pattern to write programs which
> ARE designed for live, interactive input:
But you aren't arguing about programs which are designed for live,
interactive input, you are arguing about sort. Sort is designed as a
filter. It should be able to read from stdin (otherwise you couldn't use
it in a pipe) and the fact that this also works when stdin is a terminal
is just a bonus. The authors of sort would have to go out of their way
to prevent that and they didn't. I think that's a good thing: It's
occassionally useful that I can paste something directly into sort and
don't have to write it into a file first, and the rest of the time it
does no harm.
> print ("Enter blank expression to quit.")
>
> while 1:
>
> buffer=input("Expr: ")
> if buffer == "": break
> try:
> print (eval(buffer))
> except:
> print ("Error")
>
> print ("Done")
I hope you don't think this a good design for interactive input: It's
much too easy to hit enter once too often. Ctrl-D is much harder to hit
accidentally. In addition you could add a "user-friendly" command like
"exit" or "quit". Although I hate it when Ctrl-D doesn't work:
Ctrl-D - does nothing
exit - syntax error
quit - syntax error
bye - program exits.
There are way too many english words which a user might want to use to
indicate their intention to close a program. None of them is therefore
likely to work everywhere (and I'm not even talking about stuff like
"\q" or "~."). EOF is unambiguous (and Ctrl-D for signalling EOF is an
OS feature - the application knows nothing about it).
hp
--
_ | Peter J. Holzer| Fluch der elektronischen Textverarbeitung:
|_|_) || Man feilt solange an seinen Text um, bis
| | | h...@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
--
https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On Fri, Oct 6, 2017 at 2:35 PM, Paul Moore wrote:
>
> cmd:
> for /f %i in ('gcc -E program.c') do ...
Note that CMD processes the output as decoded Unicode text instead of
encoded bytes. This is often a source of mojibake. It runs the above
command with stdout redirected to a pipe, and it decodes the output
line-by-line using the console's output codepage from
GetConsoleOutputCP(). The console defaults to the system locale's OEM
codepage. If CMD is run without a console (detached), it defaults to
the system locale's ANSI codepage. Commonly, the program being run
might write its output as OEM, ANSI, or UTF-8 text. For example,
Python defaults to ANSI on Windows, but %PYTHONIOENCODING% could
override this as UTF-8.
You can change the console's input and output codepages to another
codepage (but not separate values) via chcp.com. For example, `chcp
65001` sets it to UTF-8. But don't change it permanently, and
certainly don't leave it in its (buggy) UTF-8 mode. Instead, a batch
script should save the previous codepage and switch back when it's
done.
--
https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On Fri, Oct 6, 2017 at 11:38 PM, bartc wrote: > And is there any reason why you wouldn't use a text editor to capture your > input first? I can see myself noticing an error I'd made 10 lines up, which > is now too late to change, and I've still got 100 lines to go. What to do? As has already been mentioned, this is frequently used with pasted text. But if I'm typing it manually, it's because there aren't a hundred lines to go, there might be a dozen. What to do? Hit Ctrl-D, let it spam its output, and then start over, probably by highlighting the previous text and using middle-button paste. > I just can't anyone wanting to use programs that work in the way you > suggest. Not outside of a student exercise (read N numbers and display the > average), where getting the input correct isn't so important. And since you've never personally worked this way, you scorn the concept. Have you ever worked on a slow remote session where a GUI is completely impracticable (or maybe even unavailable), and redrawing the screen is too expensive to do all the time? You absolutely have to work with line-by-line content. What text editor do you use there? >> And since >> every one of these programs is written to read from stdin until EOF, >> you can use them all in exactly the same way - type at keyboard, hit >> Ctrl-D when done. > > So they're all at it! That doesn't mean it's a good way of doing things. Actually it does, because you learn the system once and use it for everything. > On 06/10/2017 12:45, Chris Angelico wrote: >> Why do you call redirection "crude"? Do you not understand the value >> of generic solutions that work with all programs, rather than having >> every program implement its own "take input from file" parameter? >> >> You can disagree with the Unix philosophy all you like, but when you >> insult it, you just make yourself look like an idiot. > > Redirection is used on Windows too. I use output redirection quite > frequently (to capture the output of 'dir' for example). > > I don't rely on > and < in my own programs. Where there's complex, mixed > output, the bulk of it - the data - needs to go to a proper file, while the > screen shows messages. That's why we have the stderr stream as well as stdout. You can redirect stdout and still have messages go to the screen (via stderr); or you can redirect stderr as well, sending those messages to a logging facility. How do you do THAT with your program? Also: can you use your program to write to a file on a different computer? I can pipe a program's output into SSH. You can make a crude intercom system like this: ssh flurble arecord | aplay & arecord | ssh flurble aplay More practically, I've done remote backups by triggering something on a remote system and then transferring it to the system I'm running the script on. In one particular case, the CPU load of compressing the data was impacting the (single-core) source computer, so I piped it uncompressed to the recipient, deflating it on arrival: ssh flurble dump_stuff | gzip >some.dump > If you don't like the word 'crude', try 'lazy'. Take this example of the gcc > C compiler: > > > gcc -E program.c > > This preprocesses the code and shows the result. Typical programs will have > many thousands of lines of output, but it just dumps it to the console. You > /have/ to use '>' to use it practically (Windows doesn't really have a > working '|' system.) I'm not sure what you mean by a working pipe system. Yes, the one cmd.exe gives you is not nearly as flexible as what bash gives you, but for the purposes of the examples given so far, I'm pretty sure the Windows cmd.exe facilities are fine. I don't know about the actual OS facilities, but unless you're trying to redirect input/output from/to something other than a file or another process, that should be fine too. And as has already been said in this thread, it should not be a problem to explicitly redirect that. > BTW if I try: > > > gcc > it doesn't work (this on Linux). What happened to the generic solution? "It doesn't work" is a terrible way to report this. What's the problem? Is it possibly what's described fairly clearly in the error message? gcc: error: -E or -x required when input is from standard input Oh look! "In the face of ambiguity, refuse the temptation to guess." Since GCC is the GNU Compiler *Collection*, it won't assume that it knows what language you want it to compile. When you give it a file name with an extension, it will presume that that's correct (you can override with "-x", but I don't remember *ever* needing to do that), but otherwise, it doesn't guess, so you have to specify with "-x c" or similar. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On Fri, Oct 6, 2017 at 1:31 PM, Thomas Jollans wrote:
> On 2017-10-06 12:33, Ben Bacarisse wrote:
>
>> A general solution to the (rather odd) complaint about silent waiting
>> should really check any input fileno to see if a prompt is needed. You
>> could argue, though, that anyone who's re-arranged a program's input so
>> that some non-zero input fileno is attached to a terminal won't need the
>> prompt!
>
> stdin is ALWAYS fileno 0, whether the input is attached to a tty or not.
> The only situation where sys.stdin.fileno() != 0 is when sys.stdin has
> been reassigned from within python.
>
> $ python -c 'import sys; print(sys.stdin.fileno())' < /dev/zero
> 0
>
> This should be true for all platforms, or at least all platforms python
> supports.
POSIX defines STDIN_FILENO as 0, and the Windows C runtime reserves FD
0 to map to the native StandardInput handle. But as I noted in a
previous message, on Windows isatty(0) returns true if a process isn't
executed with a valid StandardInput. In this case sys.stdin will be
None, so call sys.stdin.fileno() and handle the exception if that
fails.
If you really need to know that stdin is interactive for something
critical, then isatty() is the wrong function on Windows. You need to
check for a console, which is most easily done by using ctypes to call
GetConsoleMode. For example:
import os
if os.name == 'posix':
from os import isatty
elif os.name == 'nt':
import ctypes
import msvcrt
kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)
def isatty(fd):
"""Return True if the fd is connected to a console."""
try:
handle = ctypes.c_void_p(msvcrt.get_osfhandle(fd))
except (OSError, IOError):
return False
mode = ctypes.c_ulong()
success = kernel32.GetConsoleMode(handle, ctypes.byref(mode))
return bool(success)
--
https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On 2017-10-06 17:01, eryk sun wrote:
> On Fri, Oct 6, 2017 at 1:31 PM, Thomas Jollans wrote:
>> On 2017-10-06 12:33, Ben Bacarisse wrote:
>>
>>> A general solution to the (rather odd) complaint about silent waiting
>>> should really check any input fileno to see if a prompt is needed. You
>>> could argue, though, that anyone who's re-arranged a program's input so
>>> that some non-zero input fileno is attached to a terminal won't need the
>>> prompt!
>>
>> stdin is ALWAYS fileno 0, whether the input is attached to a tty or not.
>> The only situation where sys.stdin.fileno() != 0 is when sys.stdin has
>> been reassigned from within python.
>>
>> $ python -c 'import sys; print(sys.stdin.fileno())' < /dev/zero
>> 0
>>
>> This should be true for all platforms, or at least all platforms python
>> supports.
>
> POSIX defines STDIN_FILENO as 0, and the Windows C runtime reserves FD
> 0 to map to the native StandardInput handle. But as I noted in a
> previous message, on Windows isatty(0) returns true if a process isn't
> executed with a valid StandardInput. In this case sys.stdin will be
> None, so call sys.stdin.fileno() and handle the exception if that
> fails.
Seriously? sys.stdin can be None? That's terrifying.
>
> If you really need to know that stdin is interactive for something
> critical, then isatty() is the wrong function on Windows. You need to
> check for a console, which is most easily done by using ctypes to call
> GetConsoleMode. For example:
>
> import os
>
> if os.name == 'posix':
> from os import isatty
>
> elif os.name == 'nt':
> import ctypes
> import msvcrt
> kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)
>
> def isatty(fd):
> """Return True if the fd is connected to a console."""
> try:
> handle = ctypes.c_void_p(msvcrt.get_osfhandle(fd))
> except (OSError, IOError):
> return False
> mode = ctypes.c_ulong()
> success = kernel32.GetConsoleMode(handle, ctypes.byref(mode))
> return bool(success)
>
--
https://mail.python.org/mailman/listinfo/python-list
Re: Introducing the "for" loop
On 10/6/2017 8:44 AM, ROGER GRAYDON CHRISTMAN wrote: Despite the documentation, I would still be tempted to say that range is a function. It is, *according* to the documentation. Built-in classes are included in Library Reference, Ch. 2, Built-in Functions. Changing that to "Built-in Functions and Classes" has been proposed (perhaps by me) and rejected. Taking duck-typing to the meta-level, every time I use range, I use its name followed by a pair of parentheses enclosing one to three parameters, and I get back an immutable sequence object. It sure looks like a function to me. In the standard mathematical sense it is, more so than instances of classes or mainly by side effects. I would similarly say that map is a function, or an iterator generator I write myself with yield statements is a function, Functions with 'yield' are 'generator functions' both of which also return sequences. Iterators are mutable representatives of sequences, but cannot be indexed. It is not clear to me what the difference really is between my conception and the official definition -- is it a question about whether it returns a first-class object? No. All python callables (functions in the broad sense) return objects. Or more simply, what is the clear and obvious distinction that I can give to my non-scientific laypeople about why range isn't a function, if it looks like one? It is a function, in the usual sense not specific to Python, that is specifically a Python class. It is not just a function. It is a function that returns an instance of itself when called. This is the distinguishing feature of classes as functions (callables). -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Platform preferences survey (your chance to gripe about app stores!)
Hi everyone! I'm launching a business offering new tools and services that might be of interest to users of scripting languages, so I'm interested in hearing your input (again). Thanks to those of you who participated in the earlier survey I've been busy improving the product suite to better match the needs of the community, so now I'm looking for more information about platform and distribution preferences in the lead-up to release. (Those of you who opted in for the beta trial are still on the list, I'll be in touch soon.) This survey should take less than 4 minutes to complete: https://www.surveymonkey.com/r/JBGCHZR Thanks! -Zak. -- https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On 2017-10-06, Thomas Jollans wrote: > Seriously? sys.stdin can be None? That's terrifying. Why? Unix daemons usually run with no stdin, stderr, or stdout. And yes, people do write Unix daemons in Python. -- Grant Edwards grant.b.edwardsYow! VICARIOUSLY experience at some reason to LIVE!! gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: callable values
On 06/10/17 17:25, Stefan Ram wrote: Terry Reedy writes: On 10/6/2017 8:44 AM, ROGER GRAYDON CHRISTMAN wrote: Despite the documentation, I would still be tempted to say that range is a function. It is, *according* to the documentation. Built-in classes are included in Library Reference, Ch. 2, Built-in Functions. Changing that to "Built-in Functions and Classes" has been proposed (perhaps by me) and rejected. FWIW, in my course notes, I have coined a special word for this: A /prelate/ (German: "Prälat") is a callable value (object). I think I'll continue to call them callables. That way I won't burst into giggles when I accidentally think of them as church dignitaries. -- Rhodri James *-* Kynesim Ltd -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 06/10/2017 15:55, Chris Angelico wrote: On Fri, Oct 6, 2017 at 11:38 PM, bartc wrote: Have you ever worked on a slow remote session where a GUI is completely impracticable (or maybe even unavailable), and redrawing the screen is too expensive to do all the time? You absolutely have to work with line-by-line content. Not since about 1977, using 110 baud teletypes and VDUs, on a mainframe not geared to interactive use so it was unresponsive anyway. By 1981 however I was using a memory-mapped text display (of my home-made computer) which even with its 8-bit processor could update the screen at 200,000 characters per second. In other words, instantly. So what's the excuse for an unresponsive text display in 2017? What text editor do you use there? That depends; are we still in the 1970s? That's why we have the stderr stream as well as stdout. You can redirect stdout and still have messages go to the screen (via stderr); or you can redirect stderr as well, sending those messages to a logging facility. How do you do THAT with your program? I said the output was complex. Then there might be more than one output file, and one or more of the outputs need to be in an actual file. Just blithely sending /everything/ to stdout, even mixed up with stderr, might be something I'd do for a quick throwaway program, not a major application. (And since I mainly use my own languages, actually getting hold of 'stdin', 'stdout' and 'stderr' is not trivial. Creating actual named files is much easier.) Also: can you use your program to write to a file on a different computer? I can pipe a program's output into SSH. You can make a crude intercom system like this: No. I've got no idea about formal networking. (Actually, I walked out of the computer networks exam in my CS course, as I realised I knew nothing.) But as it happens, I could make computers talk to each when I was working with microprocessors, using home-made interfaces, rs232 or rs423. I wouldn't know how to do it now because it depends on other people's over-complex tech. I'm not sure what you mean by a working pipe system. Yes, the one cmd.exe gives you is not nearly as flexible as what bash gives you, but for the purposes of the examples given so far, I just don't work that way. The OS is there to launch applications, or to provide a basic API for common services such as a file system. I don't need its complicated shells. BTW if I try: > gcc "It doesn't work" is a terrible way to report this. What's the problem? Is it possibly what's described fairly clearly in the error message? It says 'no input files'. Presumably it's one of those programs that only takes input instructions from the command line, and does not look at stdin. In which case you wouldn't be able to pipe source code into it. You might actually have to tell it the name of a discrete file you want to compile. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On Sat, Oct 7, 2017 at 4:05 AM, Grant Edwards wrote: > On 2017-10-06, Thomas Jollans wrote: > >> Seriously? sys.stdin can be None? That's terrifying. > > Why? > > Unix daemons usually run with no stdin, stderr, or stdout. > > And yes, people do write Unix daemons in Python. Hmm, but usually I would expect them still to HAVE those streams, they're just connected to /dev/null or something. I don't think they would actually fail to exist, would they? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On Sat, Oct 7, 2017 at 4:13 AM, bartc wrote: > On 06/10/2017 15:55, Chris Angelico wrote: >> >> On Fri, Oct 6, 2017 at 11:38 PM, bartc wrote: > > >> Have you ever worked on a slow remote session where a GUI is >> completely impracticable (or maybe even unavailable), and redrawing >> the screen is too expensive to do all the time? You absolutely have to >> work with line-by-line content. > > > Not since about 1977, using 110 baud teletypes and VDUs, on a mainframe not > geared to interactive use so it was unresponsive anyway. > > By 1981 however I was using a memory-mapped text display (of my home-made > computer) which even with its 8-bit processor could update the screen at > 200,000 characters per second. In other words, instantly. > > So what's the excuse for an unresponsive text display in 2017? Got it. You assume that a system is a coherent computer with its peripherals, rather than being a networked collection of computers, all of them controlled from your laptop in response to a panicked email saying the web site is down. Your terminal exists on your laptop. The programs are being run on any of a number of your servers, possibly several of them concurrently. How do you handle that? >> What text editor do you use there? > > That depends; are we still in the 1970s? Nope. We're in 2017, where the "system" is often a networked collection of computers. > (And since I mainly use my own languages, actually getting hold of 'stdin', > 'stdout' and 'stderr' is not trivial. Creating actual named files is much > easier.) More blub happening right there. You start out by assuming that the standard streams are unimportant, therefore you think that providing them is pointless. It's self-perpetuating. >> Also: can you use your program to write to a file on a different >> computer? I can pipe a program's output into SSH. You can make a crude >> intercom system like this: > > No. I've got no idea about formal networking. (Actually, I walked out of the > computer networks exam in my CS course, as I realised I knew nothing.) It's 2017. You should understand at least a bit about the internet and how to use it. > But as it happens, I could make computers talk to each when I was working > with microprocessors, using home-made interfaces, rs232 or rs423. I wouldn't > know how to do it now because it depends on other people's over-complex > tech. I don't know if you're an idiot or a troll. Using TCP/IP networking is pretty simple (at least if you're using a real language - your own toy languages might have made it unnecessarily hard, for all I know), hardly "over-complex" by comparison to RS-232 programming. >> I'm not sure what you mean by a working pipe system. Yes, the one >> cmd.exe gives you is not nearly as flexible as what bash gives you, >> but for the purposes of the examples given so far, > > > I just don't work that way. The OS is there to launch applications, or to > provide a basic API for common services such as a file system. I don't need > its complicated shells. Blub rears its head again. (Also, the shell isn't part of the OS. It's a separate tool. But still.) >>> BTW if I try: >>> >>> > gcc >> >>> it doesn't work (this on Linux). What happened to the generic solution? >> >> >> "It doesn't work" is a terrible way to report this. What's the >> problem? Is it possibly what's described fairly clearly in the error >> message? > > > It says 'no input files'. Presumably it's one of those programs that only > takes input instructions from the command line, and does not look at stdin. Presumably you don't know that a large number of programs accept "-" as a pseudo-filename that means "stdin" or "stdout" depending on context. For instance, you can diff a file with stdin, or send wget's output to stdout. At what point will you acknowledge that there are things you do not understand that are actually useful? ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On 2017-10-06, Chris Angelico wrote:
> On Sat, Oct 7, 2017 at 4:05 AM, Grant Edwards
> wrote:
>> On 2017-10-06, Thomas Jollans wrote:
>>
>>> Seriously? sys.stdin can be None? That's terrifying.
>>
>> Why?
>>
>> Unix daemons usually run with no stdin, stderr, or stdout.
>>
>> And yes, people do write Unix daemons in Python.
>
> Hmm, but usually I would expect them still to HAVE those streams,
> they're just connected to /dev/null or something. I don't think they
> would actually fail to exist, would they?
That's a good point. The basic approach is to fork and then just
close all file descriptors. Since what is normally the
std{in,out,err} descriptors can be re-used, you could end up with some
naive code (e.g. something in a library) writing to a file/socket that
it shouldn't be writing to.
The defensive approach is to open /dev/null and use dup2() to make fd
0 1 2 refer to that. In that case, they do exist, but stdin always
reads empty and stdout stderr write data is discarded.
That's probably the more common approach.
--
Grant Edwards grant.b.edwardsYow! Could I have a drug
at overdose?
gmail.com
--
https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
bartc : > The internal utilities used within an operating system, primarily > intended for file or redirected i/o with no live interaction, should be > distinct from those designed to be used directly with a live user. > > Or is it against the rules of Unix to have two different versions of a > program? > > Then you might have 'sort' for the non-interactive version, and 'isort' > or whatever for the interactive. You are right that interactive programs exist and operate very differently from what are known as *tools*. Interactive Linux programs include: LibreOffice NetworkManager Firefox Skype XBoard Emacs GIMP top gdb etc. I don't know if anybody has seen a market/need for an interactive sort program, but there's nothing preventing you from writing one. > So I can't see the point of using that same pattern of input usage > (reading from stream, file, pipe whatever until interrupted with an > EOF signal) for a true interactive program that is used in a sensible > manner. So go ahead and write an interactive sort program. It might employ a mouse, joystick, iris scanner, touchscreen, sound effects or whatever facilities you would think would be useful for the human user. > A program like 'python' might fit the bill too. Here, you can give it > the name of a file, OR say nothing, and it will take input from stdin. Personally, I think stdin is a bit lame as a stimulus source for an interactive program. That's not even what stdin is primarily meant for; stdin is meant to be the input data for a job. Similarly, stdout is meant to be the result of the computation. Stderr, then, is used to deliver optional diagnostic messages, ie, metainfo about the computation. For interaction with a human, you should look into frameworks like Qt or curses. > Funnily enough, you now get a message, and a prompt. And when entering > multiple lines of code, you get a prompt before each line. You can > also terminate the sequence by entering a blank line. > > So it IS possible to do it properly after all!) The Unix terminal can operate in two main modes: canonical and non-canonical. The latter is typically used for interaction. See: https://en.wikipedia.org/wiki/POSIX_terminal_interface#C anonical_mode_processing> Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 2017-10-06, bartc wrote: > So what's the excuse for an unresponsive text display in 2017? Well, they've invented this thing called "networking". Not everybody in the world sits alone working with nothing other than the computer in front of them. Some people have to deal with remote systems connected via satellites links, low-bandwidth RF modems, and whatnot. Even cellular network connections often have high latency and low bandwidth. -- Grant Edwards grant.b.edwardsYow! BELA LUGOSI is my at co-pilot ... gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
Chris Angelico : > On Sat, Oct 7, 2017 at 4:05 AM, Grant Edwards > wrote: >> On 2017-10-06, Thomas Jollans wrote: >>> Seriously? sys.stdin can be None? That's terrifying. >> >> Why? >> >> Unix daemons usually run with no stdin, stderr, or stdout. >> >> And yes, people do write Unix daemons in Python. > > Hmm, but usually I would expect them still to HAVE those streams, > they're just connected to /dev/null or something. I don't think they > would actually fail to exist, would they? The reason a daemon usually opens dummy file descriptors for the 0, 1 and 2 slots is to avoid accidents. Some library might assume the existence of those file descriptors. For example, I often see GTK print out diagnositic messages. It would be awkward if those file descriptor slots were assigned to, say, a database or a socket. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 2017-10-06 15:00, Dennis Lee Bieber wrote: > On Fri, 6 Oct 2017 15:04:45 +0100, bartc declaimed the > following: >>But if I use the -S option (show assembly listing) that DOES output to a >>file (program.s). >> > > The assembler file is created anyway -- but is normally a temporary > file, deleted after the assembly pass of gcc. The -S option tells gcc to > /stop before the assembly pass/, leaving the assembly file in the > directory. On modern gcc, no: The assembly file is normally created in /tmp or (with -pipe) not at all. With -S the assembly file needs to be created with the proper name in the current directory, which is not the default behaviour. Your description may have been true for the original portable c compiler. But if I remember correctly, that one also wrote the output of the preprocessor to a temporary file which was then read by cc1. In any case, that -E writes to stdout and -S to file is an inconsistency which looks more like a historical accident than a planned feature to me. hp -- _ | Peter J. Holzer| Fluch der elektronischen Textverarbeitung: |_|_) || Man feilt solange an seinen Text um, bis | | | h...@hjp.at | die Satzbestandteile des Satzes nicht mehr __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel -- https://mail.python.org/mailman/listinfo/python-list
Re: stop/start windows services -python command
On Friday, October 6, 2017 at 4:29:48 AM UTC-4, Paul Moore wrote: > On 6 October 2017 at 04:52, Prabu T.S. wrote: > > On Thursday, October 5, 2017 at 9:00:19 PM UTC-4, MRAB wrote: > >> On 2017-10-06 01:37, Prabu T.S. wrote: > >> > On Thursday, October 5, 2017 at 8:33:02 PM UTC-4, MRAB wrote: > >> >> On 2017-10-05 23:32, Prabu T.S. wrote: > >> >> > On Thursday, October 5, 2017 at 6:16:44 PM UTC-4, Prabu T.S. wrote: > >> >> >> hello all,what is the command to stop and start windows services ? > >> >> >> i can't install win32serviceutil bec am using latest python version. > >> >> > > >> >> > Please advice on this > >> >> > > >> >> Ask Google: windows services start stop command line > >> > > >> > asking for python. > >> > > >> Again, ask Google: windows services start stop python > >> > >> Those results talk about "win32serviceutil", which is not part of the > >> standard library, but part of pywin32, which you can download. > > > > i tried pywin32, but its not compatible with python 3.6. Is there anyway i > > can implement start and stop services in python 3.6 version. > > pywin32 *is* available for Python 3.6. Either from > https://sourceforge.net/projects/pywin32/files/pywin32/Build%20220/ (a > wininst installer, which is not compatible with pip but which > nevertheless can be installed in your system Python) or from > http://www.lfd.uci.edu/~gohlke/pythonlibs/ which hosts a lot of wheels > for Windows,or as pypiwin32 from PyPI > (https://pypi.python.org/pypi/pypiwin32/220). > > It's possible to find at least some of these via Google searches, too. > Paul thank Pauls. I have to rename 3.6 python in registry to 3.6-32 to make it work. Thanks again. -- https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On Sat, Oct 7, 2017 at 4:54 AM, Grant Edwards wrote:
> On 2017-10-06, Chris Angelico wrote:
>> On Sat, Oct 7, 2017 at 4:05 AM, Grant Edwards
>> wrote:
>>> On 2017-10-06, Thomas Jollans wrote:
>>>
Seriously? sys.stdin can be None? That's terrifying.
>>>
>>> Why?
>>>
>>> Unix daemons usually run with no stdin, stderr, or stdout.
>>>
>>> And yes, people do write Unix daemons in Python.
>>
>> Hmm, but usually I would expect them still to HAVE those streams,
>> they're just connected to /dev/null or something. I don't think they
>> would actually fail to exist, would they?
>
> That's a good point. The basic approach is to fork and then just
> close all file descriptors. Since what is normally the
> std{in,out,err} descriptors can be re-used, you could end up with some
> naive code (e.g. something in a library) writing to a file/socket that
> it shouldn't be writing to.
>
> The defensive approach is to open /dev/null and use dup2() to make fd
> 0 1 2 refer to that. In that case, they do exist, but stdin always
> reads empty and stdout stderr write data is discarded.
>
> That's probably the more common approach.
Yeah. I usually see daemonized processes that still have *some*
handles in 0/1/2, either /dev/null or to some sort of logging facility
(the latter being extremely helpful where it's available). But I just
tested it, and sure enough, Python does actually stash None into
sys.stdin/out/err if the corresponding file handles were closed prior
to exec.
#include
#define IGNORE1 \
""" ";
int main()
{
close(0);
close(1);
close(2);
execlp("python3", "python3", "nostreams.c", NULL);
}
#define IGNORE2 \
" """; #\
import sys #\
with open("nostreams.log", "w") as f: #\
print("stdin: ", sys.stdin, file=f) #\
print("stdout:", sys.stdout, file=f) #\
print("stderr:", sys.stderr, file=f)
So I suppose you'd have to do something like:
if sys.stdout and sys.stdout.isatty():
# be interactive
else:
# perform in batch mode
just to be on the safe side.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 2017-10-06 15:08, Dennis Lee Bieber wrote:
> On Fri, 6 Oct 2017 15:06:03 +0200, "Peter J. Holzer"
> declaimed the following:
>
>
>>I can see some merit in the idea that filters could print a short help
>>message when reading from a terminal, but creating a second
>>"interactive" version of each filter with a different name seems to be
>>utterly pointless to me.
>>
> Knowing UNIX practices -- it would still be the same executable with a
> different name hard-linked to it, and would differentiate by reading the
> name used to invoke it. That, or a system wide alias that expands to the
> base sort command with a default argument specifying interactive mode.
I'm not worried about code duplication or disk space. I think that the
creation of such "interactive" variants is pointless because those
people who would - in bartc's opinion - benefit from them would never
find out about them: Would a newbie who wants to sort something and
hasn't read a book or other documentation type "sort" or "isort"? If
they type "linux sort file" into Google, will they find lots of search
results telling them to use "sort" or "isort"? If they do read a book,
will it recommend "sort" or "isort"?
> {I was tempted to make that "isor", pronounced eye-sore}
:-)
hp
--
_ | Peter J. Holzer| Fluch der elektronischen Textverarbeitung:
|_|_) || Man feilt solange an seinen Text um, bis
| | | h...@hjp.at | die Satzbestandteile des Satzes nicht mehr
__/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel
--
https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On 2017-10-06, Marko Rauhamaa wrote: > The reason a daemon usually opens dummy file descriptors for the 0, 1 > and 2 slots is to avoid accidents. Some library might assume the > existence of those file descriptors. For example, I often see GTK print > out diagnositic messages. I run a lot of GTK programs from the command line, and I would say 90% or more of them spew a steady stream of meaningless (to the user) diagnostic messages. That's pretty sloppy programming if you ask me... -- Grant Edwards grant.b.edwardsYow! I've got a COUSIN at who works in the GARMENT gmail.comDISTRICT ... -- https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On 2017-10-06 17:05, Grant Edwards wrote: > On 2017-10-06, Thomas Jollans wrote: >> Seriously? sys.stdin can be None? That's terrifying. > > Why? > > Unix daemons usually run with no stdin, stderr, or stdout. That's pretty rare. Usually they are just connected to /dev/null or a log file. Completely closing them is dangerous: The next open will use the first free file descriptor and there may be parts of your daemon (e.g. a library function) which assumes that it can write on file descriptor 2: You don't want random error messages or warnings appear in one of your output files (there have been a few security holes because of this). hp -- _ | Peter J. Holzer| Fluch der elektronischen Textverarbeitung: |_|_) || Man feilt solange an seinen Text um, bis | | | h...@hjp.at | die Satzbestandteile des Satzes nicht mehr __/ | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On Sat, Oct 7, 2017 at 4:55 AM, Marko Rauhamaa wrote: > Personally, I think stdin is a bit lame as a stimulus source for an > interactive program. That's not even what stdin is primarily meant for; > stdin is meant to be the input data for a job. Similarly, stdout is > meant to be the result of the computation. Stderr, then, is used to > deliver optional diagnostic messages, ie, metainfo about the > computation. > > For interaction with a human, you should look into frameworks like Qt or > curses. Qt is *massive* overkill for a lot of programs. Even curses is more than you'd normally need. Stick to readline and have done with it. Challenge: Take a reasonably competent computer programmer who's never written a single line of Python code, and teach him/her how to use Python in one working week (Mon-Fri). Your student must work mostly solo, and you may meet with him/her once per day for one hour. At 5PM on Friday, your student must demonstrate a fully-working project written in Python; it must have some form of user interaction and perform some kind of useful or semi-useful task. Are you going to recommend that s/he master Qt as well as the Python language itself? And if you say "this task is impossible", that's fine. I'll have to rewrite my history and erase the eighteen or twenty (I think) students of mine that have done exactly that. A number of them used Flask to create a web application (since they already had experience with web app development using Node.js prior to this one-week challenge), one did data analysis with output in matplotlib, and the rest all used nothing but the console. Recently, I had three (out of seven) students building adventure games, and they all had distinct styles and dramatically different code models, but all of them followed a basic "read from stdin, write to stdout" model. Their UIs literally consisted of just input() and print() calls, letting them all concentrate on the guts of the code. Standard streams exist for a reason. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
Chris Angelico : > On Sat, Oct 7, 2017 at 4:55 AM, Marko Rauhamaa wrote: >> Personally, I think stdin is a bit lame as a stimulus source for an >> interactive program. That's not even what stdin is primarily meant >> for; stdin is meant to be the input data for a job. Similarly, stdout >> is meant to be the result of the computation. Stderr, then, is used >> to deliver optional diagnostic messages, ie, metainfo about the >> computation. > > [...] > > Standard streams exist for a reason. That's exactly what I said. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 06/10/2017 18:42, Chris Angelico wrote: On Sat, Oct 7, 2017 at 4:13 AM, bartc wrote: So what's the excuse for an unresponsive text display in 2017? Got it. You assume that a system is a coherent computer with its peripherals, rather than being a networked collection of computers, all of them controlled from your laptop in response to a panicked email saying the web site is down. Your terminal exists on your laptop. The programs are being run on any of a number of your servers, possibly several of them concurrently. How do you handle that? What text editor do you use there? That depends; are we still in the 1970s? Nope. We're in 2017, where the "system" is often a networked collection of computers. Still no excuse. We were talking about the need to use a crude keyboard interface to serially create a file of data a line at a time rather than using a proper application for it (such as a text editor). So which bit do you have access to locally? The keyboard presumably. And the display has to be local unless you it's either got a 50' screen or you use binoculars. Are you saying the bit in the middle is remote and that is what is playing up? This is exactly the situation from the 1970s that I thought we'd long left behind! There really is no excuse for not having the minimum amount of local processing power available to be able to enter and review a few dozen lines of text without needing to involve a temperamental network. If you're stuck, whip out a tablet computer or smartphone (they should still function without connectivity) and use a preloaded text editor. Or just compose and then save an email. Even the simplest should be more sophisticated than just blindly entering text on a Linux terminal screen. (And since I mainly use my own languages, actually getting hold of 'stdin', 'stdout' and 'stderr' is not trivial. Creating actual named files is much easier.) More blub happening right there. You start out by assuming that the standard streams are unimportant, therefore you think that providing them is pointless. It's self-perpetuating. They were a creation of either C, Unix, or some combination. Certainly I had very little to with any of that for decades. I can't remember that it ever stopped me doing anything I needed to do. My own programs worked like this (showing original '#' symbol I used); print "One" # to console (also using print #0) print #f, "Two" # to file handle f print #s, "Three" # append to string s print #w, "Four" # to window or control w print #b, "Five" # to image b What would I want with stderr?! It's 2017. You should understand at least a bit about the internet and how to use it. I can use it but can't fix it when it goes wrong. I don't know if you're an idiot or a troll. Using TCP/IP networking is pretty simple (at least if you're using a real language - your own toy languages might have made it unnecessarily hard, for all I know), hardly "over-complex" by comparison to RS-232 programming. So how do you use it from Python - without using an existing Python library? Or is it only simple when someone else has made it idiot-proof? (That reminds me, at some point I have to provide a winsock2.h file for my C compiler. I may have to finally learn some of this stuff to test it.) I just don't work that way. The OS is there to launch applications, or to provide a basic API for common services such as a file system. I don't need its complicated shells. Blub rears its head again. How so? I said I have little need for most of what an OS does, in my development work, which is perfectly true. Perhaps you haven't noticed that many are using sophisticated IDEs now rather than fiddling about with command lines. (Mine is not sophisticated, but still better than a command line.) At what point will you acknowledge that there are things you do not understand that are actually useful? I can understand that people who use Unix and Linux arrange their world so that all these things are apparently indispensable. What you're trying to tell me is that because Unix provides such a tightly knit system system of utilities, stdin, stdout, files, pipes and very specific ways of using the keyword (which seems to consist of avoiding actually using it for entering data as much a possible; just using the logical idea of it), then every other text entry system in the world, in whichever OS or application, must follow exactly the same model. Because the Unix one is so great. Needless to say, I disagree. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On Sat, Oct 7, 2017 at 5:47 AM, Marko Rauhamaa wrote: > Chris Angelico : > >> On Sat, Oct 7, 2017 at 4:55 AM, Marko Rauhamaa wrote: >>> Personally, I think stdin is a bit lame as a stimulus source for an >>> interactive program. That's not even what stdin is primarily meant >>> for; stdin is meant to be the input data for a job. Similarly, stdout >>> is meant to be the result of the computation. Stderr, then, is used >>> to deliver optional diagnostic messages, ie, metainfo about the >>> computation. >> >> [...] >> >> Standard streams exist for a reason. > > That's exactly what I said. And you also described it as "lame" for an interactive program. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 06/10/2017 18:55, Marko Rauhamaa wrote:
bartc :
The internal utilities used within an operating system, primarily
intended for file or redirected i/o with no live interaction, should be
distinct from those designed to be used directly with a live user.
Or is it against the rules of Unix to have two different versions of a
program?
Then you might have 'sort' for the non-interactive version, and 'isort'
or whatever for the interactive.
You are right that interactive programs exist and operate very
differently from what are known as *tools*.
Interactive Linux programs include:
LibreOffice
NetworkManager
Firefox
Skype
XBoard
Emacs
GIMP
top
gdb
etc.
I meant interactive programs that work with a scrolling display, as
suits a program like this:
while 1:
print (input("?"))
Considerations of the 'eof' status of a keyboard would of course be
irrelevant for anything more sophisticated, either with a more organised
console app, or one using a GUI.
I don't know if anybody has seen a market/need for an interactive sort
program, but there's nothing preventing you from writing one.
For sort, there is no real need. You use a text editor to create your
data. Then use existing file-based sort.
So I can't see the point of using that same pattern of input usage
(reading from stream, file, pipe whatever until interrupted with an
EOF signal) for a true interactive program that is used in a sensible
manner.
So go ahead and write an interactive sort program. It might employ a
mouse, joystick, iris scanner, touchscreen, sound effects or whatever
facilities you would think would be useful for the human user.
It wasn't me who brought up 'sort' when the subject was interactive
keyboard dialogues (it was Chris I think).
A program like 'python' might fit the bill too. Here, you can give it
the name of a file, OR say nothing, and it will take input from stdin.
Personally, I think stdin is a bit lame as a stimulus source for an
interactive program. That's not even what stdin is primarily meant for;
stdin is meant to be the input data for a job. Similarly, stdout is
meant to be the result of the computation. Stderr, then, is used to
deliver optional diagnostic messages, ie, metainfo about the
computation.
You really need punched tape or cards for input and output to get the
full effect. Complete with all the sound effects. Sadly when I came into
it, we were using mag-tape for input (with a variety of outputs).
The clatter of an ASR33 printing your results was also a treat.
--
bartc
--
https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On Sat, Oct 7, 2017 at 5:51 AM, bartc wrote: > On 06/10/2017 18:42, Chris Angelico wrote: >> >> On Sat, Oct 7, 2017 at 4:13 AM, bartc wrote: > > >>> So what's the excuse for an unresponsive text display in 2017? >> >> >> Got it. You assume that a system is a coherent computer with its >> peripherals, rather than being a networked collection of computers, >> all of them controlled from your laptop in response to a panicked >> email saying the web site is down. Your terminal exists on your >> laptop. The programs are being run on any of a number of your servers, >> possibly several of them concurrently. How do you handle that? >> What text editor do you use there? >>> >>> >>> That depends; are we still in the 1970s? >> >> >> Nope. We're in 2017, where the "system" is often a networked >> collection of computers. > > > Still no excuse. We were talking about the need to use a crude keyboard > interface to serially create a file of data a line at a time rather than > using a proper application for it (such as a text editor). > > So which bit do you have access to locally? The keyboard presumably. And the > display has to be local unless you it's either got a 50' screen or you use > binoculars. Are you saying the bit in the middle is remote and that is what > is playing up? > > This is exactly the situation from the 1970s that I thought we'd long left > behind! There really is no excuse for not having the minimum amount of local > processing power available to be able to enter and review a few dozen lines > of text without needing to involve a temperamental network. > > If you're stuck, whip out a tablet computer or smartphone (they should still > function without connectivity) and use a preloaded text editor. Or just > compose and then save an email. Even the simplest should be more > sophisticated than just blindly entering text on a Linux terminal screen. Save an email and then what? You need to make a change to something on a remote server. Maybe your hosts file is borked. Maybe the mail server configuration is slightly off, resulting in delayed delivery. Maybe your bindfile has an outdated record in it so half your users are getting timeouts. Whatever it is, it's almost certainly going to be managed by a text file in /etc, so you need to edit that file. How do you edit a file on a remote computer? How do you compare three instances of that file on different computers to see if one of them is different? >>> (And since I mainly use my own languages, actually getting hold of >>> 'stdin', >>> 'stdout' and 'stderr' is not trivial. Creating actual named files is much >>> easier.) >> >> >> More blub happening right there. You start out by assuming that the >> standard streams are unimportant, therefore you think that providing >> them is pointless. It's self-perpetuating. > > > They were a creation of either C, Unix, or some combination. Certainly I had > very little to with any of that for decades. I can't remember that it ever > stopped me doing anything I needed to do. That's Blub. You've never used it, so you don't understand its value, so you scorn it. > My own programs worked like this (showing original '#' symbol I used); > > print "One" # to console (also using print #0) > print #f, "Two" # to file handle f > print #s, "Three" # append to string s > print #w, "Four" # to window or control w > print #b, "Five" # to image b I'm not sure what printing to a window or image would mean, or how it's useful, but sure. In Python, you could do the same by making those things into file-like objects. > What would I want with stderr?! That's where you print error messages. It is, in fact, the standard place to print error messages. That's what it's for. If you're running a program interactively, stderr goes to the console. If you're running it interactively with output redirected, stderr still goes to the console. If you run it detached as a system service, stderr goes to the system logger. (At least, it should; it does with a lot of service managers.) If you run it from a web application framework, stderr goes into the web server's log. Etcetera. The program doesn't need to know or care - it just writes text to stderr. >> It's 2017. You should understand at least a bit about the internet and >> how to use it. > > I can use it but can't fix it when it goes wrong. Can you use it from a program, though? Not just working in a web browser, mail client, news client, etc - can your applications establish socket connections, listen for incoming connections, etc? >> I don't know if you're an idiot or a troll. Using TCP/IP networking is >> pretty simple (at least if you're using a real language - your own toy >> languages might have made it unnecessarily hard, for all I know), >> hardly "over-complex" by comparison to RS-232 programming. > > > So how do you use it from Python - without using an existing Python library? > Or is it only simple when someone else has made it idio
Re: The "loop and a half"
On Sat, Oct 7, 2017 at 6:18 AM, bartc wrote: >> I don't know if anybody has seen a market/need for an interactive sort >> program, but there's nothing preventing you from writing one. > > > For sort, there is no real need. You use a text editor to create your data. > Then use existing file-based sort. How about this: you run "du -sb *" to get directory sizes, and then after the info's on screen, you want to show the five largest. You could rerun the command, piped into "sort -n", or you could grab the existing text from your console and sort it. Do you have to switch across to a text editor, save the output there, and then sort it? Or do you invoke "sort -n" with no other args, paste straight from terminal back into the same terminal, hit Ctrl-D, and then read the output? I have done this exact thing multiple times. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 2017-10-06, Chris Angelico wrote: > Some are. Many aren't. In fact, the basic terminal has many advantages > over purely GUI systems, including that you can scroll back and see > exactly what happened previously. I generally recommend my students to > use a sophisticated text editor, and then a separate terminal (or, as > I tend to do, *many* separate terminals) to run commands in. Indeed, I find that to be very efficient. I'm always amazed how long it takes people to accomplish simple tasks when they refuse to use anything other than eclipse and a web browser. -- Grant Edwards grant.b.edwardsYow! I'm pretending that at we're all watching PHIL gmail.comSILVERS instead of RICARDO MONTALBAN! -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 2017-10-06, bartc wrote: > For sort, there is no real need. You use a text editor to create > your data. Then use existing file-based sort. I sort streams on stdin far more often than I sort named files. -- Grant Edwards grant.b.edwardsYow! Do you like "TENDER at VITTLES"? gmail.com -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
bartc : >> Personally, I think stdin is a bit lame as a stimulus source for an >> interactive program. That's not even what stdin is primarily meant for; >> stdin is meant to be the input data for a job. Similarly, stdout is >> meant to be the result of the computation. Stderr, then, is used to >> deliver optional diagnostic messages, ie, metainfo about the >> computation. > > You really need punched tape or cards for input and output to get the > full effect. Complete with all the sound effects. Sadly when I came into > it, we were using mag-tape for input (with a variety of outputs). > > The clatter of an ASR33 printing your results was also a treat. There you go! You got the idea. Keep that in your head when you are programming with stdin and stdout. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: How to determine lowest version of Python 3 to run?
Op 2017-10-06, Christopher Reimer schreef : > So I got tox and tox-docker installed. When I went to install Docker > for Windows, it wouldn't work because Hyper-V wasn't available on > Windows 10 Home. After paying Microsoft $99 for the privilege, I got > Windows 10 Pro installed and Docker started working. I've read that > all the cool programming kids are using Docker these days. I certainly > hope it was worth the cost. O_o You could have just used a Linux VM in Virtualbox for $0, and run Docker in that. Stephan -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
Grant Edwards : > I'm always amazed how long it takes people to accomplish simple tasks > when they refuse to use anything other than eclipse and a web browser. Now I can bring this back to Python. I have had a huge task of arranging 1000+ soccer games in a tournament. I could have used a web service for the purpose, but chose to use Python instead -- to great success! It's actually not about combining Unix tools but using programming to express ad hoc relationships between data. I could set up the games and have the program verify the diverse and individualistic boundary conditions are obeyed. Whenever customers come up with impromptu requests and change their minds, the Python program can accommodate the sudden needs with ease. The Web service owner was dismayed that I wasn't using their fancy web service. There was a time in computing when people fancied everybody should know how to program and apply the skill to everyday tasks. I don't think many people have such misconceptions anymore. However, it's a bit depressing because I have had a tremendous advantage several times when I've been able to solve my problems with programming. And Python's the obvious choice for the job. So today at 3:15 pm I was sent an Excel template I should use to deliver the game schedule. By 3:40 pm I had modified my program to generate the desired Excel format (with openpyxl) and sent the schedule to the referee administrator as an attachment. I told him I could send him a different format if he needed it, and advised him he should be prepared for multiple iterations as new requests arrive from customers. I wouldn't have managed the task with the mouse and the clunky web service. Marko -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 06/10/2017 20:38, Grant Edwards wrote: On 2017-10-06, bartc wrote: For sort, there is no real need. You use a text editor to create your data. Then use existing file-based sort. I sort streams on stdin far more often than I sort named files. So what's been established is that 'sort' is useful for a text stream that already exists as a file or is the output of another process. What hasn't been established is why how this works this has to influence the design of simple text-based dialogues, real ones where there will likely be an actual user tapping the keys in real time. The only tenuous connection I can see, is that if 'sort' is run without any piped or redirected input, it will resort to the keyboard. Even though that method is not user-friendly and hardly anyone ever uses it in that mode. So that same unfriendly technique should be the model for text dialogues everywhere. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On 10/6/2017 1:32 PM, Chris Angelico wrote: On Sat, Oct 7, 2017 at 4:05 AM, Grant Edwards wrote: On 2017-10-06, Thomas Jollans wrote: Seriously? sys.stdin can be None? That's terrifying. Why? Unix daemons usually run with no stdin, stderr, or stdout. And yes, people do write Unix daemons in Python. Hmm, but usually I would expect them still to HAVE those streams, they're just connected to /dev/null or something. I don't think they would actually fail to exist, would they? On Windows, a file run with pythonw.exe (no console) starts with sys.[__]std[in|out|err][__] (6 entries) set to None. The program can reset them as it pleases. In an IDLE user process, the non-dunder names are set to objects that communicate with the IDLE GUI process. >>> import sys; sys.__stdin__, sys.stdin (None, ) GUI programs interact with the OS and thence users through event streams rather than character streams. (Note that terminal escape sequences are character-encoded events.) That is why automating a GUI usually requires a special program than can generate and inject events into the event queue read by the GUI program. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On 06/10/2017 20:21, Chris Angelico wrote: On Sat, Oct 7, 2017 at 5:51 AM, bartc wrote: If you're stuck, whip out a tablet computer or smartphone (they should still function without connectivity) and use a preloaded text editor. Or just compose and then save an email. Even the simplest should be more sophisticated than just blindly entering text on a Linux terminal screen. Save an email and then what? You will have been able to create and review the text using normal editing methods. It will then be saved as a draft somewhere. When the sort program is back up (if that's what you're planning), then retrieve the text with copy&paste. No need to actually send it anywhere. My point is that everyone has the facility to create at least plain text documents off-line. There is no need to start some ancient terminal utility, get no response from it, then blindly type in line after line with no idea if it's doing anything with it. You need to make a change to something on a remote server. Maybe your hosts file is borked. Maybe the mail server configuration is slightly off, resulting in delayed delivery. Maybe your bindfile has an outdated record in it so half your users are getting timeouts. Whatever it is, it's almost certainly going to be managed by a text file in /etc, so you need to edit that file. How do you edit a file on a remote computer? How do you compare three instances of that file on different computers to see if one of them is different? I've no idea where you're going with this. Remember my original complaint was in treating keyboard entry like a file complete with EOF marker. They were a creation of either C, Unix, or some combination. Certainly I had very little to with any of that for decades. I can't remember that it ever stopped me doing anything I needed to do. That's Blub. You've never used it, so you don't understand its value, so you scorn it. OK, that works both ways as you've never used any of my stuff. print #w, "Four" # to window or control w print #b, "Five" # to image b I'm not sure what printing to a window or image would mean, or how it's useful, It displayed the text at the current position (using the current font, size and colour) and moved the current position to the end of the text. -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On Fri, Oct 6, 2017 at 4:27 PM, Thomas Jollans wrote: > On 2017-10-06 17:01, eryk sun wrote: >> >> POSIX defines STDIN_FILENO as 0, and the Windows C runtime reserves FD >> 0 to map to the native StandardInput handle. But as I noted in a >> previous message, on Windows isatty(0) returns true if a process isn't >> executed with a valid StandardInput. In this case sys.stdin will be >> None, so call sys.stdin.fileno() and handle the exception if that >> fails. > > Seriously? sys.stdin can be None? That's terrifying. Just check for None or handle the exception. It could be worse in Windows -- like inheriting broken standard I/O. This can happen if a console application is run without a console (i.e. dwCreationFlags=DETACHED_PROCESS) yet console handles are inherited in the standard handles via STARTUPINFO. isatty() will return True, but using the handles will fail. To avoid this problem with subprocess.Popen, if you use creationflags=DETACHED_PROCESS, make sure to set unused standard handles to subprocess.DEVNULL. -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On Sat, Oct 7, 2017 at 7:32 AM, bartc wrote: > On 06/10/2017 20:21, Chris Angelico wrote: >> >> On Sat, Oct 7, 2017 at 5:51 AM, bartc wrote: > > >>> If you're stuck, whip out a tablet computer or smartphone (they should >>> still >>> function without connectivity) and use a preloaded text editor. Or just >>> compose and then save an email. Even the simplest should be more >>> sophisticated than just blindly entering text on a Linux terminal screen. >> >> >> Save an email and then what? > > > You will have been able to create and review the text using normal editing > methods. It will then be saved as a draft somewhere. When the sort program > is back up (if that's what you're planning), then retrieve the text with > copy&paste. No need to actually send it anywhere. > > My point is that everyone has the facility to create at least plain text > documents off-line. > > There is no need to start some ancient terminal utility, get no response > from it, then blindly type in line after line with no idea if it's doing > anything with it. Saving a text file doesn't actually change that file anywhere. Yes, anyone can edit text files that do nothing. Great. Your task is to actually edit a file that exists on a remote server. You can't do that through a draft email. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: callable values
On 06/10/17 18:25, Stefan Ram wrote: > Terry Reedy writes: >> On 10/6/2017 8:44 AM, ROGER GRAYDON CHRISTMAN wrote: >>> Despite the documentation, I would still be tempted to say that range is a >>> function. >> It is, *according* to the documentation. Built-in classes are included >> in Library Reference, Ch. 2, Built-in Functions. Changing that to >> "Built-in Functions and Classes" has been proposed (perhaps by me) and >> rejected. > FWIW, in my course notes, I have coined a special word for > this: > > A /prelate/ (German: "Prälat") is a callable value (object). Are you just going to let that hanging without justifying your choice of word? > > For, example, I say: > > |When certain prelates are called, one has to write an > |expression into the parentheses, which is called "argument > |expression. In the case of the call »neg( 9 )«, »9« is the > |argument expression. > > (In the original German text this is: > > |Beim Aufruf mancher Prälaten kann oder muß in den für den > |Aufruf verwendeten Klammern ein Ausdruck geschrieben werden, > |der Argumentausdruck genannt wird. Im Aufruf »neg( 9 )« ist > |»9« der Argumentausdruck. > > .) > -- https://mail.python.org/mailman/listinfo/python-list
Re: How to determine lowest version of Python 3 to run?
On Oct 6, 2017, at 12:58 PM, Stephan Houben wrote: > > Op 2017-10-06, Christopher Reimer schreef : > >> So I got tox and tox-docker installed. When I went to install Docker >> for Windows, it wouldn't work because Hyper-V wasn't available on >> Windows 10 Home. After paying Microsoft $99 for the privilege, I got >> Windows 10 Pro installed and Docker started working. I've read that >> all the cool programming kids are using Docker these days. I certainly >> hope it was worth the cost. O_o > > You could have just used a Linux VM in Virtualbox for $0, and run Docker > in that. > > Stephan > -- > https://mail.python.org/mailman/listinfo/python-lists My $200 Dell laptop couldn't handle that combo and it would add an extra layer of complexity to my programming setup. Chris R. -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On Sat, 7 Oct 2017 12:24 am, bartc wrote:
> print ("Enter blank expression to quit.")
I *despise* programs that do that, and would cheerfully and unapologetically
take their designers, disguise them as a lettuce, and stake them out to be
nibbled to death by snails.
At the interactive prompt, I am frequently hitting Enter on a blank line,
either by accident, or deliberately to break up the calculations into groups,
or just to give myself time to think.
Blank lines should be treated as "do nothing" and simply ignored, and there
should be an explicit QUIT command.
Actually two: your OS's version of EOF (Ctrl-D on Unix-like systems, Ctrl-Z
ENTER on Windows), plus at least one of the usual exit/quit/bye named
commands. (Localised into whatever natural language you are using for the
prompts.)
--
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: The "loop and a half"
On Sat, 7 Oct 2017 01:55 am, Chris Angelico wrote: > Since GCC is the GNU Compiler *Collection* Today I Learned that gcc doesn't mean "Gnu C Compiler". I knew gcc compiles C, C++, Objective C and Objective C++, but today I discovered it also compiles Ada, Fortran, Java and "treelang", whatever the hell that is. -- 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: The "loop and a half"
On Sat, Oct 7, 2017 at 10:49 AM, Steve D'Aprano wrote: > On Sat, 7 Oct 2017 01:55 am, Chris Angelico wrote: > >> Since GCC is the GNU Compiler *Collection* > > Today I Learned that gcc doesn't mean "Gnu C Compiler". > > I knew gcc compiles C, C++, Objective C and Objective C++, but today I > discovered it also compiles Ada, Fortran, Java and "treelang", whatever the > hell that is. > Yeah. I think it *was* originally "GNU C Compiler", but when all the others got added, they renamed it. I may be wrong on that though. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
Steve D'Aprano writes: > On Fri, 6 Oct 2017 09:33 pm, Ben Bacarisse wrote: > >> A general solution to the (rather odd) complaint about silent waiting >> should really check any input fileno to see if a prompt is needed. You >> could argue, though, that anyone who's re-arranged a program's input so >> that some non-zero input fileno is attached to a terminal won't need the >> prompt! > > I'm afraid I don't quite know if I'm understanding you or not. > > I think you mean to say I should look at sys.stdin.fileno(), and if it is 0, > then write a prompt, and if not, just read from stdin (possibly blocking, > waiting for input). > > Is that right? > > But aren't there circumstances where fileno 0 isn't attached to a terminal, > and writing a prompt would be inappropriate? No. The point was that other file descriptors might be associated with a terminal. I could, for example, switch the input to an interactive program that interprets command to be done on some data file so that the supposedly interactive commands come form a file and I type the data at a terminal. The second point was anyone doing this probably does not need a hint about tying something. But this detail about other inputs opened by the program aside, it seems to me that what BartC (and others who want this) needs is a beginners shell that prints a helpful text whenever it starts a program (or pipeline of programs) with stdin attached to the terminal. It's not really something that every individual program should have to tackle. -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
Re: callable values (was: Introducing the "for" loop)
On Sat, 7 Oct 2017 03:25 am, Stefan Ram wrote: > FWIW, in my course notes, I have coined a special word for > this: > > A /prelate/ (German: "Prälat") is a callable value (object). In English, prelate is a kind of priest, a senior clergyman and dignitary. I don't know whether German makes a practice of taking arbitrary verbs and adjectives and turning them into nouns, but English does, and so a callable object is just called a "callable". -- 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: The "loop and a half"
On 07/10/2017 00:43, Steve D'Aprano wrote:
On Sat, 7 Oct 2017 12:24 am, bartc wrote:
print ("Enter blank expression to quit.")
I *despise* programs that do that, and would cheerfully and unapologetically
take their designers, disguise them as a lettuce, and stake them out to be
nibbled to death by snails.
At the interactive prompt, I am frequently hitting Enter on a blank line,
either by accident, or deliberately to break up the calculations into groups,
or just to give myself time to think.
Blank lines should be treated as "do nothing" and simply ignored, and there
should be an explicit QUIT command.
Um, that actually follows what interactive Python does. If you type this
(I'm using <<< as the prompt as >>> confuses my newsreader's quoting
system):
<<< def fn():
<<
Re: The "loop and a half"
bartc writes:
> On 06/10/2017 14:35, Paul Moore wrote:
>> On 6 October 2017 at 13:56, bartc wrote:
>>> If you don't like the word 'crude', try 'lazy'. Take this example of the gcc
>>> C compiler:
>>>
>>> > gcc -E program.c
>>>
>>> This preprocesses the code and shows the result. Typical programs will have
>>> many thousands of lines of output, but it just dumps it to the console. You
>>> /have/ to use '>' to use it practically (Windows doesn't really have a
>>> working '|' system.)
Does the Windows version of gcc not support the -o file option?
>> No you don't. Ignoring the fact that "windows doesn't really have a
>> working '|' system" (which is an oversimplification, by the way) the
>> following all work:
>>
>> Python:
>> data = subprocess.check_output(["gcc", "-E", "program.c"])
>> Powershell:
>> $x = (gcc -E program.c)
>> cmd:
>> for /f %i in ('gcc -E program.c') do ...
>>
>> If gcc -E wrote its output to a file, you'd have to read that file,
>> manage the process of deleting it after use (and handle possible
>> deletion of it if an error occurred), etc.
>
> But if I use the -S option (show assembly listing) that DOES output to
> a file (program.s).
And a good system lets you alter that. How many labels are generated
for some code? Let's see:
gcc -S -o /dev/stdout t.c | grep -c '^\.L'
Now gcc also permits -o - (it's a common Unix convention) but you can
almost always get round less helpful programs using /dev/sdout.
--
Ben.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"]
On Sat, 7 Oct 2017 05:33 am, Grant Edwards wrote: > On 2017-10-06, Marko Rauhamaa wrote: > >> The reason a daemon usually opens dummy file descriptors for the 0, 1 >> and 2 slots is to avoid accidents. Some library might assume the >> existence of those file descriptors. For example, I often see GTK print >> out diagnositic messages. > > I run a lot of GTK programs from the command line, and I would say 90% > or more of them spew a steady stream of meaningless (to the user) > diagnostic messages. That's pretty sloppy programming if you ask > me... Indeed. If you ever start to doubt that the average quality of software is "crap", try running GUI applications from the command line and watch the stream of warnings and errors flow by. They range from relatively trivial warnings that correctly sized icons are missing, to scary looking warnings about uninitialised pointers. Developers: why do you bother to log warnings if you're never going to fix the damn things? They're probably to busy re-doing working programs from scratch every few versions, with a brand new "improved" UI (almost invariably including a kool new design that uses light grey text on an ever so slightly lighter grey background) and deleting any useful functionality that the lead developer personally doesn't use, because "nobody uses that". https://www.jwz.org/doc/cadt.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: The "loop and a half"
bartc writes: > It is anyway not really acceptable these days for a long list of data > to simply be typed in like that without any feedback at all. And 100% > dependent on your typing Ctrl-D at the end and not Ctrl-C by > mistake. This is not still the 1970s. It was not acceptable in the 1970s either. No one did it then and no one does it now. What you are actually saying is that it is not acceptable that the option of unprompted input even exists. -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On Sat, 7 Oct 2017 05:56 am, Chris Angelico wrote: > On Sat, Oct 7, 2017 at 5:47 AM, Marko Rauhamaa wrote: >> Chris Angelico : >> >>> On Sat, Oct 7, 2017 at 4:55 AM, Marko Rauhamaa wrote: Personally, I think stdin is a bit lame as a stimulus source for an interactive program. That's not even what stdin is primarily meant for; stdin is meant to be the input data for a job. Similarly, stdout is meant to be the result of the computation. Stderr, then, is used to deliver optional diagnostic messages, ie, metainfo about the computation. >>> >>> [...] >>> >>> Standard streams exist for a reason. >> >> That's exactly what I said. > > And you also described it as "lame" for an interactive program. I think what Marko meant is that using stdin ALONE, with no prompts, no help, and no explanation, provides a bare-bones, featureless and underpowered user interface unsuitable for an interactive program. Let's come back to sort again: we all agree that sort reading from stdin is *not* a user-friendly interface suitable for an interactive program. "Lame" is a good word to describe an interface so bleakly featureless, underpowered and user-hostile. But that interface wasn't designed for interactive use. It was designed for passing data in via a file or pipe. The fact that it happens to work at all is a happy accident, and one which experienced users can take advantage of, but the primary intention of sort is that it will read from a pipe or a file, not the keyboard. It works because that's how Unix works, not because it was intentionally designed that way. The sorts of games your students write use stdin to get input from the user, but they don't -- or at least, shouldn't -- merely dump the user at a bare screen with no prompt and no explanation of what they're supposed to do. -- 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: The "loop and a half"
On 07/10/2017 01:14, Ben Bacarisse wrote: bartc writes: On 06/10/2017 14:35, Paul Moore wrote: On 6 October 2017 at 13:56, bartc wrote: If you don't like the word 'crude', try 'lazy'. Take this example of the gcc C compiler: > gcc -E program.c This preprocesses the code and shows the result. Typical programs will have many thousands of lines of output, but it just dumps it to the console. You /have/ to use '>' to use it practically (Windows doesn't really have a working '|' system.) Does the Windows version of gcc not support the -o file option? I never thought of trying it. But OK, you have to use -o or > to stop the output from swamping the console. (| might work if I could find a program that captured the piped output for the purpose of browsing.) (In my IDE, if a particular C file is highlighted, then typing 'cpp' will invoke the currently selected C compiler's -E equivalent, then instantly show the result in the editor. Looking at the script for that, that does make use of the -o option, for gcc, so I must have known about it.) And a good system lets you alter that. How many labels are generated for some code? Let's see: gcc -S -o /dev/stdout t.c | grep -c '^\.L' Now gcc also permits -o - (it's a common Unix convention) but you can almost always get round less helpful programs using /dev/sdout. I'm not really arguing against this. I'm disputing the suggestion that because these utilities, which are rarely given data actually typed from the keyboard, work by reading from stdin using an eof-checking loop, that the same method must always be used in programs that really are reading data from the keyboard. I think they are different kinds of applications. (As for the ability to chain these programs together, I have the same opinion of that as doing the same in program code when you use the result of one function/method call to feed in as the argument to the next. They can both end up as long horizontal hard-to-follow (or to intercept) sequences. I'd prefer to break them up using intermediate variables in the language and intermediate files in the shell. And as you can see from my IDE's 'cpp' command, which works with 4 different C compilers (a fifth doesn't properly support -E), there are other approaches developers can use.) -- bartc -- https://mail.python.org/mailman/listinfo/python-list
Warnings (was Re: Interactive scripts (back on topic for once) [was Re: The "loop and a half"])
On Sat, Oct 7, 2017 at 11:19 AM, Steve D'Aprano wrote: > On Sat, 7 Oct 2017 05:33 am, Grant Edwards wrote: > >> On 2017-10-06, Marko Rauhamaa wrote: >> >>> The reason a daemon usually opens dummy file descriptors for the 0, 1 >>> and 2 slots is to avoid accidents. Some library might assume the >>> existence of those file descriptors. For example, I often see GTK print >>> out diagnositic messages. >> >> I run a lot of GTK programs from the command line, and I would say 90% >> or more of them spew a steady stream of meaningless (to the user) >> diagnostic messages. That's pretty sloppy programming if you ask >> me... > > Indeed. > > If you ever start to doubt that the average quality of software is "crap", try > running GUI applications from the command line and watch the stream of > warnings and errors flow by. They range from relatively trivial warnings that > correctly sized icons are missing, to scary looking warnings about > uninitialised pointers. > > Developers: why do you bother to log warnings if you're never going to fix the > damn things? The warnings usually come from the library, but the bugs are in the application. So the question is: is it right for a library to raise console warnings like that? Under what circumstances and to what destinations should a library report on potential problems? IMO the console belongs to the application, not a library. But that means that the logging of warnings needs to be done by the app. I'm not sure what the solution is. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
bartc writes: > On 07/10/2017 01:14, Ben Bacarisse wrote: >> bartc writes: >> >>> On 06/10/2017 14:35, Paul Moore wrote: On 6 October 2017 at 13:56, bartc wrote: > If you don't like the word 'crude', try 'lazy'. Take this example of the > gcc > C compiler: > >> gcc -E program.c > > This preprocesses the code and shows the result. Typical programs will > have > many thousands of lines of output, but it just dumps it to the console. > You > /have/ to use '>' to use it practically (Windows doesn't really have a > working '|' system.) >> >> Does the Windows version of gcc not support the -o file option? > > I never thought of trying it. But OK, you have to use -o or > to stop > the output from swamping the console. (| might work if I could find a > program that captured the piped output for the purpose of browsing.) >> And a good system lets you alter that. How many labels are generated >> for some code? Let's see: >> >>gcc -S -o /dev/stdout t.c | grep -c '^\.L' >> >> Now gcc also permits -o - (it's a common Unix convention) but you can >> almost always get round less helpful programs using /dev/sdout. > > I'm not really arguing against this. I'm disputing the suggestion that > because these utilities, which are rarely given data actually typed > from the keyboard, work by reading from stdin using an eof-checking > loop, that the same method must always be used in programs that really > are reading data from the keyboard. And I'm not arguing about that -- I know there is no point. The way Usenet works is that I reply to the parts I want to comment on. No one can see what made me make the above remark because you cut it, but the combined effect of the two remarks of yours that I commented on was to suggest that gcc makes arbitrary choices about output destinations (and I assume gcc was just an example). I was simply saying that a good OS can finesse such matters. -- Ben. -- https://mail.python.org/mailman/listinfo/python-list
Re: The "loop and a half"
On Sat, 7 Oct 2017 06:18 am, bartc wrote:
> For sort, there is no real need. You use a text editor to create your
> data. Then use existing file-based sort.
What you mean is, *you* see no need for sorting interactively, or sorting as
part of a pipeline of functions. That speaks more of your lack of imagination
and closed-mindedness than any real lack.
Personally, if I have a few (say, a dozen or so) lines I want sorted, it is
much easier to:
- select text from whatever application I'm using;
- bring up a terminal (I almost always have one already open);
- type `sort ENTER`;
- middle-click to paste the lines;
- type Ctrl-D;
- select the output lines;
- paste back into the original application;
(seven steps)
versus:
- select text from whatever application I'm using;
- open a text editor;
- paste into the text editor;
- hit Ctrl-S to save;
- think of a file name ("temp123");
- type it in the file save dialog;
- click SAVE to save;
- invariably the file name is already used from the previous time I
needed a temporary file and forgot to delete it afterwards;
- so look more carefully at the existing files, and think of a new name;
- edit the file name;
- click SAVE again;
- open an external sort program (do I even have one? what's it called again?);
- in the sort program, whatever it is called, type Ctrl-O to open;
- navigate to the directory I saved the temp file;
- open that file;
- sort the file;
- save the output;
- type Ctrl-Q to quit;
- go back to the editor;
- select the File > Reload menu command to reload the now sorted file;
- select the text;
- go back to the application I started with;
- paste;
- go back to the editor and hit Ctrl-Q to quit;
- go to a file manager;
- locate the temporary file;
- hit backspace to send it to the trash
(27 steps).
Yes, I can certainly see why you prefer that second work-flow to the first.
Its so much more inefficient than memorising "Ctrl-D for EOF".
I forget... it is "work harder, not smarter"? Being inefficient is a good
thing, right?
--
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: The "loop and a half"
On Sat, 7 Oct 2017 06:21 am, Chris Angelico wrote: > I'm not sure what printing to a window or image would mean, or how > it's useful, but sure. Print to window: Print Preview. Print to image: export to pdf or jpg or png. More useful for rich GUI apps than plain old text apps, but the basic principle is still sound. I recently had a HUGE LibreOffice draw document, containing a very long mathematical formula, and the only practical way for me to turn it into an image was by taking 14 screenshots and then merging them by hand. A working export to PNG command would have been really useful. -- 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
