We Keep Coding

readline() returns nothing when run from certain file

I've been working on a project lately which requires me to get a value stored in a text file. Simple task, right?
I have tried pretty much every stupid solution that uses readline() at some point, but when it's printed, there's nothing. Debug also tells me that it is empty.
Since I've experienced some inconsistencies with python already, I tried using the same function inside a different python file, and running it does exactly what it's supposed to do.
My current solution (not the best, but currently I just want it to run properly) is
count_file = "count.txt"
filehandle = open(count_file, 'r')
line = filehandle.readline()
print(line)
which works fine when used in a file called "test.py". When used in my "main.py", it returns nothing. And yes, I used it on the same context and temporarily deleted everything else from the main file while testing.
Does anyone have a clue what causes this? I could just paste the other stuff into the test file and rename it, but 1. that's annoying and 2. it'd be useful to know how to avoid this.
EDIT: I am not certain yet, but I think that the problem is caused by my IDE (am using the latest version of Pycharm Professional). I solved the problem by deleting and re-adding the Run/Debug Configuration.

Sometimes you will get return value as None if you do not specify the file path. please check the path/relative path of "count.txt" file with respect to "main.py" script.

First point: your file path is relative, so it will be resolved according to the current working directory, NOT depending on your script's location.
Second point: you read a single line, it can indeed be empty or only contains non-printable characters.
Third point: run your code without pycharm. Pycharm is probably fine when you really understand what it does behind your back, but if you don't you will indeed experiment some unexpected results. Just using the command line and a simple code editor is actually much simpler (though possibly not as productive) and less confusing.
And finally, don't forget you have an interactive Python shell. Quite handy for testing out things...

why Python string changes to italic looking in the Canopy editor when moved to new line?

This is probably an editor snag. But thought to check in case, as I do not know Python and just started to learn it.
Comparing the following
And I simply move the second field one line below by hitting return
The code in the second line became italic. I thought at first I have some syntax error or the editor is warning me about something, but there is no problem and the code run just as before. This only happens when the """ use. With a single " then the code does not become italic.
Do you think this is just an editor issue, or is the editor trying to tell something I should not be doing?
Specs:
Windows 7, Enthought Canopy 1.5.4 (64 bit)
code in plain text:
data = [r"""123""",r"""456"""]

Without being able to see the documentation for your editor, I would guess that the italics is there to signify that the line is wrapped and is not trying to warn you of anything.
As stated in PEP, "Continuation lines should align wrapped elements either vertically using Python's implicit line joining inside parentheses, brackets and braces, or using a hanging indent". wrapping lines like you're doing is completely ok and the editor shouldn't be warning you of anything.

Eclipse, using external tools to edit text directly

I'm new to eclipse. One thing I notice about eclipse+PyDev is that it give me warning if the indentation is not in multiple of 4 space. That is fine because I could use "reindent.py" to just reindent it. And I manage to setup it as the external tools. But the problem is, when I use it, (using Run->Externaltools->reindent) it would modify the code in the background, so after that, it would pop up saying that the source code has been modified (duh!) would you like to to reload the file? (duh again!) So, my question is, is there a way to pipe the current selection of the source code through reindent (it uses standard input/output when given no argument) and then replace the selection with reindent standard output automatically. Thanks!

Check in the preferences > general > workspace if you have 'refresh on access' and 'refresh with native hooks' both checked (that may solve your problem).
Another thing to check is in your external tool configuration: it has a 'refresh' tab, where you can choose to refresh the selected resource upon completion.
Another thing... if you have things just in a different indent (say 2 spaces), you can simply replace all 2 spaces by 4 spaces in the find instead of going through reindent...

When you run reindent.py as an external tool, you modify the whole file that contains the source code, not the current selection in your editor. But according to PEP 8 you should not mix tabs and spaces, so this might actually be what you want. In that case just click ok to reload the file and find that it worked.
In the settings you find some options under Window->Preferences->PyDev->Editor
There you can activate automatic replacement of a tabs with spaces when typing. Also you can choose that PyDev assumes tab-spacing for files that contain tabs.
You might want to read this:
How to integrate pep8.py in Eclipse?
When you activate Window->Preferences->PyDeV->Editor->Code Analysis->pep8.py you can generate a warning for every line, that conflicts with the convention.

How do you avoid leaving debugger print/pdb statements in python open source apps when you're debugging them and just finish?

Sometimes when developing using open source software, you need to read it's source code (specially zope/plone). A lot of times I need to write print statements, or debug calls (import pdb), or comment try/except clauses, you name it.
Sometimes I have a lot of files opened when trying to find an issue, and sometimes I forget to remove these print/debug alterations.
So, my question is: how do you keep yourself organized when doing it? Do you write "TODOs" along the modifications and search for them later, do you keep everything opened in your editor and when you find what you were looking for you just revert the files (This approach isn't useful when you're searching for a really big problem that needs days, you need to turn off your computer and return the other day)? Or you just don't do nothing since print statements in development environment is nothing to worry about?
I'm using Vim. I'm just interested to know how other programmers treat this issue.

I used to run into that problem a lot. Now, as part of my check-in process, I run a find/grep script combo that looks for my debugging statements. The only caveat is that I must keep my added debugging statements consistent so grep can find them all.
something like this:
## pre-checkin_scan.bin
find . -name "*.py" -exec grep -H --file=/homes/js/bin/pre-checkin_scan_regexp_list.grep {} \;
## pre-checkin_scan_regexp_list.grep
## (The first pattern is to ignore Doxygen comments)
^##[^#]
pdb
^ *print *( *" *Dbg
^ *print *( *" *Debug
^ *debug

In case of my own projects, the source code is always in version control. Before committing, I always check the graphical diff so that I can see what has changed, what the commit message should be and whether I can split up into smaller commits. That way, I almost always recognize temporary garbage like print statements. If not, I usually notice it shortly afterwards and can do an uncommit if I haven't yet pushed (works for DVCS like git and bzr, not with subversion).
Concerning problems that take multiple days, it's just the same thing. I don't commit until the problem is solved and then look at the diff again.
A text editor that allows editing within the graphical diff view would be really helpful in these cases, but I'm mostly using Eclipse, which doesn't support that.

Well +1 for starting this discussion. Yes sometime this happen to me. I left those pdb and commit the code to the central code base, git. I use 'emacs'. So, Before commit the code I usually search for pdb in the file. But it is hectic checking each file.So, Before committing the code I usually check the diff very carefully. I am also finding the better way to resolve this issue.

I also develop Python with Vim. I have never had to substantially modify the source code for debugging. I do sometimes put debugging print statements, and I have the habit of putting "# XXX" after every one. Then when I want to remove them (before a commit), and just search for the XXX and delete those lines.
For exceptions, I have arranged to run my code in the Vim buffer with an external interpreter that is set up to automatically enter the debugger on any uncaught exception. Then I'm placed automatically in the code at the point the exception occured. I use a modified debugger that can also signal Vim (actually GTK Gvim) to open that source at that line.
Caught exceptions should report meaningful errors, anyway. It is considered by many to be bad practice to do things like:
try:
... some code
except:
handle everything
Since you probably aren't actually handling every possible error case. By not doing that you also enable the automatic debugging.

I can give you three suggestions:
Do not remove debugger statements. By this, I mean leave them in, but make them conditional on being in debug mode:
# Set this to True to enable Debug code
XYZ_Debug = False
if XYZ_Debug:
do_debugging()
Oh, and if the debugging code is just to print things out, you should get familiar with logging (PyMOTW). If you are using logging, you could:
import logging
# Set this to True to enable debug
XYZ_Debug = False
log = logging.getLogger("XYZ")
log.setLevel(logging.DEBUG if XYZ_Debug else logging.INFO)
log.debug("debug output")
Put the same unique tag (in a comment) after each line, or near each block:
do_debug_code() # XYZZY
I then use Emacs' Ibuffer feature, mark all Python buffers then search for occurrences of this tag. Using some combination of find/grep/sed as in other answers would work as well.
If you are using Mercurial and know Mercurial Queues (or might want to learn them), maintain the debug code as a patch in your queue. When you are ready for "production"; or push of the current changes; pop the patch containing the debug code and go. You could achieve something like this outside of version control with diff and patch.

Vim Python omni-completion failing to work on system modules

I'm noticing that even for system modules, code completion doesn't work too well.
For example, if I have a simple file that does:
import re
p = re.compile(pattern)
m = p.search(line)
If I type p., I don't get completion for methods I'd expect to see (I don't see search() for example, but I do see others, such as func_closure(), func_code()).
If I type m., I don't get any completion what so ever (I'd expect .groups(), in this case).
This doesn't seem to affect all modules.. Has any one seen this behaviour and knows how to correct it?
I'm running Vim 7.2 on WinXP, with the latest pythoncomplete.vim from vim.org (0.9), running python 2.6.2.

Completion for this kind of things is tricky, because it would need to execute the actual code to work.
For example p.search() could return None or a MatchObject, depending on the data that is passed to it.
This is why omni-completion does not work here, and probably never will. It works for things that can be statically determined, for example a module's contents.

I never got the builtin omnicomplete to work for any languages. I had the most success with pysmell (which seems to have been updated slightly more recently on github than in the official repo). I still didn't find it to be reliable enough to use consistently but I can't remember exactly why.
I've resorted to building an extensive set of snipMate snippets for my primary libraries and using the default tab completion to supplement.