Develop Reference

Python 3 not recognizing boolean condition

I am migrating python2 code to python3 and have learned there are some minor differences in the call parameter handling that is stricter in python3. This same code used to determine if a feature was enabled by the conditional boolean floatclock_enabled. After adding several log print lines in the code, I was able to confirm that the first line of code was always resolving to True, even when I logged the string before and after the test. The print results were both False, yet it ran True in the flow.
if ss.floatclock_enabled:
It looks like a bug to me and the way I solved it was the following line.
if str(ss.floatclock_enabled) == 'True':
Any suggestions where this anomaly might be caused? My other _enabled variables work normally, so far.

Probably it's not next Python, check this https://docs.python.org/3/library/logging.html#logrecord-attributes for thread and threadName to include this into your logs to be sure that they are from the same thread. Also print floatclock_enabled via repr, if it has string value "False" it would be printed as False, but evaluates to boolean True.

Thank you very much for the quick responses. After further analysis, I found in my long list of configparser load items I had used config.get instead of config.getboolean. Since my initial load used the boolean get, I assumed it wouldn't matter later until I scrutinized my code. Again, I appreciate the quick response and suggestions. I will be scrutinizing more before the next time I post!

Scrapy Shell: How to execute multiple lines of code in shell?

You will see in the screenshot that pressing enter after pasting a multiline code doesnt run it but merely send each time a "...".
How can I run this multiline pasted code?
someone asked here, but did not get (the right) answer;
Did not work:
Backspace
Use the arrow key to move the cursor, then use the delete key
Escape
F2

Pressing enter twice when inside the Python interpreter executes a block of code, but you have an unmatched open parenthesis on the last line, so you haven't completed defining the block of code. Also, I'm not sure what dic is in the last line, because you haven't included its definition, so you may need to fix that as well.

Running
a=[1,2]
for x in a:
print(x)
actually works (pressing 2 enters worked as expected). So I made a mistake in the code above. I aplogise, I should have checked that before.
I don't delete the question since the one on google can be confusing (the guy did not mentioned it was his mistake, so I though there was a trick to be found. The trick is to check the code).

you could use IPython link which simplifies the process, better yet you have access to every command line as if executed inside the shell.
The other alternative is to encapsulate this inside a function

I know this answer is a bit late, but someone will need the information sometime:
When you make a new line, i.e. title.quote.... you need to press the tab to create an indent, then it will work. Without indenting, you get the "expected an indent" error message.

Python 3.x multi line comment throws syntax error

I'm working on a Python project and as of now, my code has over 400+ lines. At one point, I had to write a multi-line comment about a small bug which needs a work around, and the interpreter decided to throw a syntax error.
According to the interpreter, the syntax error is occuring at elif.
I re-checked my indentation, converted tabs to spaces etc. Nothing seems to work.
if some_condition_1 == True:
do_something()
"""
Sub stage (b):
Refer documentation [1.7A] for ...
....
....
....
"""
elif condition_1 == True:
if condition_2 == False:
list.append(item)
However, if I remove the multi-line comment, the code executes fine.
Any idea what's going wrong? Please note that the code sample I've show above, is at very top of the file, and there's no chance for anything to go wrong elsewhere.

This is an indentation error. Your "multi-line comment" (really multi-line string) must be indented under the if block just like anything else.
""" These kinds of things """ are not really comments in Python. You're just creating a string and then throwing the value away (not storing it anywhere). Since Python doesn't have true multi-line comments, many people use them this way. However, since they are not true comments (they aren't ignored by the interpreter), they must obey all normal syntax rules, including indentation rules.
(Do note that when I say "creating a string" I'm speaking loosely. CPython, at least, has an optimization not to create an object here.)

Does python have an EXIT_SUCCESS constant?

I'm returning 0 all over the place in a python script but would prefer something more semantic, something more readable. I don't like that magic number. Is there an idea in python similar to how in C you can return EXIT_SUCCESS instead of just 0?
I was unable to find it here:
https://docs.python.org/3.5/library/errno.html

I'm returning 0
return is not how you set your script's exit code in Python. If you want to exit with an exit code of 0, just let your script complete normally. The exit code will automatically be set to 0. If you want to exit with a different exit code, sys.exit is the tool to use.
If you're using return values of 0 or 1 within your code to indicate whether functions succeeded or failed, this is a bad idea. You should raise an appropriate exception if something goes wrong.

Since you discuss return here, it seems like you may be programming Python like C. Most Python functions should ideally be written to raise an exception if they fail, and the calling code can determine how to handle the exceptional conditions. For validation functions it's probably best to return True or False - not as literals, usually, but as the result of some expression like s.isdigit().
When talking about the return value of a process into its environment you caonnt use return because a module isn't a function, so a return statement at top level would be flagged as a syntax error. Instead you should use sys.exit.
Python might seem a little minimalist in this respect, but a call to sys.exit with no arguments defaults to success (i.e. return code zero). So the easiest way to simplify your program might be to stop coding it with an argument where you don't want to indicate failure!
As the documentation reminds us, integer arguments are passed back, and string arguments result in a return code of 1 and the string is printed to stderr.
The language doesn't, as far as I am aware, contain any constants (while it does have features specific to some environments, if it provided exit codes their values might need to be implementation- or platform-specific and the language developers prefer to avoid this where possible.

When would `if False` execute in Python?

While browsing some code, I came across this line:
if False: #shedskin
I understand that Shedskin is a kind of Python -> C++ compiler, but I can't understand that line.
Shouldn't if False: never execute? What's going on here?
For context:
This is the whole block:
if False: # shedskin
AStar(SQ_MapHandler([1], 1, 1)).findPath(SQ_Location(1,1), SQ_Location(1,1))
More context is on Google Code (scroll down all the way).

It won't execute, because it isn't supposed to. The if False: is there to intentionally prevent the next line from executing, because that code's only purpose is seemingly to help Shed Skin infer type information about the argument to the AStar() function.
You can see another example of this in httplib:
# Useless stuff to help type info
if False :
conn._set_tunnel("example.com")

It will never get executed. It's one way to temporarily disable part of the code.

Theoretically, it could get executed:
True, False = False, True
if False: print 'foo'
But typically this will be used to temporarily disable a code path.

You are correct in assuming that this will never evaluate to true. This is sometimes done when the programmer has a lot of debugging code but does not want to remove the debugging code in a release, so they just put if False: above it all.

not enough reputation to comment yet apparently, but tim stone's answer is correct. suppose we have a function like this:
def blah(a,b):
return a+b
now in order to perform type inference, there has to be at least one call to blah, or it becomes impossible to know the types of the arguments at compile-time.
for a stand-alone program, this not a problem, since everything that has to be compiled for it to run is called indirectly from somewhere..
for an extension module, calls can come from the 'outside', so sometimes we have to add a 'fake' call to a function for type inference to become possible.. hence the 'if False'.
in the shedskin example set there are a few programs that are compiled as extension modules, in order to be combined with for example pygame or multiprocessing.