Is it possible to make either jedi.el or anaconda-mode complete base class methods? For example, when subclassing html.parser.HTMLParser I expect it to complete the following code at point (1) (base class has methods like handle_data or handle_starttag):
import html.parser
class MyParser(html.parser.HTMLParser):
def handle_ # (1)
I've done some research on this issue and I've found that it is implemented in the latest version of jedi (0.10.0). Unfortunately, this version is in development state right now and is not available from pip. However, many editors use 0.10.0: Atom, VsCode, and even jedi-vim from the author of jedi.
It's easy to update jedi's version in anaconda-mode: https://github.com/nightuser/anaconda-mode. The actual change is just a one line. The Python part of anaconda-mode must be reinstalled -- simply delete anaconda-mode directory. The default location is ~/.emacs.d/anaconda-mode for Emacs and ~/.emacs.d/.cache/anaconda-mode for Spacemacs.
upd: It seems that 0.10.0 will be released soon: https://github.com/davidhalter/jedi/issues/740 .
upd2: It was released and know everything works out of the box. Just remove anaconda-mode directory and it'll automatically install latest version.
Related
Is it possible to programmatically check if a wheel (whl) is compatible with the chosen Python installation before attempting to install?
I'm making an automated packages installer (packages needed for my Python project to work), and I need to only attempt to install compatible pkgs, so if there are errors, I know they are only from the compatible modules and I should see what happened (not errors also from incompatible pkgs, which I wouldn't care). Example: I'd have wheels for Python 3.5 and 3.7, and in a 3.5 installation, 3.7 wheels could not be tried to be installed.
I've tried pkginfo (https://pypi.org/project/pkginfo/), but on wheel.supported_platforms, it returns an empty array and I can't do anything with that (a wheel with "any" or with "win32" on their name in the platform part, returned an empty array, so I can't use that, it seems).
Also tried the output from python -m pip debug --verbose, but the following appears:
WARNING: This command is only meant for debugging. Do not use this with automation for parsing and getting these details, since the output and options of this command may change without no
tice.
This makes the command not possible to use, even though bellow that it prints the "Compatible tags", which more or less I could use to determine if a wheel is supported or not from its name. Example of those "Compatible tags" in a Python array:
['cp39-cp39-win_amd64', 'cp39-abi3-win_amd64', 'cp39-none-win_amd64', 'cp38-abi3-win_amd64', 'cp37-abi3-win_amd64', 'cp36-abi3-win_amd64', 'cp35-abi3-win_amd64', 'cp34-abi3-win_amd64', 'cp
33-abi3-win_amd64', 'cp32-abi3-win_amd64', 'py39-none-win_amd64', 'py3-none-win_amd64', 'py38-none-win_amd64', 'py37-none-win_amd64', 'py36-none-win_amd64', 'py35-none-win_amd64', 'py34-no
ne-win_amd64', 'py33-none-win_amd64', 'py32-none-win_amd64', 'py31-none-win_amd64', 'py30-none-win_amd64', 'cp39-none-any', 'py39-none-any', 'py3-none-any', 'py38-none-any', 'py37-none-any
', 'py36-none-any', 'py35-none-any', 'py34-none-any', 'py33-none-any', 'py32-none-any', 'py31-none-any', 'py30-none-any']
With, for example, "pyHook-1.5.1-cp36-cp36m-win32.whl", I could check the name and see if it's compatible or not (except because of the warning above...).
Any other ideas?
Thanks in advance for any help!
EDIT: I could go manually and pull things from the name and hard-code the some possibilities I see on documentation, like "win32" and "win_amd64" (as I did before), but then I'd need to know exactly all the possibilities that the parts of the name can have (I saw a cool expression on the documentation: "e.g." - which means there are more than the mentioned things) and have a lot of work on that. I was hoping there was already someone that had made such thing (maybe even Python itself has some way in any of its internal packages).
You can do this using packaging.
pip install packaging
An example code to get the tags similar to how you got from pip would be:
from packaging.tags import sys_tags
tags = sys_tags()
print([str(tag) for tag in tags])
# ['cp39-cp39-manylinux_2_33_x86_64', 'cp39-cp39-manylinux_2_32_x86_64', 'cp39-cp39-manylinux_2_31_x86_64', ..... , 'py31-none-any', 'py30-none-any']
Of course, you can do much more things programmatically with the above variable tags:
>>> tags = sys_tags()
>>> for tag in list(tags)[:3]:
... print(tag.interpreter, tag.abi, tag.platform)
...
cp39 cp39 manylinux_2_33_x86_64
cp39 cp39 manylinux_2_32_x86_64
cp39 cp39 manylinux_2_31_x86_64
For more in-depth documentation, check: https://packaging.pypa.io/en/latest/tags.html#packaging.tags.sys_tags
I am migrating a piece of software from Python 2.7 to Python 3.
One problem that arises is:
The sklearn.neighbors.kde module is deprecated in version 0.22 and
will be removed in version 0.24. The corresponding classes / functions
should instead be imported from sklearn.neighbors. Anything that
cannot be imported from sklearn.neighbors is now part of the private
API.
I am not sure which line causes this, and not sure if it is an error or a warning, and what are the implications.
On python 2.7 everything works fine.
How do I get rid of this?
It will work until you update your scikit/sklearn version. Then the Kernel Density package will not run any more. You still have time to search for similar modules if you want to update your version.
But you can also set up different environments with different versions. Thus, if you need this module just start an environment and don't upgrade your sklearn version in this environment.
It's just a warning, for now -- until you upgrade sklearn to version 0.24. Then your code will need to be modified before it works. It's giving you a heads-up about this, so you can fix your code ahead of time. The modifications described below should work with your current version; you don't need to wait to upgrade before changing your code (at least, that's how these deprecation warnings usually work).
The corresponding classes / functions should instead be imported from sklearn.neighbors.
If I read this message correctly, it's saying that if you're using a function like sklearn.neighbours.kde.some_function() in your code now, you need to change it to sklearn.neighbours.some_function().
Anything that cannot be imported from sklearn.neighbors is now part of the private API.
This seems to be saying that there may be some functions that will no longer be available to you, even using the modification above.
One thing I can't get over - when I use numpy in Visual Studio and I want to declare an array of zeroes, I write:
x = numpy.zeros(n)
and it is correct for the interpreter. BUT THE AUTOCOMPLETION GIVES ME:
X = numpy.zeros_like ...
How can I change it to get actually helpful autocompletion? In C++ I get everything allright, so I guess it's an internal problem in Python case.
Edit: As I see the problem is that numpy.zeros is defined in numeric.py as:
zeros = multiarray.zeros. Apparently this is not enough for IntelliSense (or VisualAssist for this matter), which requires def function to actually see the structure.
You need to install the python 3.5 and download the corresponding wheel for numpy. Then using the command: pip install xxxx(numpy wheel version that you download) to install it. For more the detail information about the installation staff, you can have a look at this.
Then open or create a python application project in VS and set the python 3.5 as the default environment, then I can found the intellisense for numpy.zeros also works fine in .py file like the following screenshot: (python 3.5)
If set the python 2.7 as the default environment, the intellisense just like your description as below:
pexpect has gone through big changes since the version provided by Ubuntu 15.04 (3.2). When installing newest version of pexpect using pip3, this minimal program that previously successfully gave terminal emulation over serial console does not work any more:
#!/usr/bin/python3
import serial
import pexpect.fdpexpect
ser = serial.Serial("/dev/ttyS0", baudrate=115200)
spawn = pexpect.fdpexpect.fdspawn(ser)
spawn.interact()
The newer API is missing interact() method in class pexpect.fdpexpect.fdspawn which used to be there.
Question: how is the newer version of pexpect (currently 4.2.1) supposed to be used to provide free manual interaction with file object (serial port in this case)?
Alternatively, question/work-around: I recognize I am using a bit heavy machinery for such a simple use case, any suggestions for other python libraries that can do the same as earlier version of pexpect could?
Code reading: Examples use pexpect.spawn(command_str) to get a spawn object which has interact() method; actually this pexpect.spawn() is the same as directly creating a pexpect.pty_spawn.spawn object which has this method. On the other hand, pexpect.fdpexpect.fdspawn() will construct a pexpect.fdpexpect.fdspawn class which is missing interact() method. Both of these spawn classes derive from pexpect.spawnbase.SpawnBase class. Based on my quick reading, this looks like regression that resulted from refactoring on the way to version 4.x.
Browsing the pexpect issues, found #351, #356, and the newly submitted #377. By my quick reading, it seems this is a regression that was brought by uncompleted refactoring along the way towards new major release version 4. There are three possible avenues:
Make sure to install older version:
$ pip3 install "pexpect<3"
(or make sure that the version installed by other system is 3.x).
Fix pexpect by yourself.
Use some other python library.
These avenues were all more or less hinted by github user #takluyver, apparently maintainer of pexpect in comment to issue #351:
#jquast any thoughts on what to do for this (and #356)? I feel bad that we've broken things people were doing with fdspawn, but I really don't want to make it inherit from the pty spawn class, and now that it works on Windows, I think it's important to preserve that too.
Maybe we should just say:
If you have legacy code that broke with Pexpect 4, downgrade to Pexpect 3.x (pip install pexpect<4)
If you're writing new code, use streamexpect instead of pexpect.
Using PyCharm 3.0.1 Community the code completion works fine, but when I e.g. compelete to a method to one of the parents classes, the inserted method name then gets marked as an unresolved reference. What am I missing?
Details:
I am new to PyCharm, and test it on a (unified installed) Plone 4.3.2. The interpreter from the Installation is selected automatically, and I add the zinstance/bin/zopepy script for buildout.
I then open Products.CMFPlone-4.3.2-py2.7.egg/Products/CMFPlone/SkinsTool.py and then type
x = SkinsTool
at the bottom of the file. The code completion offers me manage_changeProperties (and shows PropertyManager). I select this, so that the line now says
x = SkinsTool.manage_changeProperties
The manage_changeProperties part is marked though. Hovering over the marked 'manage_changeProperties' now shows
Unresolved attribute reference 'manage_changeProperties' for class 'SkinsTool'
Is this a bug or am I doing something wrong (e.g. with importing the project)?
Edit: Following vape's advice I also tried on an instance. Same problem:
Auto-complete works fine:
But then the reference is unresolved:
This test was also done with 3.0.1 Professional.
Edit 2: The strucuture is the one of a standard plone installation: structure.txt. I have opened the topmost plone.4.3.2 folder.
Cheers,
Joerg
This is likely because there was an error when pycharm generated the skeletons for the plone library. Unless this is a bug, the only way to solve your problem is to delete the .idea folder inside your project. After doing so, reopen the project from the command line using charm <your project dir>. In case you have not made a command line tool for pycharm yet, this is how you do it:
Ok, the bug is fixed:
https://youtrack.jetbrains.com/issue/PY-11401
The next release will hopefully contain the fix, until then I compiled my own version.
Two things to note:
Link (or copy) the folder 'help' from the official community release into the intellij-community/python directory.
comile it from that python directory using 'ant -Didea.build.number=140.1332' (I think the actual number doesn't matter)
The result is in intellij-community/out/pycharmCE/artifacts