Pylint Wrong or no encoding specified - python-3.x

I'm maintinaing a library of python code. All bar one of the modules in the library runs through pylint with no problems.
For this one module pylint returns error F0010.
<some_module>.py:1: [F0010(parse-error), ] error while code parsing: Wrong or no encoding specified for <some_module>.py
I've stared at the code for hours and I can't see quite what's so special about it. There is nothing that jumps out at me as being different in any substantial way to the other modules in the library. File names, headers, footers are all very similar, PEP8 etc etc.
Does anyone have any hints for debugging this error?
If nothing else I'd like to have a pylint score for it so I can justify its existence in its current form, and I really don't want to rewrite it from scratch to appease pylint.

Turns out I've managed to fix the problem.
Whoever edited it last saved it as ANSI rather than UTF-8.
Thanks for the pointers, as its not somethign I would have thought of checking. I found this out when I was looking to see what it was actually encoded as, in response to the comments above. I'd have assumed it was UTF-8 as all the other files in the library are UTF-8, in fact everything here is utf-8, apart from this one file...
Now to up its pylint score a bit.

Related

How to debug when vim writes random files

I have a weird hard-to-localize issue with vim. It's almost certainly a weird custom configuration that is my fault, but I don't know (1) what I should be looking for and (2) how to reproduce it. I don't know if anyone will be able to help, but its been plaguing me for years, so I thought I'd at least make a post about it.
The issue is that after using vim, I occasionally find weird files in the directories I was working. The file names were usually characters I was typing. I have absolutely no idea what is triggering this, and it doesn't happen that often, so its hard to simply comment out a piece of my vimrc check if it occurs and narrow it down that way.
Examples of the file names I get are:
= np.diff(bins)
ep='')
= {
(shape0, device=device"
_rect = cv2.undistortPoints(left_corners, cameraMatrix, distCoeffs)
elf.alt_fc = nh.layers.MultiLayerPerceptronNd(
=feat_dim, noli=swish,
hape0 = (
ys, ubelt
tates, evidence=evidence)
ample_input = torch_encoder_result
tack = kwimage.stack_images(imgs, axis=1, resize='smaller')
hear_range=(-10, 10)
There is nothing in common between the files names that I can see. The majority have an "=" and a paren, but not all. I really have no idea how to reproduce this error. I feel like I must have a habit of hitting an incorrect key stroke that causes this issue, or there is some plugin doing something weird, or I have a crazy configuration (which I do).
The contents of the files varies. Sometimes they look like git differences. The one from the first example was the page for "less --help" (yes I grepped for that). Another is what looks like a docstring for a python class (I'm not 100% sure if this only happens with Python files, because most of my vim usage is Python).
Any tips that anyone has for how to further debug this would be appreciated.
Just for reference this is my vimrc: https://github.com/Erotemic/local/blob/master/vim/portable_vimrc and it does reference and source several other files in that repo, so I don't expect anybody to be able to parse it and figure it out.
If I was to take a guess I'd say its probably an auto-commands that's doing it, and I do have all of those auto-commands defined in this file: https://github.com/Erotemic/local/blob/master/vim/rc_settings/autocommand_settings.vim but I don't see anything that would cause this issue.

AutoPEP8, Anaconda, Sublime Text 3 Inconsistent Error Reporting

Please reference the attached screenshot.
I am working on a scrapy pipeline. I am using Sublime Text 3 with Anaconda/AutoPep8. I just moved over from ST2 where I did not have AutoPep8 or Anaconda.
The huge white dot is telling me that this line has invalid syntax. I could not figure out what the problem was, so I copied the line and pasted it here on line 1 of what was then an empty file. The syntax error still showed, suggesting it was not a problem with a prior line missing a closing parenthesis.
Then I made up some similar code, lines 3, 6, & 9. As you can see, they all pass muster. (I don't care about the other little errors, they are not the issue).
Then I pasted in the entire method over onto this new document, and now, as you can see, even the suspect line (22) passes.
Then I copied and pasted the whole class, and again, as you can see, line 49, the code it was complaining about before now doesn't cause any issues at all.
I tried using the command palette - PEP8: Preview Changes, (see https://github.com/wistful/SublimeAutoPEP8) but nothing happened.
I also tried the right click menu Anaconda > Autoformat PEP8 Errors but the E501 errors (line too long) were ignored and nothing happened with the supposed syntax error in the if statement.
Note: When I first started using AutoPep8 to fix E501 errors last week, I noticed that about halfway through a script, it suddenly stopped reporting errors at all. Don't know if this is related.
I also get this error when ST3 starts: https://github.com/DamnWidget/anaconda/issues/514. However, the consensus seems to be that if Sublime works even after you click through this error, it is nothing to worry about. I just mention this to give you as much as I know so you can help.
I also tried turning len('advocate') into a string, but the syntax error remains.
What is going on here? Is there a bug in Anaconda, AutoPep8, ST3, or my code?
Ubuntu 16.04, Python 3.4, (but 'automatic' build in ST3) ST3 Build 3126 (I don't know how the Build number lines up with a version number) Anaconda, AutoPep8 version numbers unknown, but I got them less than two weeks ago.
Well, it took a lot of very patient Googling and a comparison test in VSCode, but I have the astoundingly simple answer: I should have put '==', not '=' ! Yes, dear friends, it is basic Python. = means assignment, == mean equality or comparison. My if is of the latter type, because you can't make an assignment in an if statement. Now VSCode didn't make this any clearer, I think they both use Pylint, but it at least let me know that this was probably a valid error, whether I understood it or not. (Unless of course I know more that the devs at Pylint...Yea, not likely).
Kudos to Jean Mark Gawron, (who must be related to the Klingon Emperor) for giving me the answer: http://gawron.sdsu.edu/python_for_ss/course_core/book_draft/programming_intro/boolean_results.html

Are XLSX files UTF-8 encoded by definition?

I'm trying to read in XLSX files with PHP. Using gneustaetter/XLSXReader to be exact. However, these XLSX-files are generated by different companies, using different software. So I wanted to check if they have the right encoding and always just found UTF-8.
Therefore my question as above:
Are XLSX files UTF-8 encoded by definition? Or are there exceptions that could break the import script I'm working on?
It'd be risky to presume it's always UTF-8. I'd just key your expectations to what the XML describes in the XML header. In my experience Windows-1252 encoded data shows up all the time when you least expect it. You might check the XLSX specification more closely to find out more.
Here's a Chromium bug relating to a Windows-1252 encoded XLSX file, so these seem to exist in the wild. Maybe they're produced by programs other than Microsoft Office. With things like LibreOffice becoming more popular, older versions that may not have had the most robust XLSX support might end up interacting with your code. You probably don't want to have a bug like this show up in your code.
Try and be as accommodating as possible unless you have a concrete reason for rejecting invalid encoding. JSON, by strict definition, is UTF-8. XLSX seems to be XML by definition, but the encoding is not as nailed down. UTF-8 simply seems to be the default convention.

LaTeX document errors where no errors exist

I am writing my thesis with LaTeX and since today very curious errors turn up. I wrote something and made a citication in the file references.bib, and then the errors turned up. Befor writing that few lines everything worked great. Thus, I deleted everything I've added. But the errors still turn up. One Error is: Extra }, or forgotten $. ...ckoverflow Permission SYSTEM_ALERT_WINDOW}. I think my citication (which I've deleted after the errors turned up) is still stored somewhere , because "ckoverflow Permission SYSTEM_ALERT_WINDOW" was a part of the title of the cite.
I hadn't found any error in any file.
The next weird thing is that a mate of mine can compile that files without any problems. He is using WinEdt. I am using TeXStudio, but I've tried it with WinEdt, too.
There is a screenshot of my errors:
Please help me, any suggestions are appreciated.
Best regards
Looks like you might need to escape your _ characters there, as they are normally used for subscript, but only in math mode; hence the "missing $ inserted".
(La)TeX error messages make me sad... :(

How to detemine the file type in Linux?

If someone sends me a document (.pdf,.doc,.xls, ppt, .ogg, mp3, png, etc) without the extension, how can I determine the file type? The /usr/bin/file command doesn't always guess right or it simply says that I have a Microsoft Office document. I would like to know exactly so I can add the extension to the file name.
You can come up with your own rules by adding them to /etc/magic
man file for more details. It is tricky to always get these correct however, I have had reasonable success.
Try mimetype(1).
For Perl, look at File::MimeInfo.
Some of the other posters thus far appear to neglect a few things.
File::MimeInfo uses the same MimeInfo database used by 'file' to identify files. So That's unlikely to do anything different.
File::Type is likely to be interesting though, as it relies only on itself, but this leads to a comically long script full of 'if' statements. But this is, by its very nature, unlikely to cover things 'file' already doesn't cover.
The best you can do with unknown filetypes is try cracking them open with a hex-editor, or running them through 'strings' and seeing if you recognise anything. If you manage how to Identify a file, you may wish to go for File::Type as your solution because as far as I can make out, its at least easy to extend.
You can use the Perl module: File::Type

Resources