import cStringIO
output = cStringIO.StringIO()
output.write('First line.\n')
print >>output, 'Second line.'
# Retrieve file contents -- this will be
# 'First line.\nSecond line.\n'
contents = output.getvalue()
What does >>output in the print statement on line 5 do?
It redirects the print statement output to an open file-like object. See the print statement documentation:
print also has an extended form, defined by the second portion of the syntax described above. This form is sometimes referred to as “print chevron.” In this form, the first expression after the >> must evaluate to a “file-like” object, specifically an object that has a write() method as described above. With this extended form, the subsequent expressions are printed to this file object. If the first expression evaluates to None, then sys.stdout is used as the file for output.
Essentially, the line is translated to output.write('Second line.' + '\n') asprint` adds a newline to it's output unless the expression ends with a comma.
The syntax is based on the bash append >> syntax (which also influenced C++ << and >> I/O operators); see PEP 214 for a full motivation for why this was chosen.
In Python 3, where print() is a function, you'd write:
print('Second line.', file=output)
instead.
Related
When I start an interactive Lua shell, io.write() adds unwanted material after the string I want it to print. print(), however does not:
[user#manjaro lua]$ lua
Lua 5.4.2 Copyright (C) 1994-2020 Lua.org, PUC-Rio
> io.write('hello world')
hello worldfile (0x7fcc979d4520)
> print('hello world')
hello world
And when I use io.write() in a program it works fine too:
--hello.lua
io.write('hello world\n')
print ('hello world')
Output:
[user#manjaro lua]$ lua hello.lua
hello world
hello world
I'm using Manjaro Linux on a Dell desktop. Can anyone tell me what's going on here? Thanks in advance.
EDIT: I should add, perhaps, that the unwanted material is always something like this:
file (0x7f346234d520)
It's always 'file' followed by what looks like a large hexadecimal number in parentheses. The exact number stays constant within one shell session but varies between different shell sessions.
"file (0x7fcc979d4520)" (or whatever address) is the return value of the io.write call, with an implicit tostring.
The lua(1) man page says
In interactive mode, lua prompts the user, reads lines from the standard input, and executes them as they are read. If the line contains an expression or list of expressions, then the line is evaluated and the results are printed.
The trouble here is that io.write('hello world') could be either an expression or a statement. Since it's a valid expression, the interpreter outputs that unwanted return value.
As a workaround, try adding a semicolon:
> io.write('hello world\n');
hello world
Although Lua usually doesn't require a semicolon for each statement if it's at the end of a line, it does allow it. And important here, it means the syntax can't be an expression, only a statement which calls the function. So the interpreter won't output the returned value.
You are just seeing the return value of io.write when you call io.write manually, interactively. When using the Lua, uh, shell, if you want to call it that, it almost always prints the return value of any function(s) you call.
file(blabblah) is the internal representation of the file you are writing to (probably just a hex memory address, but who knows?)
I am writing an interpreter for assembly using lex and yacc. The problem is that I need to parse a word that will strictly be at the end of the file. I've read that there is an anchor $, which can help. However it doesn't work as I expected. I've wrote this in my lex file:
ABC$ {printf("QWERTY\n");}
The input file is:
ABC
without spaces or any other invisible symbols. So I expect the outputput to be QWERTY, however what I get is:
ABC
which I guess means that the program couldn't parse it. Then I thought, that $ might be a regular symbol in lex, so I changed the input file into this:
ABC$
So, if $ isn't a special symbol, then it will be parsed as a normal symbol, and the output will be QWERTY. This doesn't happen, the output is:
ABC$
The question is whether $ in lex is a normal symbol or special one.
In (f)lex, $ matches zero characters followed by a newline character.
That's different from many regex libraries where $ will match at the end of input. So if your file does not have a newline at the end, as your question indicates (assuming you consider newline to be an invisible character), it won't be matched.
As #sepp2k suggests in a comment, the pattern also won't be matched if the input file happens to use Windows line endings (which consist of the sequence \r\n), unless the generated flex file was compiled for Windows. So if you created the file on Windows and run the flex-generated scanner in a Unix environment, the \r will also cause the pattern to fail to match. In that case, you can use (f)lex's trailing context operator:
ABC/\r?\n { puts("Matched ABC at the end of a line"); }
See the flex documentation for patterns for a full description of the trailing context operator. (Search for "trailing context" on that page; it's roughly halfway down.) $ is exactly equivalent to /\n.
That still won't match ABC at the very end of the file. Matching strings at the very end of the file is a bit tricky, but it can be done with two patterns if it's ok to recognise the string other than at the end of the file, triggering a different action:
ABC/. { /* Do nothing. This ABC is not at the end of a line or the file */ }
ABC { puts("ABC recognised at the end of a line"); }
That works because the first pattern will match as long as there is some non-newline character following ABC. (. matches any character other than a newline. See the above link for details.) If you also need to work with Windows line endings, you'll need to modify the trailing context in the first pattern.
What syntax do I use to print "hello world" in the output window?
I simply want to specify the text in the syntax and have it appear in the output.
You need the title command:
title 'this is my text'.
Note that the title can be up to 256 bytes long.
Alternatively, you could use ECHO also. ECHO is useful for debugging macro variable assignements where as TITLE is useful for neat/organised presentation of your tables with intension to perhaps export output results.
If you want to write arbitrary text in its own block in the Viewer rather than having it stuck in a log block, use the TEXT extension command (Utilities > Create text output). You can even include html markup in the text.
If you don't have this extension installed, you can install it from the Utilities menu in Statistics 22 or 23 or the Extensions menu in V24.
example:
TEXT "The following output is very important!"
/OUTLINE HEADING="Comment" TITLE="Comment".
Outfile here is used in an ambiguous way. The prior two answers (the TITLE and ECHO commands) simply print something to the output window. One additional way to print to the output window is the PRINT command.
DATA LIST FREE / X.
BEGIN DATA
1
2
END DATA.
PRINT /'Hello World'.
EXECUTE.
If you do that set of syntax you will actually see that 'Hello World' is printed twice -- one for each record in the dataset. So one way to only print one line is to wrap it in a DO IF statement and only select the first row of data.
DO IF $casenum=1.
PRINT /'Hello World'.
END IF.
EXECUTE.
Now how is this any different than the prior two commands? Besides aesthetic looks in the output window, PRINT allows you to save an actual text file of the results via the OUTFILE parameter, which is something neither of the prior two commands allows.
DO IF $casenum=1.
PRINT OUTFILE='C:\Users\Your Name\Desktop\Hello.txt' /'Hello World'.
END IF.
EXECUTE.
Each expression is on a separate line.
Given
34-2
34-5
34-3
I'm looking to obtain
34-2=28
34-5=29
34-3=31
Or, this would also be helpful:
given:
34-2=5
34-5<=34
34-3=31
I'm looking to obtain
! 34-2=5
34-5<=34
34-3=31
Where ! is some indication that inequality or equality is false. I'm looking for something that processes text files.
Chris Taylor is perfectly right, here is what it gives in python:
>>> s="""34-2
34-5
34-3
34-2==5
34-5<=34
34-3==31
"""
>>> for line in s.split('\n'):
# Test line is not empty
if line:
operators = ('!=', '<=', '>=', '==', '<', '>')
op_found = False
# Stop at 1st operator found
for op in operators:
if op in line:
op_found = True
if not eval(line):
print '!', line
else:
print '+', line
break
# If no operator found, we assume we want the result of the operation
if not op_found:
print '{0}={1}'.format(line, eval(line))
34-2=32
34-5=29
34-3=31
! 34-2==5
+ 34-5<=34
+ 34-3==31
>>>
Several remarks:
I used == instead of = because that's the way equality is in python (= is only used for assignment)
I also used + to show assertion was right for readability purpose
I used a string s but you can of course use a file (you would replace the line for line in s.split('\n'):
by for line in open(file_path):
keep in mind that each time you use eval, you can be hacked (beware of the lines you have in your file...)
I invoked Maxima tex1 from within a batch script as follows:
maxima --very-quiet -r "tex1(solve(8*x^2+7*x+5));" | grep -v false > output.txt
and I got the output.txt as follows:
\left[ x=-{{\sqrt{111}\,i+7}\over{16}} , x={{\sqrt{111}\,i-7}\over{16}} \righ\
t]
that is not valid as a (La)TeX input file.
How to prevent Maxima tex1 from wrapping its output?
Sorry for the late reply.
Instead of
tex1(solve(8*x^2+7*x+5));
write:
?princ(tex1(solve(8*x^2+7*x+5)))$
The problem is that the string returned by tex1 is being printed by the display formatter (the same function which would print the string if you were using Maxima in an interactive session). The display formatter breaks strings at linel characters (default = 79) and inserts a backslash. Instead for your purposes you want to evade the display formatter entirely, so you print the string with ?princ (a Lisp function to just print the string) and terminate the input with "$" instead of ";" to tell Maxima not to call the display formatter.
Note that the hard-coded constant 70 in MYPRINC doesn't come into play here. MYPRINC is not called in the example given.
This is, unfortunately, hard coded into Maxima. A way to solve this problem is to edit the function myprinc located in the file maxima/src/mactex.lisp. There is a cond form that has a 70. written there, it should read linel instead of 70. If you recompile maxima after making this change then the following will work:
maxima --very-quiet -r "linel: 1000$ tex1(solve(8*x^2+7*x+5));" | grep -v false > output.txt
Anyway, I'll send a patch to the Maxima list ASAP so that future versions of the program won't have this shortcoming.