file object autocompletion and syntax highlighting

Jun 13 at 7:41 PM
Edited Jun 13 at 7:44 PM
Hey everyone,

I'm pretty new to PTVS and noticed two things:

f = open('foobar.txt')
f.

Why does the file object have no autocompletion?


My second question is, if it's possible to have more than the basic syntax highlighting, i.e. keyword arguments or "self". The two issues below are marked as resolved. Does that mean this will be adressed in a future release?

https://pytools.codeplex.com/workitem/852
https://pytools.codeplex.com/workitem/527
Coordinator
Jun 13 at 7:48 PM
In the first case, you don't necessarily have a file object. You may have one of a wide range of IO objects, and it's likely that our analysis has given up and is just returning object. We should really be specializing builtin functions like open so that they always return something sensible, even if it isn't as precise as it could be.

That feature has been added and will be in the next release. (You can't see the Planned Release because we have it hidden right now. I'll unhide it... there's nothing important being concealed AFAIK.)
Jun 13 at 8:04 PM
Yes, it would be pretty nice to change the way how PTVS is handling "open".
I'm having here a piece of code for reading certain binary files, which was written in 2.x and I'm trying to port it to 3.x, though this is pretty hard since I have almost no autocompletion or code analysis.
Another IDE I'm using is handling this pretty well, but I would like to stick with PTVS since the overall autocompletion is a lot better.

Thanks for the quick reply!
Jun 13 at 8:44 PM
Edited Jun 13 at 8:49 PM
Just got an idea. I've seen in one of your videos that you enforce a certaing type by using an assert with isinstance().
Would something similary be possible in my case?

Edit: Just tried it out. It actually works now! :)
Coordinator
Jun 13 at 9:12 PM
Yep, that will work fine.

The downside is that the assertion will be checked when you run your code, which may mean that you get failures when it would actually work (this is probably more likely while you're porting, since a number of types have changed name but still have the same interface). But it's handy to have the option to force a particular type like that.