Finding actual Python attributes
-
I'm a Java programmer trying to adapt to Python. Use Eclipse for both. In Java, in Eclipse, if you type a variable's name, and then the dot operator, you'll see a list of attributes, and you can generally depend on those being available at runtime. However, I have found that in Python, this is not necessarily the case.
The screenshot shows that newgrid has an attribute datatype.
However, when I run it, I get the error:
line 794, in ShowGrids
type = newgrid.datatype
AttributeError: 'numpy.ndarray' object has no attribute 'datatype'Anyone care to explain?
-
Do "datatype" and/or "dateStyle" appear elsewhere in the codebase and it's just suggesting those without the context of attributes?
I ask because, though I've little experience with numpy, "dateStyle" doesn't seem like something it would handle.
-
Typical python don't declares parmeters type, hence from a local context Intellisense has no idea what could be sensible.
Some editors will offer anything that is an attribute in any class, hoping the writer could narrow to something appropiate.; by example if I know the object is an numpy.ndarray and the context sugest an object type, I can bet on .dtype .
With type annotations in recent pythons, linting and Intellisense could do better (if it gains adoption, some people dislike annotations)
Another explanation to your brief sample can be: ShowGrids was expecting a type Z in newgrid, type Z in fact has an attr .datatype, but newgrind was mistakenly assigned a numpy.ndarray, which does not have that attr.
-
@jinpa said in Finding actual Python attributes:
Anyone care to explain?
The Eclipse plugin for Python guesses what the attributes are when it can't work them out. Compiled packages (such as numpy) are very much not well understood by it, so the IDE's guesses are unusually wild. It usually does a better job with classes and packages that it can see the source of.
With arguments, it guesses that anything you've already used in that function may be used again. This isn't very helpful, but is about all you can do in a language that lets almost anything be done to objects after the fact.
-
@jinpa I don't know if this might help you at all, and I don't even know if Python has a similar thing in Eclipse, but could you change the Content Assist sources?
I don't have Python set up on my installation of Eclipse, but here's what I have for Java under Window->Preferences->Java->Editor->Content Assist->Advanced:
If Python has a corresponding settings page, then you should be able to control what shows up in the auto-completion list.
-
@djls45 said in Finding actual Python attributes:
If Python has a corresponding settings page
It's not nearly as richly supplied.
The other pane beneath it just lets you specify which keyword-like things you want to have available for completion, and nothing for the other possible sources (such as your current imports).
-
@cabrito said in Finding actual Python attributes:
Some editors will offer anything that is an attribute in any class, hoping the writer could narrow to something appropiate.; by example if I know the object is an numpy.ndarray and the context sugest an object type, I can bet on .dtype .
But .dtype isn't even on the suggested list at all for newgrid. Did I misunderstand what you were saying?
-
@dkf said in Finding actual Python attributes:
@jinpa said in Finding actual Python attributes:
Anyone care to explain?
The Eclipse plugin for Python guesses what the attributes are when it can't work them out. Compiled packages (such as numpy) are very much not well understood by it, so the IDE's guesses are unusually wild. It usually does a better job with classes and packages that it can see the source of.
With arguments, it guesses that anything you've already used in that function may be used again. This isn't very helpful, but is about all you can do in a language that lets almost anything be done to objects after the fact.
I find that in general programmers tend to underestimate the importance of debuggability. I can't understand why Python is so popular if it breaks one of the most important advantages of an IDE. In school, I had to keep track of things with pencil and paper, but once I discovered IntelliSense/code completion I never went back. I'm at a loss as to how to figure out what's actually going on in a program without it.
-
@jinpa said in Finding actual Python attributes:
But .dtype isn't even on the suggested list at all for newgrid. Did I misunderstand what you were saying?
You type .d and then one of the following happens
- you type an 'a' before Eclipse shows the list
- you don't look at the list before typing the 'a'
In both cases .da doens't match .dtype , so does not show in suggestons.
Context in the 0P case is small
-
@cabrito said in Finding actual Python attributes:
@jinpa said in Finding actual Python attributes:
But .dtype isn't even on the suggested list at all for newgrid. Did I misunderstand what you were saying?
You type .d and then one of the following happens
- you type an 'a' before Eclipse shows the list
- you don't look at the list before typing the 'a'
In both cases .da doens't match .dtype , so does not show in suggestons.
Context in the 0P case is small
No, I mean, now I type newgrid.dt, and I get no further suggestions.
-
@jinpa said in Finding actual Python attributes:
@cabrito said in Finding actual Python attributes:
@jinpa said in Finding actual Python attributes:
But .dtype isn't even on the suggested list at all for newgrid. Did I misunderstand what you were saying?
You type .d and then one of the following happens
- you type an 'a' before Eclipse shows the list
- you don't look at the list before typing the 'a'
In both cases .da doens't match .dtype , so does not show in suggestons.
Context in the 0P case is small
No, I mean, now I type newgrid.dt, and I get no further suggestions.
And if you put .dtype and run what happens? (Trying to discern lf Eclipse is wrongly ruling out newgrind can be an ndarray)
-
@cabrito said in Finding actual Python attributes:
@jinpa said in Finding actual Python attributes:
@cabrito said in Finding actual Python attributes:
@jinpa said in Finding actual Python attributes:
But .dtype isn't even on the suggested list at all for newgrid. Did I misunderstand what you were saying?
You type .d and then one of the following happens
- you type an 'a' before Eclipse shows the list
- you don't look at the list before typing the 'a'
In both cases .da doens't match .dtype , so does not show in suggestons.
Context in the 0P case is small
No, I mean, now I type newgrid.dt, and I get no further suggestions.
And if you put .dtype and run what happens? (Trying to discern lf Eclipse is wrongly ruling out newgrind can be an ndarray)
Yes, that works, thanks.
-
@jinpa said in Finding actual Python attributes:
But .dtype isn't even on the suggested list at all for newgrid. Did I misunderstand what you were saying?
The problem is that numpy is deeply inscrutable to the ways that most Python programs do introspection. Because Python is a language that will merrily provide as many ways to achieve something as you can shake a stick at, and many of them are actively hostile to making reliable metatools (e.g., introspection for IDEs) and the language community doesn't see this as a major problem. There's type annotations in very new versions of the language, but there's also a metric tonne of old code out there and lots of fools who think that making stuff introspectable is a sign of a lack of flexibility on their part.
-
Good old PyCharm.
-
@pie_flavor It's probably special-cased for the common C-based frameworks.
Still won't make numpy actually easy to use though.
