ANN: peppy-0.7.0.3 with IDLE's python reindenting code
Rob McMullen
from IDLE -- tab anywhere on the line in python mode now indents the
line to the correct indentation. It works really well, as good as
XEmacs for all the tests I've thrown at it. That's the benefit from
borrowing someone else's already-debugged code! Took me a little
while to adapt it, but much much less that me trying to figure out the
indentation algorithm by reading elisp code. :)
It seems fast; I know that was one of Josiah's concerns about scanning
arbitrarily far backwards in the file in order to find the correct
indentation. Admittedly I don't exactly have low end hardware, but
still; if it's good enough for IDLE which is targeted at a mainstream
(i.e. not bleeding edge gamer hardware) computers, it should be OK for
me.
So, kudos to the IDLE developers for making PyParse.py a standalone
module without any interdependencies with the rest of IDLE's code.
The interface was pretty straightforward, so it wasn't too hard to
adapt.
www.flipturn.org/peppy/Status.html
Rob
phil jones
definitely kudos to IDLE people ...
as an aside I don't know if you're thinking of writing this up, but
I'd love to see a tutorial / how to / blogpost on what you had to
do to reuse the indentation / formatting code.
phil
Rob McMullen
> as an aside I don't know if you're thinking of writing this up, but
> I'd love to see a tutorial / how to / blogpost on what you had to
> do to reuse the indentation / formatting code.
That's a good idea. I'll do that on my website somewhere and post a
link back to the list when I get it written up.
Rob
Don Dwiggins
from svn, and tried "python peppy.py". The splash screen came up, then
partway into it I got the following:
> Traceback (most recent call last):
> File "peppy.py", line 10, in ?
> peppy.main.main()
> File "C:\Dwig\Sandbox\peppy\peppy\main.py", line 710, in main
> run()
> File "C:\Dwig\Sandbox\peppy\peppy\main.py", line 670, in run
> peppy = Peppy(redirect=False)
> File
> "C:\ProgramFiles\Python24\Lib\site-packages\wx-2.8-msw-ansi\wx\_core.py",
> line 7757, in __init__
> self._BootstrapApp()
> File
> "C:\ProgramFiles\Python24\Lib\site-packages\wx-2.8-msw-ansi\wx\_core.py",
> line 7354, in _BootstrapApp
> return _core_.PyApp__BootstrapApp(*args, **kwargs)
> File "C:\Dwig\Sandbox\peppy\peppy\main.py", line 190, in OnInit
> self.autoloadSetuptoolsPlugins()
> File "C:\Dwig\Sandbox\peppy\peppy\main.py", line 556, in
> autoloadSetuptoolsPlugins
> peppy.lib.setuptools_utils.load_plugins(entry_point)
> File "c:\Dwig\Sandbox\peppy\peppy\lib\setuptools_utils.py", line 39,
> in load_plugins
> for entrypoint in pkg_resources.iter_entry_points(entry_point):
> AttributeError: 'module' object has no attribute 'iter_entry_points'
I'm hoping this will ring a bell for you; if not, I'll dig in and try to
diagnose the problem.
Thanks
--
Don Dwiggins
Advanced Publishing Technology
Rob McMullen
On 11/1/07, Don Dwiggins <d...@dondwiggins.net> wrote:
> You've tempted me with the latest announcement. I checked out peppy
> from svn, and tried "python peppy.py". The splash screen came up, then
> partway into it I got the following:
> > AttributeError: 'module' object has no attribute 'iter_entry_points'
> I'm hoping this will ring a bell for you; if not, I'll dig in and try to
> diagnose the problem.
Oops. I must be using a method from setuptools that is newer than the
setuptools version that is installed on your machine. I wrapped that
it a try/except and checked the new version into svn. So if you do a
checkout, you should pick up that fix in r740.
Rob
Don Dwiggins
get the following:
> ERROR:root:Unable to execute the code in plugin:
> c:\Dwig\Sandbox\peppy\peppy\hsi\hsi_major_mode
>
> No module named numpy
I understand the second message; I don't have or need numpy for what I
do. I'll also ignore the first one, but thought you might want to see it.
Rob McMullen
> Rob, thanks for the quick feedback; peppy comes up fine, although I did
> get the following:
> > ERROR:root:Unable to execute the code in plugin:
> > c:\Dwig\Sandbox\peppy\peppy\hsi\hsi_major_mode
> >
> > No module named numpy
> I understand the second message; I don't have or need numpy for what I
> do. I'll also ignore the first one, but thought you might want to see it.
Thanks, I don't see that message much because I have numpy on all my
machines. And, as it turns out it's all connected: the hyperspectral
image viewing mode requires numpy, and the plugin loading code is
screaming out the error condition when the hsi_major_mode couldn't
find numpy.
But, it brings up a good point: perhaps I should make that into more
of an informational message instead of the big flashing neon sign
saying error. Because it really isn't that big of an error if an
extremely optional plugin like the hyperspectral image viewer doesn't
get loaded.
Rob
SPE Stani's Python Editor
I also run a while ago into that 'problem' of numpy. (I've emailed you
about it.) Would it not be better to load "numpy" only on demand even
if you have it installed? It increases unnecessarily boot time and
memory usage as someone might not use the image viewer every session.
Some IDE users are quite critical about it and they are right.
Stani
Rob McMullen
> Would it not be better to load "numpy" only on demand even
> if you have it installed?
Indeed it would be. The current plugin scheme hasn't been extended to
support on-demand plugins, so with my current setup I'd be forced to
have every function do an "import numpy" which is tedious as well as
not recommended.
Rob
Don Dwiggins
> Hi Rob,
> I also run a while ago into that 'problem' of numpy. (I've emailed you
> about it.) Would it not be better to load "numpy" only on demand even
> if you have it installed? It increases unnecessarily boot time and
> memory usage as someone might not use the image viewer every session.
> Some IDE users are quite critical about it and they are right.
>
and a way to control their loading: on startup, on first use, or never
(this could be useful to keep the plugin in the list for occasional use,
but avoid having it loaded inadvertently). Come to think of it, the
list should probably be a tree to show dependencies among plugins.
Rob McMullen
> and a way to control their loading: on startup, on first use, or never
> (this could be useful to keep the plugin in the list for occasional use,
> but avoid having it loaded inadvertently).
Good idea.
> Come to think of it, the
> list should probably be a tree to show dependencies among plugins.
You'd actually have to use a dependency graph, because a plugin could
depend on more than one plugin. (I suppose if you really wanted to
use a tree you could show the same plugin in multiple places in a
tree, but that might get confusing.) It might be easier just to have
a sortable list of plugins and show the dependencies in the
information panel.
Eclipse probably does something like this, since it's entirely plugin
based. I'll have to get more memory and try it out. :) Anyone have
any other examples of this sort of hierarchical dependency-based
plugin management?
Rob
Christopher Barker
> www.flipturn.org/peppy/Status.html
starting up Peppy seemed to import the gdal module too - I wonder what for?
I think you really do need to have a plug-in system where registering
the plugin is a separate step from importing the while thing -- If this
catches on, we can only hope there will be many, many, plugins in the
future.
By the way, all the default key bindings use ctrl+whatever on the Mac,
where they really should be cmd+whatever. I don't have time to poke into
it now, but we'll have to do something about that. I know wx provides
some auto-translation, but I don't know if you can use that, or if we'll
have to design a set of OS-X key bindings.
-Chris
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
Dusty Phillips
>
> SPE Stani's Python Editor wrote:
> > Hi Rob,
> > I also run a while ago into that 'problem' of numpy. (I've emailed you
> > about it.) Would it not be better to load "numpy" only on demand even
> > if you have it installed? It increases unnecessarily boot time and
> > memory usage as someone might not use the image viewer every session.
> > Some IDE users are quite critical about it and they are right.
> >
> This would be a good idea in general: give the user a list of plugins,
> and a way to control their loading: on startup, on first use, or never
> (this could be useful to keep the plugin in the list for occasional use,
> but avoid having it loaded inadvertently).
This is an area where it might be a good idea to borrow some design
ideas from JEdit. Since version 4.2 or 4.3, I can't remember which,
they've supported dynamic plugin loading. I think at the time, the
primary reason was to cut back on startup time -- less of an issue
with Python apps than Java ones, I've noticed. However, it does
everything you ask in an elegant (not counting the XML) way.
JEdit is well designed and well-documented, code-wise. I suggest
running doxygen on it to gain some insight into its design.
> Come to think of it, the
> list should probably be a tree to show dependencies among plugins.
This is true when it comes to recursively loading or unloading
plugins. However, I personally think dependencies should not be
tracked or managed. The reason for this is that it is entirely
possible that someone will write a plugin that provides the same
functionality as another plugin, but in a completely different way. A
plugin that depends on this functionality should not have to depend on
one or both of those other plugins. This simply extends the pythonic
philosophy of duck typing to a higher level of abstractions.
As a really bad example, you might have a plugin that parses the
structure of a java file and another plugin that parses the structure
of a python file. A third plugin might use this parse structure to
provide autocomplete or class navigation or similar functionality
without caring about which of the other two plugins (or maybe a
totally different generic plugin that parses all languages that hasn't
been written yet) is loaded.
Dusty
Rob McMullen
> starting up Peppy seemed to import the gdal module too - I wonder what for?
Hyperspectral imagery. Not a common major mode, I would have to
agree, but I use it all the time for my job.
> I think you really do need to have a plug-in system where registering
> the plugin is a separate step from importing the while thing
Here's a workaround I just found: lazy module importing.
http://peak.telecommunity.com/DevCenter/Importing
It's complicated because the major modes reside in plugins, and all
the logic to determine if a file is editable with a major mode reside
in the major mode code itself. So, the major modes are self-contained
code; i.e. there's no huge case statements in the main program --
everything related to the major mode is with the major mode plugin
code.
The upshot is that the code needs to be imported to check to see if a
file works with a major mode.
Perhaps there could be a two-stage importing -- one small plugin
that's always imported and contains the logic to determine if a file
is editable with the major mode, and the other larger plugin that
contains the bulk of the code.
> If this
> catches on, we can only hope there will be many, many, plugins in the
> future.
I need to write up some documentation to make that easier. But,
obviously the framework is still in flux. :)
> By the way, all the default key bindings use ctrl+whatever on the Mac,
> where they really should be cmd+whatever.
You're right, there are no default mac key bindings, and my Mac-fu is
weak. Rather than simply converting the windows bindings, I'd like to
create mac bindings that correspond to the Mac UI guidelines.
Rob
Don Dwiggins
The upshot is that the code needs to be imported to check to see if a file works with a major mode. Perhaps there could be a two-stage importing -- one small plugin that's always imported and contains the logic to determine if a file is editable with the major mode, and the other larger plugin that contains the bulk of the code.
- auto-mode-alist, which is a list of pairs of regular expressions and modes, and applies each regex to the file name until it gets a match;
- magic-mode-alist, which is a similar list, except the regex is applied to the beginning bytes of the file (a function can be used in place of the regex to do the matching);
- interpreter-mode-alist, which is used with files that begin "#!{interpreter file path}".
Rob McMullen
>> The upshot is that the code needs to be imported to check to see if a
>> file works with a major mode.
>
>
>
> auto-mode-alist, which is a list of pairs of regular expressions and modes,
> and applies each regex to the file name until it gets a match;
> magic-mode-alist, which is a similar list, except the regex is applied to
> the beginning bytes of the file (a function can be used in place of the
> regex to do the matching);
> interpreter-mode-alist, which is used with files that begin "#!{interpreter
> file path}". Pretty simple, really, but it works reasonably well, and it
> might spark some ideas.
I have something similar, implemented is classmethods in each major
mode. What I'm thinking is that I can move these matching heuristics
to the plugin code itself. Currently each plugin returns a list of
major mode classes it knows about, which implies that the major mode
has to be imported when the plugin is imported.
If I move the heuristics to the plugin code, it would allow on-demand
loading of the major mode, because the import of the major mode would
be inside some conditional. If it doesn't match, it wouldn't be
imported.
If you want to see the types of matches currently performed you can go to:
http://trac.flipturn.org/browser/trunk/peppy/major.py#L145
but basically I match in order of precidence:
url protocol
url regular expression
emacs mode specifier (i.e. -*- hexl-mode -*-)
bangpath
magic bytes
attempt to open using a library open function
where the matching stops once it has a unique match.
Rob
Christopher Barker
> You're right, there are no default mac key bindings, and my Mac-fu is
> weak. Rather than simply converting the windows bindings, I'd like to
> create mac bindings that correspond to the Mac UI guidelines.
I can start on this -- is there a file to edit (or a new one to create?)
Rob McMullen
> Rob McMullen wrote:
> > Rather than simply converting the windows bindings, I'd like to
> > create mac bindings that correspond to the Mac UI guidelines.
>
> I can start on this -- is there a file to edit (or a new one to create?)
That would be awesome. Let me write up some stuff and I'll send you
some more info.
Rob