Could anyone please explain me how features become "Low"?

I can see that if issues are sorted by votes, on the top we can find 210:"Support mixed mode C/Python debugging" which has maximal vote count !19! and it's impact is low.

How is that?

If I get it right, this is most demanded feature (according to votes).

Does complexity of implementation plays any role in selecting Impact level?

Embedded debugging is barely possible without implementation of #210 or at least #639 ("Launch mode: embedded").

And since people vote for these so intensively, probably embedded python is not so rare case?

Anyway, tool is great and I love it :)

Honestly for features we don't pay much attention to the "impact" setting.  For bugs we'll pay a little more attention to it but we try and fix those quickly and keep them well organized so the impact (ha-ha) is lower there.

Our current feature selection process is probably best described as a combination of looking at the most voted features and looking at scenarios we're trying to enable for the current release.  And here and there we get to slip a random feature in because it's needed to enable something else we're doing.  Ultimately we're a small team so we are going to be choosy by necessity.

But just because we're not focusing on a feature doesn't mean it can't happen.  We'd love to see more people contribute features and we're perfectly willing to help those who are capable of doing so.  For example to implement mixed mode debugging "all" one needs to do now is clone our existing debugger (which implements all the requisite VS APIs) and replace it's guts to instead multiplex between the normal Python debugger and the normal native debugger.  Then there's a small bit of wiring to support launching with this new debug engine.  It's probably not difficult work given that all the major scaffolding can be cloned, but there's going to be a ton of little issues along the way.  Many of those are probably simply judgement calls of how things should behave to te end user but I'm sure there'll also be some technical issues as well. Either way we're here to help if anyone will attempt it. 

639's is probably even easier and it simply hasn't risen up on the priority list for us yet, but I can see it easily crossing the effort vs reward factor for us before mixed mode debugging. And when mixed mode debugging pops up on the stack for us we'd almost certainly do this one as well to complete the scenario. 

So in summary keep in mind we are a small team and we won't ever be able to do it all. And everyone on the team would love to see more contributors and to see the project grow.  Maybe that contribution is as small as keeping the bug impact rating correct, but we'd also love to see people contributing features as well :)    And thanks for the feedback and support!

I see, thanks for explanations!

Could you please at least provide a python code snippet that allows to attach automatically?

Idea is next: in my embedded python script I want to call something like "pytools.attach()" which makes Visual Studio to attach to this spot.

This is how I work with winpdb now. Here is code for winpdb:

def debug():
    import rpdb2
    if rpdb2.g_debugger: return
    import os
    import sys
    file = __file__.lower()
    file = file.rsplit(".", 1)[0] + ".py"
    os.spawnv(
        os.P_NOWAIT,
        '%s/python' % sys.prefix,
        ['python', '-c \"import winpdb;winpdb.main()\"', '-p123', '-a %s' % file]
    )
    rpdb2.start_embedded_debugger('123')

It runs winpdb and makes it to attach tho the very place of debug() call.

Something like this would make embedded debugging possible until #639, #210 are implemented.

Thanks!