RE: [Pydev-code] Next release

[Grig G. <gr...@gh...>]

Fabio,

Thanks for putting together this documentation, it really helps. 

I made some progress on the pyUnit integration, but I have some ways to
go before I can show the results neatly in their own view. Fabio
already checked in a preliminary version, which adds a "pyUnit Test..."
menu item on the popup menu which appears when you right-click on a .py
file. The corresponding action invokes a unittest runner which then
displays the results on stdout. In the next version, I'll have a tabbed
view, just as you have when you use jUnit.

Grig

--- Fabio Zadrozny <fa...@in...> wrote:

> Hi Aleks, 
> 
> Ok then, I'm going to do a clean up on code completion too... I'm
> giving
> some examples on how should refactor / code completion work below.
> 
> 
> Examples
> 
> --------------------------------------------------------------------
> 
> Refactor Examples (activates on right mouse click - there is usually
> a
> keyboard key that emulates that):
> 
> On:
> 
> class C:
>     def a(self):
>         a = 2
>         b = 3
>         c = a+b #this should be refactored.
>         return c
> c = C()
> 
> Marking 'a+b' and making an extract method refactor for a method
> called
> 'plusMet' should give you:
> 
> class C:
>     def a(self):
>         a = 2
>         b = 3
>         c = self.plusMet(a, b) #this should be refactored.
>         return c
> 
>     def plusMet(self, a, b):
>         return a+b
> c = C()
> 
> 
> 
> And with the same class, marking C (it must be the class definition)
> should
> give you:
> class G:
>     def a(self):
>         a = 2
>         b = 3
>         c = a+b #this should be refactored.
>         return c
> c = G()
> 
> Until now, extract method has given me no problems, but rename does
> not
> always work... It has to scan all the PYTHONPATH and does not always
> find
> all the references (and sometimes may have problems parsing some
> files
> too...)
> 
> Methods or variables can be renamed too.
> 
> And as a helper, a Refactor Results View has been contributed. After
> any
> refactoring it should show which files were changed, however, it only
> works
> correctly if it is opened (if you do a refactor and open it later it
> won't
> show the results - that's a bug).
> 
> 
> -----------------------------------------------------------------
> 
> Code completion examples:
> 
> Imports completion goes for the sys.path, that is, if you go in
> python and:
> import sys
> print sys.path - those are the locations searched to get the imports
> tips.
> Directories if they contain an __init__.py 
> Files: .py, .py, .pyo, .pyd, .dll
> 
> So, if you go: (| Marks Ctrl+Space)
> import |                    a list of the imports that can be gotten
> should
> appear.
> import comp|                completes imports that start with comp
> import compiler.|           completes with compiler sub-modules and
> classes
> import compiler.ast.|       completes with compiler.ast sub-modules
> and
> classes
> from compiler import |      completes with compiler sub-modules and
> classes
> from compiler import ast.|  completes with compiler.ast sub-modules
> and
> classes
> 
> Now for other completions:
> 
> If you have a file
> 
> from compiler import *
> 
> And just Ctrl+Space, it should appear all the globals, in this case
> all
> compiler submodules and classes.
> 
> If you had just 
> 
> Import compiler 
> 
> Ctrl+Space would bring you '__builtins__' and 'compiler' suggestions
> 
> 
> For class code completion:
> 
> Suppose you have:
> 
> import compiler 
> class C(compiler.visitor.ASTVisitor):
>     def __init__(self):
>         self.| would bring you all the code available from this
> class.
> 
> 
> compiler.| would bring all that is contained within the compiler
> module
> 
> 
> There is a catch in this completion: as I rely on our ModelUtils to
> know in
> which class I am, it only works correctly once it is parsed correctly
> (at
> least once) - if this doesn't happen, you're getting an error such as
> 'name
> self. Not defined', because as it can't determine it as a class in
> ModelUtils, it tries to complete as if it was a simple token - this
> could be
> worked with some kind of fast parser, just to determine in which
> class we
> are...
> 
> Well, I think that's most of it...
> 
> 
> []s
> 
> Fabio Zadrozny
> ------------------------------------------------------
> Software Developer
> ESSS - Engineering Simulation and Scientific Software
> www.esss.com.br
> 
> 
> -----Original Message-----
> From: pyd...@li...
> [mailto:pyd...@li...] On Behalf Of Aleks
> Totic
> Sent: terça-feira, 21 de setembro de 2004 23:38
> To: pyd...@li...
> Subject: Re: [Pydev-code] Next release
> 
> Hi Fabio,
> this is great news, way beyond what I was thinking about. I am 
> sure the pydev users will love it. About feature freeze, that was 
> just a suggestion, it seems as if everything you've done is ready 
> to ship. You've
> 
> My current plan is to compile what we have, clean up the debugger 
> bugs, and ship it, late tomorrow as 0.6. About documentation, 
> I'll do what I can. Can you give me some good examples of how 
> your features work? Maybe a python file with comments like "you 
> can refactor this, you can do code completion on these".
> 
> For imports code completion, what are you using as your path?
> 
> Aleks
> 
> Fabio Zadrozny wrote:
> > Hi All,
> > 
> > I've been working full time the last week in pydev (thanks to some
> support
> > from my company), so, I have been able to introduce the following
> features
> > in the plugin (yes Aleks, I saw you said freeze the features, but I
> was
> > REALLY, REALLY in need for that):
> > 
> > Python shell integration
> > 	- Using a python shell and communicating through sockets (for
> > refactoring, search and code completion).
> > 
> > Refactoring:
> > 	Completed:
> > 	- Bicycle repair man (BRM) integration (support for rename and
> > extract method). 
> > 	- Added a view to show which files were affected by the last
> 
=== message truncated ===