Re: File opening modes (r, w, a ...)
jf...@ms4.hinet.net wrote:
> ast於 2018年2月22日星期四 UTC+8下午8時33分00秒寫道：
>> Hello
>>
>> I share a very valuable table I found on
>> StackOverflow about file opening modes
>>
>> If like me you always forget the details of
>> file opening mode, the following table provides
>> a good summary
>>
>>| r r+ w w+ a a+
>> --|--
>> read | + +++
>> write | ++ ++ +
>> write after seek | ++ +
>> create| + ++ +
>> truncate | + +
>> position at start | + ++ +
>> position at end | + +
>
> What the "write after seek" means?
It /should/ mean that programs are permitted to seek to a point in the file,
and then write from that point on.
A write to a read mode ("r") file isn't permitted at all,
so neither is "write after seek" to a read mode file.
A write to an append mode ("a" and "a+") file always write to the end of the
file, effectively negating any seek.
HTH
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
--
https://mail.python.org/mailman/listinfo/python-list
Re: Proposed new syntax
Marko Rauhamaa wrote: > Gregory Ewing : >> I don't agree that the word "for" necessarily implies proceduralness. > > Programming languages stole the word from math, where it is > nonprocedural. > > Really, "for" is just a preposition. In Algol, for example, > proceduralness was not in the word "for" but in "do": [snip] > I guess we have C to blame for the redefinition of the word "for" in > programmers' minds. Sorry, but that use of "for" was part of the programmer's lexicon well before the invention of C. Computer languages have inherited and used it since (at least) 1948. Dartmouth BASIC (1964) had "FOR" FOR I=1 TO 10 ALGOL-60 (1960) had "for" for i:=1 step 1 until 10 ALGOL-58 (1958) had "for" for i:=1(1)10 Superplan (1948) had "fur" (German for the English word "for") Für k=1(1)10 : -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request -- https://mail.python.org/mailman/listinfo/python-list
Re: Pound sign problem
Chris Angelico wrote: > On Wed, Apr 12, 2017 at 1:24 AM, Lew Pitcher > wrote: >> >> What in "Try changing your target encoding to something other than ASCII" >> is encouragement to use "old legacy encodings"? >> >>> In 2017, unless you are reading from old legacy files created using a >>> non-Unicode encoding, you should just use UTF-8. >> >> Thanks for your opinion. My opinion differs. > > So what encoding *do* you recommend, and why is it better than UTF-8? I recommend whatever encoding is appropriate for the output. That's not up to you or me to decide; that's a question that only the OP can answer. (Imagine, python on an IBM Zseries running ZOS; the "native" characterset is one of the EBCDIC variants. Would UTF-8 be a better choice there? ) -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request -- https://mail.python.org/mailman/listinfo/python-list
Re: Pound sign problem
Steve D'Aprano wrote: > On Tue, 11 Apr 2017 12:50 am, Lew Pitcher wrote: > >> David Shi wrote: >> >>> In the data set, pound sign escape appears: >>> u'price_currency': u'\xa3', u'price_formatted': u'\xa3525,000', > > That looks like David is using Python 2. > >>> When using table.to_csv after importing pandas as pd, an error message >>> persists as follows: UnicodeEncodeError: 'ascii' codec can't encode >>> character u'\xa3' in position 0: ordinal not in range(128) >> >> There is no "pound sign" in ASCII[1]. Try changing your target encoding >> to something other than ASCII. > > Please don't encourage the use of old legacy encodings. I wonder if you actually read my reply. What in "Try changing your target encoding to something other than ASCII" is encouragement to use "old legacy encodings"? > In 2017, unless you are reading from old legacy files created using a > non-Unicode encoding, you should just use UTF-8. Thanks for your opinion. My opinion differs. -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request -- https://mail.python.org/mailman/listinfo/python-list
Re: Pound sign problem
David Shi wrote: > In the data set, pound sign escape appears: > u'price_currency': u'\xa3', u'price_formatted': u'\xa3525,000', > When using table.to_csv after importing pandas as pd, an error message > persists as follows: UnicodeEncodeError: 'ascii' codec can't encode > character u'\xa3' in position 0: ordinal not in range(128) There is no "pound sign" in ASCII[1]. Try changing your target encoding to something other than ASCII. [1]: See http://std.dkuug.dk/i18n/charmaps/ascii for a list of valid ASCII values. -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request -- https://mail.python.org/mailman/listinfo/python-list
Re: best way to ensure './' is at beginning of sys.path?
On Saturday February 4 2017 13:56, in comp.lang.python, "Wildman" wrote: > On Sat, 04 Feb 2017 18:25:03 +, Grant Edwards wrote: > >> On 2017-02-04, Wildman via Python-list wrote: >> >>> No, I do not know. You might try your question in a linux specific >>> group. Personally I don't understand the danger in having the dot >>> in the path. The './' only means the current directory. >> >> It allows a malicous user to put an evil executable someplace public >> like /tmp and have it executed accidentally. For example, let's say >> this executable file was named "sl" and placed in /tmp. >> >> --sl-- >> #!/bin/bash >> rm -rf $HOME >> -- >> >> The next time you are in the /tmp directory looking for something, can >> you guess what happens when you mistype "ls" as "sl"? >> >>> DOS and Windows has searched the current directory since their >>> beginning. Is that also dangerous? >> >> Yes. > > Your scenario assumes the malicious user has root access > to be able to place a file into /tmp. It doesn't take root access to write a file to /tmp In fact, /tmp is specifically set up to allow /any/ user to create /any/ file or directory in it. Witness: guest@bitsie:~$ whoami guest I'm not the root account guest@bitsie:~$ groups users audio video cdrom plugdev scanner Nor do I have proxy root access (wheel group) guest@bitsie:~$ ls /tmp 58949ba84867f 58949bab2fe41 ksocket-lpitcher/ 58949ba87a976 gpg-15lbqc/lost+found/ 58949ba87b6d7 kde-lpitcher/ ssh-0DwhGZKgCeHE/ That's what /tmp has in it right now guest@bitsie:~$ cat >/tmp/dothis < #!/bin/bash > echo gotcha > EOF There. I've created a script as a file in /tmp No root access required; no special privileges at all guest@bitsie:~$ chmod a+x /tmp/dothis Hey! I've even made the file executable guest@bitsie:~$ ls -l /tmp total 120 -rw--- 1 lpitcher users 23735 Feb 3 10:03 58949ba84867f -rw--- 1 lpitcher users 23735 Feb 3 10:03 58949ba87a976 -rw--- 1 lpitcher users 23735 Feb 3 10:03 58949ba87b6d7 -rw--- 1 lpitcher users 23735 Feb 3 10:03 58949bab2fe41 -rwxr-xr-x 1 guestusers24 Feb 4 14:05 dothis* drwx-- 2 lpitcher users 4096 Feb 4 10:10 gpg-15lbqc/ drwx-- 2 lpitcher users 4096 Feb 4 13:47 kde-lpitcher/ drwx-- 2 lpitcher users 4096 Feb 4 14:01 ksocket-lpitcher/ drwx-- 2 root root 4096 Jan 10 2012 lost+found/ drwx-- 2 lpitcher users 4096 Feb 4 10:10 ssh-0DwhGZKgCeHE/ See? /tmp/dothis is an executable file, owned by guest guest@bitsie:~$ /tmp/dothis gotcha See? It is executable Now, imagine that guest had, instead, written /tmp/sl as #!/bin/bash cd $HOME rm -rf ./ and made it executable. If /tmp were part of the $PATH, and there were no other executables named "sl" found in PATH directories before the /tmp directory, then anyone making that simple typo would execute guest's /tmp/sl and lose their home directory. > And there would > have to be some reason why I would be looking around in > /tmp. If you've set your $PATH to include /tmp, then /that's/ the "reason why" you'd "be looking around in /tmp". But, this argument can be said for /any/ directory that untrusted users have write access to (including your own $HOME directory); include that directory in your $PATH, and you risk executing a trojan binary. > After 10 years of using Linux, it hasn't happened > yet. And last I would have to be a complete idiot. > > I suppose all that could be a reality, but, how many > computers do you know of have been compromised in this > manor? Probably many, especially in high-use, public or semi-restricted systems like those found in Universities, libraries, and other "public" institutions. Even corporate systems have this exposure, which is why large corporations spend a lot of money on Information Systems security. -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Thursday December 8 2016 11:48, in comp.lang.python, "Random832" wrote: > On Wed, Dec 7, 2016, at 15:29, Lew Pitcher wrote: >> But, point of fact is that the feature to disable globbing is not often >> needed. Most Unix programs that accept filenames are happy to accept a >> list of filenames. There is not much call for a program to perform it's own >> globbing, like is required in Windows. >> >> In fact, I can only think of three Unix "commandline" programs that need >> shell globbing disabled: >> find - which performs it's own filename matching >> grep - which uses regular expressions to search the contents of files, >> and >> sed - which uses regular expressions to edit the contents of files. >> (I'm sure that there are a few more examples, though). > > tar can do its own filename matching in some contexts, to match files > inside the archive for example. > > 7z does its own filename matching to allow distinguishing "extract from > multiple archives" [x \*.zip] from "extract a list of filenames from a > single archive" [x a.zip b.zip] - a BartC-compliant command line > paradigm if I ever saw one. I suspect it also allows you to match files > inside the archives in the list part. > > scp lets you pass glob patterns to be matched on the remote server. > also, quoting for scp is somewhat unpleasant, since metacharacters in > general, not just globs but also $variables, quotes,`commands` etc, are > interpreted by both the local shell and the remote shell. sftp is a > little more sane, but still has remote globs for fetching, and quotes to > escape those globs. True. I had forgotten those. Still, it's a short list of programs that either need to do their own globbing, or need the shell to NOT glob for them. -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Wednesday December 7 2016 14:57, in comp.lang.python, "BartC" wrote: > On 07/12/2016 18:02, BartC wrote: > >> If I want to run a Windows program on Linux, and that program needs to >> see *.* unexpanded, then it can't undo that expansion. The cat is >> already out of the bag. > > I mean, the genie is out of the bottle, whatever. You know what I mean, > the operation is not reversible. So, don't pull the cork. Look, Bart, in a Unix shell, the user has the option to enable or disable globbing (that action that converts the argument * into a list of files). A Unix shell can give a program exactly the same list of unaltered arguments that a Windows shell can. But, point of fact is that the feature to disable globbing is not often needed. Most Unix programs that accept filenames are happy to accept a list of filenames. There is not much call for a program to perform it's own globbing, like is required in Windows. In fact, I can only think of three Unix "commandline" programs that need shell globbing disabled: find - which performs it's own filename matching grep - which uses regular expressions to search the contents of files, and sed - which uses regular expressions to edit the contents of files. (I'm sure that there are a few more examples, though). If your argument is with Unix shell globbing, I say that you can disable it. If your argument is with Python's use of the default shell options to parse commandlines in the Popen() method, then you need to talk to the authors of Python to see if they can give you a way to alter this behaviour. Otherwise, you are just being cranky and argumentative. Stop it. Suck it up and move on. The world doesn't revolve around BartC, no matter how loud he yells. -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Tuesday December 6 2016 12:36, in comp.lang.python, "BartC" wrote: > On 06/12/2016 17:00, MRAB wrote: >> On 2016-12-06 13:52, BartC wrote: > >>> Some special syntax is known about: | < and > for example. % less so >>> (I've never, ever used it in live input AFAIK). >>> >> [snip] >> >> You've never used ImageMagick? >> >> If you want to shrink an image to half its size: >> >> convert dragon.gif -resize 50% half_dragon.gif > > No. But that '50%' is seen by apps (eg. with Python's 'print sys.argv') > on both Windows and Linux. > > However, I can imagine that a calculator app might have trouble with > some expressions: > > calculate 3*5 I can't see this being an issue with the "calculator app", unless the calculator app itself is written to perform file globbing. It /might/ be an issue with the shell, if you permit it to glob the "calculator app" arguments before invoking the "calculator app" binary. But, then again, Unix shell filename globbing is something that the user can disable temporarily or permanently if necessary. For example: calculate '3*5' or sh -o noglob -c "calculate 3*5" or even sh -o noglob calculate 3*5 > This expression might be seen as 345 if there happens to be file called > '345' lying around. Only if shell globbing is enabled, and you don't specifically bypass it. -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request -- https://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
On Monday December 5 2016 17:24, in comp.lang.python, "Chris Angelico" wrote: > On Tue, Dec 6, 2016 at 8:38 AM, Lew Pitcher > wrote: >> The OP asked for the runlevel, not the systemd target. > > Runlevels don't exist in systemd. And systemd targets don't exist in > Upstart. The question "what runlevel are we in" does not make sense > unless you're using an init system that works on the basis of > runlevels (eg sysvinit). I repeat: The OP asked for the runlevel, not the systemd target. That should tell you that an answer involving systemd "does not make sense". To the OP: as others have said, the file /var/run/utmp contains various records, including the RUN_LVL (runlevel) record. You can find some documentation in utmp(3), including a record layout, and an values list. I don't know that python includes a standard or builtin method to parse the utmp file; to retrieve the runlevel, you may have to code your own access routine as part of your python code, or resort to invoking an external program like who(1). HTH -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request -- https://mail.python.org/mailman/listinfo/python-list
Re: Detect Linux Runlevel
On Monday December 5 2016 16:25, in comp.lang.python, "DFS"
wrote:
> On 12/05/2016 03:58 PM, Wildman wrote:
>> I there a way to detect what the Linux runlevel is from
>> within a Python program? I would like to be able to do
>> it without the use of an external program such as 'who'
>> or 'runlevel'.
>
>
> Why not?
>
> '>>> import os
> '>>> os.system("systemctl get-default")
> graphical.target
Because
$ cat rlevel.py
import os
os.system("systemctl get-default")
16:36 $ python rlevel.py
sh: systemctl: command not found
16:36 $
> systemd 'graphical.target' corresponds to the old runlevel 5.
Yes? So?
The OP asked for the runlevel, not the systemd target.
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
--
https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Monday December 5 2016 11:23, in comp.lang.python, "BartC" wrote: > On 05/12/2016 15:53, Chris Angelico wrote: >> On Tue, Dec 6, 2016 at 2:41 AM, BartC wrote: >>> >>> Are you saying that if someone executes: >>> >>> subprocess.Popen(["python","a.py", "*"]) >>> >>> the output will be: ['a.py','*']? >>> >>> In that case forget Windows vs. Linux, you now have a program that will >>> get command parameters processed differently depending on whether it was >>> invoked from a shell or not. >> >> Yes, that is correct. *SHELLS DO STUFF*. If you can't comprehend this, >> you should get to know your shell. Try this: >> >> python a.py %PATH% >> >> subprocess.Popen(["python", "a.py", "%PATH%"]) >> >> Would you expect those to do the same? If you do, prepare for Windows >> to surprise you. If you don't, why do you keep expecting other shells >> to do nothing? > > You still don't get point. I write a program P, a native executable. It > takes command line parameters but exactly what it gets depends on > whether it's started from a 'shell' or from inside another program? In Unix, it always has. > I > don't want to worry about that stuff or exactly how it is invoked! Then, I guess that you have a problem, don't you? > > subprocess.Popen(["python", "a.py", "%PATH%"]) > > Yes, %...% is an escape sequence. Those % signs are supposed to stand > out and have been chosen not to clash with typical input. > > And the end result of the transformation is, here, also a SINGLE thing; > any parameter following will still be the second parameter, not the 14771th! > > Are you saying that the * in ABC*EF also makes the whole thing some > escape pattern? If you ask the shell to parse the arguments, then, "YES, the * in ABC*EF makes the argument a candidate for globbing". > And one that could massively expand the number of parameters, Yes > pushing all the following ones out of the way, and making it > impossible to discover where these expanded parameters end and the > normal ones recommence. The best way to think about it is that all parameters are parameters, whether derived from a glob input to a shell, or explicitly specified in the invocation. If you have a need for positional parameters, then either specify that your code only accepts them in specific places, or find a way to disable globbing (it can be done) and handle the expansion yourself, in your own code. > If someone had thought this up now, it would rapidly be dismissed as > being unworkable. But because it's been in Unix/Linux/whatever so long, > no one can see anything wrong with it! Primarily because there /IS/ nothing wrong with it. -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request -- https://mail.python.org/mailman/listinfo/python-list
Re: python 2.7.12 on Linux behaving differently than on Windows
On Monday December 5 2016 10:41, in comp.lang.python, "BartC" wrote: > On 05/12/2016 15:05, Chris Angelico wrote: >> On Tue, Dec 6, 2016 at 1:11 AM, BartC wrote: >>> >>> BTW what does Popen() do when one argument is '*.*'? Will that get >>> expanded to multiple extra arguments, and at what point will it be >>> expanded? >> >> Nope. Popen is not a shell. >> >> It sounds as if you want a nerfed shell. Go ahead! I'm sure one >> exists. It'll frustrate you no end once you get used to a better >> shell, though - always does when I find myself on Windows... > > That's not the point I was making. > > Say you have this program a.py: > >import sys >print (sys.argv) > > And let's say there are just 3 files in the current directory: a.py, > b.py and c.py. > > If run from a Linux shell: > >python a.py * > > The output is: ['a.py', 'b.py', 'c.py'] or something along those lines > (there might be two copies of a.py). And, that's because, before invoking Popen, the SHELL has globbed that '*' argument into the three filenames and substituted those names where the '*' was. If you don't use a shell, then (on Unix), you have to perform the globbing yourself before invoking Popen. > > Are you saying that if someone executes: > >subprocess.Popen(["python","a.py", "*"]) > > the output will be: ['a.py','*']? > > In that case forget Windows vs. Linux, you now have a program that will > get command parameters processed differently depending on whether it was > invoked from a shell or not. Yes. > Or a program that sometimes will see "*" as an argument, and sometimes a > big list of files that merges into all the other arguments. > Yes. -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request -- https://mail.python.org/mailman/listinfo/python-list
Re: Question about working with html entities in python 2 to use them as filenames
On Tuesday November 22 2016 15:54, in comp.lang.python, "Steven Truppe"
wrote:
> I've made a pastebin with a few examples: http://pastebin.com/QQQFhkRg
>
>
>
> On 2016-11-22 21:33, Steven Truppe wrote:
>> I all,
>>
>>
>> i'm using linux and python 2 and want to parse a file line by line by
>> executing a command with the line (with os.system).
>>
>> My problem now is that i'm opening the file and parse the title but
>> i'm not able to get it into a normal filename:
>>
>>
>> import os,sys
>>
>> import urlib,re,cgi
>>
>> import HTMLParser, uincodedata
>>
>> import htmlentiytdefs
>>
>> imort chardet
>>
>> for ULR in open('list.txt', "r").readlines():
>>
>> teste_egex="(.+?)
>>
>> patter = re.compile(these_regex)
>>
>> htmlfile=urlib.urlopen(URL)
>>
>> htmltext=htmlfile.read()
>>
>> title=re.aindall(pater, htmltext)[0]
>>
>> title = HTMLParser.HTMLParser.unescape(title)
>>
>> print "title = ", title
>>
>> # here i would like to create a directory named after the content of
>> the title
>>
>>
>> I allways get this error:
>>
>> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 2
>>
>>
>>
>> i've played around with .ecode('latin-1') or ('utf8') but i was not
>> yet able to sove this simple issue.
I'm no python programmer, but I do have a couple of observations.
First, though, here's an extract from that pastebin posting of yours:
> print "Title = ", title.decode()
>
> - RESULT
> Title = Wizo - Anderster Full Album - YouTube
> Title = Wizo - Bleib Tapfer / für'n Arsch Full Album - YouTube
> Title = WIZO - Uuaarrgh Full Album - YouTube
> Title = WIZO - Full Album - "Punk gibt's nicht umsonst! (Teill
III)" - YouTube
> Title = WIZO - Full Album - "DER" - YouTube
> Title = Alarmsignal - Wir leben - YouTube
> Title = the Pogues - Body of an american - YouTube
> Title = The Pogues - The band played waltzing matilda - YouTube
> Title = Hey Rote Zora - Heiter bis Wolkig - YouTube
> Title = Für immer Punk - die goldenen Zitronen - YouTube
> Title = Fuckin' Faces - Krieg und Frieden - YouTube
> Title = Sluts - Anders - YouTube
> Title = Absturz - Es ist schön ein Punk zu sein - YouTube
> Title = Broilers - Ruby Light & Dark - YouTube
> Title = Less Than Jake 02 - My Very Own Flag - YouTube
> Title = The Mighty Mighty Bosstones - The Impression That I Get - YouTube
> Title = Streetlight Manifesto - Failing Flailing (lyrics) - YouTube
> Title = Mustard Plug - Mr. Smiley - YouTube
>
> But when i try:
> os.mkdir(title)
> i get the following:
> UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 23:
> ordinal not in range(128)
Now for the observations
1) some of your titles contain the '/' character, which on your platform
(Linux) is taken as a path separator character. The os.mkdir() method
apparently expects it's "path" argument to name a file in an already existing
directory. That is to say, if path is "/a/b/c", then os.mkdir() expects that
the directory /a/b will already exist. Those titles that contain the path
separator character will cause os.mkdir() to attempt to create a file in a
subdirectory of the current directory, and that subdirectory doesn't exist
yet. You either have to sanitize your input to remove the path separators,
and use os.mkdir() to create a file named with the name of the sanitized
path, /or/ use os.makedirs(), which will create all the subdirectories
required by your given path.
2) Apparently os.mkdir() (at least) defaults to requiring an ASCII pathname.
Those of your titles that contain Unicode characters cannot be stored
verbatim without either
a) re-encoding the title in ASCII, or
b) flagging to os.mkdir() that Unicode is acceptable.
Apparently, this is a common problem; a google search brought up several pages
dedicated to answering this question, including one extensive paper on the
topic (http://nedbatchelder.com/text/unipain.html). There apparently are ways
to cause os.mkdir() to accept Unicode inputs; their effectiveness and
side-effects are beyond me.
HTH
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
--
https://mail.python.org/mailman/listinfo/python-list
RE: What you can do about legalese nonsense on email (was: How to split value where is comma ?)
On Thursday September 8 2016 17:17, in comp.lang.python, "Joaquin Alzola" wrote: > Hi Ben > > Thanks for the advice. > >> * Complain > > Basically what all comes down is to complain. I wonder if in a company of > 80,000 people I will manage to change that behaviour. Why don't you, at least, include a "signature" line at the end of /your/ text. That way, the automatically-added "confidentiality clause" will end up appended to the signature. Since many news readers discard or suppress display of the signature, the "confidentiality clause" won't be as much of an issue. > This email is > confidential and may be subject to privilege. If you are not the intended > recipient, please do not copy or disclose its content but contact the sender > immediately upon receipt. A signature begins with a line consisting only of two hyphens followed by a space. Any lines that follow that line are considered to be part of the signature. -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request -- https://mail.python.org/mailman/listinfo/python-list
Re: Logic problem: need better logic for desired thruth table.
On Thursday May 28 2015 17:50, in comp.lang.c, "Skybuck Flying"
wrote:
> Hello,
>
> I was just coding and ran into a little logic problem which is as follows:
>
> There are two booleans/variables which can be either false or true.
>
> The desired thrutle table is:
>
> A = input
> B = input
> C = output
>
> A B C:
> ---
> F F T
> F T F
> T F T
> T T T
Seems simple enough: C == A || !B
18:38 $ cat testlogic.c
#include
#include
/*
** A = input
** B = input
** C = output
**
** A B C:
** ---
** F F T
** F T F
** T F T
** T T T
*/
int testlogic(int a, int b)
{
return (a || !b);
}
int main(void)
{
/* A B C */
int ttable[4][3] = { {0,0,1},/* F F T */
{0,1,0},/* F T F */
{1,0,1},/* T F T */
{1,1,1} /* T T T */
};
int rc = EXIT_SUCCESS;
int i, max;
for (i = 0, max = sizeof(ttable) / sizeof(ttable[0]); i < max ; ++i)
if (testlogic(ttable[i][0],ttable[i][1]) != ttable[i][2])
{
printf("testlogic failed on test %d\n",i);
rc = EXIT_FAILURE;
}
if (rc == EXIT_SUCCESS) puts("SUCCESS");
return rc;
}
18:39 $ cc -o testlogic testlogic.c
18:39 $ ./testlogic
SUCCESS
--
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request
--
https://mail.python.org/mailman/listinfo/python-list
