I know there are differences between print and return function, but sometimes, it does the same effect when you get the outputs. Under this condition, how do we differentiate between print and return?
There is a problem there, in fact you are confusing them, but also there are some changes between Python 2 and Python 3.
As Micha said, return is an statement, that would only work if it is inside a function, and would return a parameter list if it is present: return statement doc
And now we have print that depending on the version of Python you are using (Python 3 is the recommended version to use now), you will have either an statement or a function. As of Python 2, print is an statement that evaluates and prints the list of expressions directly to standard input: print doc
But in Python 3, print is a more complex function, which its default behaviour is to print directly to standard output i.e. screen; but you can modify it with its other arguments: print function doc Python 3
Print statement is not longer available in Python 3.
Related
I am new to using gcov and gcovr and I wanted to get the statement coverage of a given function. It is coded in C, compiled with minGW and called from Matlab (which I use to later process the coverage information given by gcov).
I am executing the code in two different ways: for the first one I am using Simulink, in which the function inputs are given by the outputs of other functions that encompass the dynamic process I modelled on Simulink. For the second one, I am using the editor on Matlab and defining directly the inputs to the function.
Because the Simulink - executed code depends on secondary functions whose output I cannot control (contrary to the second way), I expected the statement coverage of the first execution to be worse than the second but to have the same number of statement lines (since it is exactly the same code). However, I found that:
For some function callers inside the function, the second method counts the few lines of the caller (like the first line and the following lines when the input and output variables are too long to fit in a single line), adding up statements that in reality don't exist.
The first method doesn't take into account some variable definitions at the beginning of the code, not counting them as line statements (for instance, setting input variables to 0).
Has anybody also encountered this discrepancy when getting the statement coverage of the same function? Do you know why this may be?
Thank you very much in advance!
As it is known, Lua 5.3 handles interactive REPL to differentiate expressions and statements this way:
In interactive mode, Lua repeatedly prompts and waits for a line. After reading a line, Lua first try to interpret the line as an expression. If it succeeds, it prints its value. Otherwise, it interprets the line as a statement. If you write an incomplete statement, the interpreter waits for its completion by issuing a different prompt.
However, this is not the behavior I want. For example, I have some codes "f()" to evaluate, where f will through error, no matter what happens. it also change the internal state of lua. The above approach will cause bugs because it will change the internal state twice.
So, I'd like to know, is there a way to implement a REPL that auto disambiguate expressions and statements? Do I have to add some syntax analysis to achieve this?
Interpreting code in Lua REPL is a two step process. First you convert the input to a runnable code with loadstring or a similar function. The code has been validated to be correct but didn’t run yet. Then you explicitly invoke it.
fn = loadstring(“return 42”);
fn()
To summarize, parsing and validating code with loadstring() or a similar function is side effect free, as long as you don’t invoke the result.
I am creating a caching system for complex shapes in Lua and I want it to be backwards compatible as a plug and play replacement for the default, non cached system, to increase performance. I've successfully rendered an object with 6.4 million points which gets turned into 3.1 million trapezoids to make a shape instead of using 6.4 million triangles, cache it and continue rendering without any performance hit beyond initial caching.
I want to set up a cached data table which uses the reference to the original table as the index. The problem is, if I use tostring, I end up with the entire table as a nicely formatted human-readable string which wouldn't be nice to use as a short index to reference the table.
I do not want to require the dev to assign an ID to the object because the default system doesn't do this, and it is an extra step which can be avoided by simply using the address which is unique to that object anyways..
I can not find a Lua implementation of lua_topointer(L, idx)... but maybe I'm missing something?
A few issues - my tostring no longer shows table: 0x12345678
I have rewritten a lot of meta-functions and __tostrings to output the data for debugging purposes. But, on Lua demo I can't find the exact function which replaces this behavior, and I didn't replace print in my latest version. So print is default, etc...
On Lua demo I have also tried getmetatable table, function m:__tostring( ) return 'blah' end
and print( { } ), print( tostring( { } ) )
The first prints the address. The second prints blah. So because print isn't using tostring, by default, what is it using? Is that accessible via Lua?
If all else fails, I'll probably have to get rid of my __tostring table metamethod and make a secondary function to output that particular data type which defaults the purpose of having a __tostring method for everything ( and the fact that print ignores it; one of the reasons I rewrote print in an old version... but I reverted to keep it default )
So, does anyone know a Lua function I can call, which is not tostring, which can get the address of a table in Lua? It must return the value so it can be used.
I would like to apply different conversion function to the parameters of an option.
Consider this following code:
parser:option('-c --circle')
:argname{'<radius>', '<coordinates>'}
-- does not work like this:
-- :convert{['<radius>']=tonumber, ['<coordinates>']=tocoords}
:default{1, {0,0}}
:args(2)
:count '0-1'
As you can see the program has an option -c which takes two parameters: radius and coordinates. I would like to apply to different conversion functions (tonumber and tocoords) respectively. Reading the documentation I can't figure out how to do this.
Is this possible and if so then what is the correct way to set this up?
Since argparse 0.6.0 this works:
:convert{tonumber, tocoords}
See documentation:
If convert property of an element is an array of functions, they will be used as converters for corresponding arguments in case the element accepts multiple arguments.
If you are correct that the Lua Argparse system does not allow you to specify multiple functions to convert the arguments to a specific option, then there may still be a way to do it. After all, Argparse has to call your conversion function once for each argument. And there's no rule that the conversion function has to do the same thing for each invocation. The only information you don't have is the particular argument it is being called on.
So... cheat. Create that information, by using Lua's first-class functions (note: the following uses Lua 5.3):
local function multi_arg_parser(...)
local index = 0
local funcs = table.pack(...)
return function(...)
index = index + 1
return funcs[index](...)
end
end
parser:option('-c --circle')
:argname{'<radius>', '<coordinates>'}
:convert(multi_arg_parser(tonumber, tocoords))
:default{1, {0,0}}
:args(2)
:count '0-1'
This will work provided that Argparse will call the convert function exactly once for each argument and call convert on the arguments in the order they appear in the command line. That is almost certainly not guaranteed by Argparse, but it's a reasonable assumption.
I would suggest using the Lapp Framework. It supports conversions via a converter method passed to the add_type method. Also, it comes with other convenient features, like assertions and default values.
I'm learning Lua, and I want to know the difference of print() and = or print() and io.write().
print is used for outputting text messages. It joins its arguments with a tab character, and automatically inserts a newline.
io.write is more simple. While it also accepts any number of arguments, it simply concatenates them (without inserting any characters) and doesn't add any newline. Think of it as file:write applied to the standard output.
These lines are equivalent:
io.write("abc")
io.write("a", "b", "c")
io.write("a") io.write("b") io.write("c")
I'd recommend using print for outputting normal text messages, or for debug, and io.write when you either want to print a number of strings without concatenating them explicitly (using io.write saves more memory), be able to write parts of a text separately, or outputting binary data via strings.
This short paragraph from "Programming in Lua" explains some differences:
21.1 The Simple I/O Model
Unlike print, write adds no extra characters to the output, such as
tabs or newlines. Moreover, write uses the current output file,
whereas print always uses the standard output. Finally, print
automatically applies tostring to its arguments, so it can also show
tables, functions, and nil.
There is also following recommendation:
As a rule, you should use print for quick-and-dirty programs, or for
debugging, and write when you need full control over your output
Essentially, io.write calls a write method using current output file, making io.write(x) equivalent to io.output():write(x).
And since print can only write data to the standard output, its usage is obviously limited. At the same time this guarantees that message always goes to the standard output, so you don't accidently mess up some file content, making it a better choice for debug output.
Another difference is in return value: print returns nil, while io.write returns file handle. This allows you to chain writes like that:
io.write('Hello '):write('world\n')