I have used xcode to create several python scripts. It appears in the editor fine, however, when I attempt to look at the code through the terminal, I'm seeing that new lines are being encoded as "^M". This is problematic, since I am collaborating through github, and the diff features do not work when this is being done.
E.g.:
Source:
#############
#
# test.py
#
# by Author
#
#############
if __name__ == "__main__":
print "This is a test"
When I save this through another editor (PyCharmer) and more it via the console, I get the output as expected. When I create a new file via xcode, past the same text, and save, I get the following:
#############^M#^M# test.py^M#^M# by Author^M#^M#############^Mif __name__ == "__main__":^M print "This is a test"
Out of curiosity, I tried creating a test .cc file, and the same formatting issue did not arise, so if you want bonus points, explaining the inconsistency would be interesting as well.
In the latest Xcode 6, if I create a new external-build-system project, set the build tool to /usr/bin/python or /usr/local/bin/python3, create a new file named test.py in that project, Xcode recognizes its type (which you can see in the File Inspector panel of the assistant editor) as "Default — Python script", and its text settings (which you can also see in the File Inspector) as:
Text Encoding: Unicode (UTF-8)
Line Endings: Default — OS X / Unix (LF)
Indent Using: Spaces
Widths: Tab: 4 Indent: 4
Wrap lines: checked
And I get Python syntax coloring, tab completions, etc.
If that's not right—in particular, if you see Line Endings as "Classic Mac OS (CR)"—you can change it for the current file right there in the panel.
That fixes the current file. It may not fix the next file you create, but try it and see.
If not: In Xcode 4 and 5, you could easily change the default settings for each language, but that no longer seems to be exposed in Xcode 6. However, you may want to try going to the "Text Editing" pane of the "Preferences" dialog, and making sure "Default line endings" is set to "OS X / Unix (LF)", and maybe that "Convert existing files on save" is checked. This will help if you've got your default settings to Classic Mac, but C/ObjC/C++ overriding that with Unix. If, on the other hand, you somehow have a leftover override for Python from an earlier version of Xcode, I'm not sure how you can undo it short of wiping all of your Xcode settings and starting clean.
From a quick search, this answer has a very detailed version of some of the steps involved in configuring Python projects to handle things like the Run and Debug commands and so on, which may also be tangentially helpful.
Related
I am using emacs on Ubuntu 16.04 and added the configuration for flycheck-mode to include the python3 setup below:
Emacs: How do I set flycheck to Python 3?
Answer: https://stackoverflow.com/a/55000284/719016
(custom-set-variables
'(flycheck-python-flake8-executable "python3")
'(flycheck-python-pycompile-executable "python3")
'(flycheck-python-pylint-executable "python3"))
But my python3 buffer still gives me an invalid syntax [E0001] error in a line like below:
print("# My message for the stderr", file=stderr)
The syntax checkers loaded are python-pylint and python-pycompile (for some reason python-flake8 does not seem to be found.
Any ideas why?
Well, if you took the answer that you quoted literally, your configuration isn't getting loaded. The answer suggests putting the config in ~/.emacs.c/custom.el. That's a typo. The correct path is ~/.emacs.d/custom.el. The more correct answer is to put the config in the file pointed to by custom-file. The most correct answer is to never edit the custom file by hand. Instead use the customize facility.
Run M-x customize-group flycheck.
Scroll to the bottom of the buffer and click on "Flycheck executables".
Find the python executables you want to change. (Always use python3 for Python3 stuff, even if you only have Python3 on your system. It'll save you headaches later.)
Scroll to the top of the buffer.
Click "Apply and Save".
Boom. Your settings are saved in the correct "custom.el" file.
Now, load up a Python3 file you want to use flycheck with. If it's not doing what you expect, check things with C-c ! v (aka flycheck-verify-setup.) Confirm individual checkers with C-c ! ? (aka flycheck-describe-checker.) Check the variables you think you're setting with C-h v. Cut-n-paste them from flycheck's website if you have to.
Don't worry about flake8's config file. It will properly cascade as you expect.
And, lastly, as #jenesaisquois suggests:
#!/usr/bin/env python3
import sys
print("# My message for the stderr", file=sys.stderr)
Scoured the net to find an answer on this doc:
Some versions of the Python interpreter support editing of the current
input line and history substitution, similar to facilities found in
the Korn shell and the GNU Bash shell. This is implemented using the
GNU Readline library, which supports various styles of editing. This
library has its own documentation which we won’t duplicate here.
Read about Unix but what is this operation called editing of the
current input line? (Examples, Resources for Python or a simple
example wourd be great)
History Substitution... what is that maybe a simple example? Documentation touches on the issue as a know field and doesn't provide any insight on it.
Also cannot crack the line:
Completion of variable and module names is automatically enabled at
interpreter startup so that the Tab key invokes the completion
function; it looks at Python statement names, the current local
variables, and the available module names.
Can anybody provide a simple line explaining this line.
Editing the current input line is common practice.
For example if I use command prompt and do:
cd C:\Us
and hit Tab it will auto fill to:
cd C:\Users\
It just edited the current input line.
Similarly look up history does the same thing. If I do the following in command prompt:
> color b --> [Enter]
> # Now I have an empty command line
[Up Arrow]
> color b # Command prompt will fill the current line with what I just used.
Python can do the same thing by looking up variables and packages:
>>> import foobar
>>> fo [TAB] --> >>> foobar
Python auto filled fo to foobar because it knew I imported it by reading through my code.
It can do the same for variables (by reading the python code to find variables you defined).
>>> temp_var = 2
>>> te [TAB] --> >>> temp_var
If I testing my codes on IDLE the autocomplete its works but if I open a new file don't.
See there pictures below:
I just press CTRL + SPACE.
So.. don't work in this case:
I'll think there are some configuration for solve this, any one knows?
Python idle doesn't work that way. You get autocomplete in idle shell because values are deduced in every run. When you use files your program is not evaluated until you run. Because you can assign any type to a variable at run time, there is no way for idle to confirm the type of variable.
Understand with an example
>> a = dict()
>> a = set()
>> a. # <-- autocomplete knows type of a is set
but the same code in a file
a = dict()
a = set()
a. # <-- How does idle come to know what this variable is without running
but when you run this file once your global variables will show autocomplete feature, but not the local scope variables.
Have you tried saving the script as a *.py file before trying to use IDLE's autocomplete?
More than that, have you considered using a text editor with Python plugins, like Sublime Text and Atom? Or even a python-compatible IDE, like PyCharm, Spyder or even JupyterNotebook.
I'm trying to get pylint to give html output when I run Validate syntax on a python file in TextMate. I installed pycheckmate, pylint, and created a .pylintrc file in $HOME that sets the output format to html.
In TextMate's Advanced control panel, in the Shell Variables tab, I have TM_PYCHECKER set to /usr/local/share/python/pylint. If I trigger Validate Syntax, it runs pylint with all the default options, and gives me the output. If I change TM_PYCHECKER to /usr/local/share/python/pylint --rcfile "$HOME/.pylintrc" and Validate Syntax again, I get:
Please install PyChecker, PyFlakes or Pylint for more extensive code
checking.
If I run /usr/local/share/python/pylint from the commandline, without any arguments, the output is html, so I know in that case that it's reading the rcfile. What am I missing?
OK, I think I found the problem: pycheckmate sets --output-format=parseable' as a forced argument to pylint. I found this out by replacing /usr/local/share/python/pylint with a wrapper script that printed out its arguments:
#!/usr/bin/env python
import sys
from pylint import lint
print sys.argv[1:]
lint.Run(sys.argv[1:])
And when I ran it in TextMate I saw this:
['--output-format=parseable', '/Users/smithm5/test.py']
test.py:26 [C] Line too long (90/80)
…
So I dug into /Applications/TextMate.app/Contents/SharedSupport/Bundles/Python.tmbundle/Support/bin/pycheckmate.py itself. Sure enough, it adds that argument, as well as a whole lot of hard-coded html. So to fix it, I removed all the escape() wrappers, set opts = () on line 287 so I could set my own darn opts, and changed line 332 to print line.
A somewhat educated guess: try replacing $HOME by the absolute path to your home directory. Shell variables like $HOME are probably not available to use in TextMate's control panel.
UPDATE: Looking at the pycheckmate.py script included with the Python.tmbundle included with the version of TextMate I have, it appears that it is not possible to include arguments , like --rcfile /path/to/rcfile. The value of TM_PYCHECKER is expected to only be the path to the checker binary with no arguments. But, if you make your own copy of the Python.tmbundle, you should be able to edit pycheckmate.py to do as you wish.
I'm trying to get the list of meta-data associated to a file, using python in Ubuntu.
Without using python, the command "extract" works very well but I don't know how to use it with python, I always get a message saying that "extract" is not defined.
I assume you're asking about the metadata that appears in the Windows "Properties" dialogue under the "Summary" tab. (If not, just disregard this.) Here's how I managed it.
Download and install Python win32 extensions. This will put win32, win32com, etc. into your Python[ver]/Lib/site-packages folder. These bring the win32api, win32com, etc. For some reason, I couldn't get the version for Python 2.6 (in build 216) to work. I updated my system to Python 2.7 and used the 216 build for Python 2.7, and it worked. (To download & install, follow the link above, click the link reading 'pywin32', click the link for the latest build (currently 216), click the link for the .exe file that matches your system and Python installation (for me, it was pywin32-216.win32-py2.7.exe). Run the .exe file.)
Copy and paste the code from the "Get document summary information" page on Tim Golden's tutorial into a .py file on your own computer.
Tweak the code. You don't really have to tweak the code, but if you run this Tim's script as your main module, and if you don't supply a pathname as your first sys.argv, then you'll get an error. To make the tweak, scroll down to the bottom of the code, and omit the final block, which starts with if __name__ == '__main__':.
Save your file as something like property_reader.py, and call its property_sets(filepath) method. This method returns a generator object. You can iterate through the generator to see all the properties and their values. You could implement it like this:
# Assuming 'property_reader.py' is the name of the module/file in which you saved Tim Golden's code...
import property_reader
propgenerator = property_reader.property_sets('[your file path]')
for name, properties in propgenerator:
print name
for k, v in properties.items ():
print " ", k, "=>", v
The output of the above code will be something like the following:
DocSummaryInformation
PIDDSI_CATEGORY => qux
SummaryInformation
PIDSI_TITLE => foo
PIDSI_COMMENTS => flam
PIDSI_AUTHOR => baz
PIDSI_KEYWORDS => flim
PIDSI_SUBJECT => bar
extract is based on the libextractor library. You can access the library from Python by installing the python-extractor package on Ubuntu.
In case you're using Windows your question has been addressed on SO already.