Re: python setup ?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: python setup ?

Andreas Röhler
Xavier Maillard wrote:

> Hi,
>
>    Richard Riley wrote:
>
>    >> The python-mode used is 5.1.0.
>
>    I've changed python-mode a little bit.
>    Purpose was to make movements a little bit easier,
>    more predictible.
>
> Easier, how easier ? What is so difficult with the default
> bindings ? (serious questions).
>  

Hi Xavier,

well, what means "easier"?

Our personal notion about whats best or fittest not
always is acknowledged by others obviously. Tastes
differ. From that I mean its better not just to look
for the one-and-all solution, but to offer flavors of
modes, so people have the choice. Thats already done
with perl-mode and cperl-mode for example. Nonetheless,
the one-and-all idea seems deep-rooted not just in
religion.

With python-mode.el, people may have good reasons, to
use it as it is - and me to leave it as it is.  Thats
fine with bazaar and other DVCs, we can do that. My
branch doesn't hamper the origin and any further branch
will not. Its just freedom to try and see.

Branch orginated from some request, to close forms more
definitely, more specific. Whilst python looks easy and
indeed is, editing it poses some specific difficulties
resulting from special meaning of whitespace.

Python-mode solved this by offering some repeats: if
you are not at the right indentation, just try the next
one - outer or inner.

Thats OK, thats a possible approach. Here the request
came from a user, who must care to save keystrokes.

Thus I wrote commands precisely closing function or
class, resp. last block. Block conceived as the
smollest hierarchical unit - themselves if no hierarchy
exists.

Too I had some other things in mind: reduction of
complexity, generalisation. Something remains to be
done.

Some reporting facilities have been introduced and
shall be still.

Here new functions as `bzr log' displays it:

`py-next-statement' and `py-previous-statement' set cursor at first char
on line instead of beginning of line
 
py-forward-block, py-backward-block

  py-beginning-of-def-or-class
  py-class-at-point
  py-function-at-point
  py-beginning-of-function
  py-beginning-of-class
  py-end-of-function
  py-end-of-class
  py-end-of-def-or-class
  py-line-at-point
  py-block-at-point
  py-beginning-of-block
  py-end-of-block
 
  py-whats-at-point
 
  py-beginning-of-def-or-class (really "or")
 
  py-beginning-of-def-or-class-if-arg

########

So far

Andreas Röhler

--
http://bazaar.launchpad.net/~a-roehler/python-mode/python-mode.el/
https://code.launchpad.net/s-x-emacs-werkstatt/

>    BTW have a look at pydb from Rocky Bernstein, if not done already.
>
> What is it useful for ?
>
> Xavier
>  

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: python setup ?

Barry Warsaw
On Apr 30, 2009, at 3:25 AM, Andreas Röhler wrote:

> With python-mode.el, people may have good reasons, to
> use it as it is - and me to leave it as it is.  Thats
> fine with bazaar and other DVCs, we can do that. My
> branch doesn't hamper the origin and any further branch
> will not. Its just freedom to try and see.

This is true, and experimentation a good thing in the short term.  In  
the long term though, a proliferation of branches just confuses people  
because no one's sure which is the official branch.  Our lives are  
more difficult too because of the python-mode.el/python.el split.

So I encourage you to experiment and get user feedback.  Old-timers  
(and remember, python-mode.el's been in widespread use for 15 years)  
will be wedded to their muscle memory, but if you introduce a user-
visible change that people like, they can be made configurable with  
defaults providing the old behavior.  Then it will be possible to  
merge your changes back into the official branch.  If you modularize  
your changes, then the less controversial ones can get merged in sooner.

-Barry


_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode

PGP.sig (313 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: python setup ?

Richard Riley-4
Barry Warsaw <[hidden email]> writes:

> On Apr 30, 2009, at 3:25 AM, Andreas Röhler wrote:
>
>> With python-mode.el, people may have good reasons, to
>> use it as it is - and me to leave it as it is.  Thats
>> fine with bazaar and other DVCs, we can do that. My
>> branch doesn't hamper the origin and any further branch
>> will not. Its just freedom to try and see.
>
> This is true, and experimentation a good thing in the short term.  In  
> the long term though, a proliferation of branches just confuses people  
> because no one's sure which is the official branch.  Our lives are  
> more difficult too because of the python-mode.el/python.el split.
>
> So I encourage you to experiment and get user feedback.  Old-timers  
> (and remember, python-mode.el's been in widespread use for 15 years)  
> will be wedded to their muscle memory, but if you introduce a user-
> visible change that people like, they can be made configurable with  
> defaults providing the old behavior.  Then it will be possible to  
> merge your changes back into the official branch.  If you modularize  
> your changes, then the less controversial ones can get merged in sooner.
>
> -Barry
>
>


IMO any new "obviously useful" features should be enabled by
default. Old Timers should have no problem reverting to older
configurations via settings. A point which generates much contention I
know. As it is, Python set up is/was a minefield. I have a reasonable
set up here fwiw,

This includes pysmell completions for hippie expand and company-mode.

http://richardriley.net/projects/emacs/dotprogramming#sec-1.3


_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: python setup ?

Andreas Röhler
Richard Riley wrote:

> Barry Warsaw <[hidden email]> writes:
>
>  
>> On Apr 30, 2009, at 3:25 AM, Andreas Röhler wrote:
>>
>>    
>>> With python-mode.el, people may have good reasons, to
>>> use it as it is - and me to leave it as it is.  Thats
>>> fine with bazaar and other DVCs, we can do that. My
>>> branch doesn't hamper the origin and any further branch
>>> will not. Its just freedom to try and see.
>>>      
>> This is true, and experimentation a good thing in the short term.  In  
>> the long term though, a proliferation of branches just confuses people  
>> because no one's sure which is the official branch.  Our lives are  
>> more difficult too because of the python-mode.el/python.el split.
>>
>> So I encourage you to experiment and get user feedback.  Old-timers  
>> (and remember, python-mode.el's been in widespread use for 15 years)  
>> will be wedded to their muscle memory, but if you introduce a user-
>> visible change that people like, they can be made configurable with  
>> defaults providing the old behavior.  Then it will be possible to  
>> merge your changes back into the official branch.  If you modularize  
>> your changes, then the less controversial ones can get merged in sooner.
>>
>> -Barry
>>
>>
>>    
>
>
> IMO any new "obviously useful" features should be enabled by
> default. Old Timers should have no problem reverting to older
> configurations via settings. A point which generates much contention I
> know. As it is, Python set up is/was a minefield. I have a reasonable
> set up here fwiw,
>  

Yes, you have. Used it month ago, thanks BTW.
Beside the question is still, how the user may get everything needed
installed with one action.
Several possibilities exist: we could make a tarball emacs-python.

Too we should let the user decide, what features to use: ipython or not,
pdbtrack or pydb, which
completion, refactoring, which checks and tests etc.

> This includes pysmell completions for hippie expand and company-mode.
>
> http://richardriley.net/projects/emacs/dotprogramming#sec-1.3
>
>
>
>  

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: python setup ?

Barry Warsaw
On May 4, 2009, at 3:59 PM, Andreas Röhler wrote:

>> IMO any new "obviously useful" features should be enabled by
>> default. Old Timers should have no problem reverting to older
>> configurations via settings. A point which generates much  
>> contention I
>> know. As it is, Python set up is/was a minefield. I have a reasonable
>> set up here fwiw,
>>
>
> Yes, you have. Used it month ago, thanks BTW.
> Beside the question is still, how the user may get everything needed
> installed with one action.
> Several possibilities exist: we could make a tarball emacs-python.
If you have permission of the authors of the other packages, I have no  
problem distributing them in our branch, or making a tarball of them  
available from the Launchpad download page.  It's up to them though.  
I tend not to use those other packages and just grab python-mode.el  
from its bzr branch.

> Too we should let the user decide, what features to use: ipython or  
> not,
> pdbtrack or pydb, which
> completion, refactoring, which checks and tests etc.

Sure.  I would tend to be more conservative in the default settings,  
so as not to surprise people, but that's just me. :)

-Barryu


_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode

PGP.sig (313 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: python setup ?

Andreas Röhler
Barry Warsaw wrote:

> On May 4, 2009, at 3:59 PM, Andreas Röhler wrote:
>
>>> IMO any new "obviously useful" features should be enabled by
>>> default. Old Timers should have no problem reverting to older
>>> configurations via settings. A point which generates much contention I
>>> know. As it is, Python set up is/was a minefield. I have a reasonable
>>> set up here fwiw,
>>>
>>
>> Yes, you have. Used it month ago, thanks BTW.
>> Beside the question is still, how the user may get everything needed
>> installed with one action.
>> Several possibilities exist: we could make a tarball emacs-python.
>
> If you have permission of the authors of the other packages, I have no
> problem distributing them in our branch, or making a tarball of them
> available from the Launchpad download page.  It's up to them though.

Thanks a lot. I'll care for that.

It will be great, if emacs-python-folks may use this facility for
emacs-python-things
 independently from existing files, thus python-mode
understood in a broader sense, rather python-mode(s).


>   I tend not to use those other packages and just grab python-mode.el
> from its bzr branch.
>
>> Too we should let the user decide, what features to use: ipython or not,
>> pdbtrack or pydb, which
>> completion, refactoring, which checks and tests etc.
>
> Sure.  I would tend to be more conservative in the default settings,
> so as not to surprise people, but that's just me. :)
>

That's wise. With releases, users shouldn't be bothered with all the
developing stuff.
Also we could consider bundles for beginners as well as for
powered-through master-pythons. :)


Andreas

> -Barryu
>

_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: python setup ?

Andreas Röhler
In reply to this post by Andreas Röhler
Richard Riley wrote:
> hi Andreas,
>
> but can one list breakpoints in pydb? Cant see how.
>
> r.
>
>  

info breakpoints

http://bashdb.sourceforge.net/pydb/pydb/lib/subsubsection-info.html

Grüße

Andreas
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: python setup ?

François Pinard
In reply to this post by Andreas Röhler
Andreas Röhler <[hidden email]> writes:

> [...] we should let the user decide, what features to use: ipython or
> not, pdbtrack or pydb, which completion, refactoring, which checks and
> tests etc.

As a general principle, users should have full control.  However, if a
user did not explicitly activate or inhibit features, python-mode should
ideally check what's available and auto-configure itself while starting,
in the most advantageous way possible for the user.

Users should not have to explicitly turn on configuration switches to
raise below some minimal configuration.  The default python-mode
behaviour should be on the side of the user rather than minimalism.  If
some use happens to not like an available feature which python-mode
decide to be a desirable one, (s)he should turn it off explicitly.

Just an example, by default, python-mode should have an *opinion* about
the best way to auto-complete, and activate the *best* way possible,
given what's has been installed besides python-mode.  Of course, *best*
is extremely debatable.  Another example : I would consider that
hideshow or highlight-indentation are desirable.  Opinions may differ,
and we cannot at the same time please me, you and everybody.  Yet,
python-mode should at least have an opinion.

Not activating things, as a way to stay neutral and avoiding the
expression of any opinion, does not serve the average python-mode user,
who would prefer something as interesting as possible, by default,
without having anything to do on the configuration side.

François
_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode
Reply | Threaded
Open this post in threaded view
|

Re: python setup ?

Andreas Röhler-2
Am 27.01.2012 04:12, schrieb François Pinard:

> Andreas Röhler<[hidden email]>  writes:
>
>> [...] we should let the user decide, what features to use: ipython or
>> not, pdbtrack or pydb, which completion, refactoring, which checks and
>> tests etc.
>
> As a general principle, users should have full control.  However, if a
> user did not explicitly activate or inhibit features, python-mode should
> ideally check what's available and auto-configure itself while starting,
> in the most advantageous way possible for the user.
>
> Users should not have to explicitly turn on configuration switches to
> raise below some minimal configuration.  The default python-mode
> behaviour should be on the side of the user rather than minimalism.  If
> some use happens to not like an available feature which python-mode
> decide to be a desirable one, (s)he should turn it off explicitly.
>
> Just an example, by default, python-mode should have an *opinion* about
> the best way to auto-complete, and activate the *best* way possible,
> given what's has been installed besides python-mode.  Of course, *best*
> is extremely debatable.  Another example : I would consider that
> hideshow or highlight-indentation are desirable.  Opinions may differ,
> and we cannot at the same time please me, you and everybody.  Yet,
> python-mode should at least have an opinion.
>
> Not activating things, as a way to stay neutral and avoiding the
> expression of any opinion, does not serve the average python-mode user,
> who would prefer something as interesting as possible, by default,
> without having anything to do on the configuration side.
>
> François

Thanks!

IMO a quite perfect description of some principle to act.
Think it's good to keep that somewhere, being able to refer to also for
new users/developers studying python-mode

stored it here for the moment:

https://blueprints.launchpad.net/python-mode/+spec/features

title might be to change still





_______________________________________________
Python-mode mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/python-mode