Re: [Python-mode] python setup ?
Andreas Röhler andreas.roeh...@easy-emacs.de 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 Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python setup ?
Am 27.01.2012 04:12, schrieb François Pinard: Andreas Röhlerandreas.roeh...@easy-emacs.de 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 Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python setup ?
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 Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python setup ?
Barry Warsaw ba...@python.org 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 Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python setup ?
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 PGP.sig Description: This is a digitally signed message part ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python setup ?
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 Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python setup ?
Richard Riley wrote: Barry Warsaw ba...@python.org 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 Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python setup ?
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 Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
Re: [Python-mode] python setup ?
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 PGP.sig Description: This is a digitally signed message part ___ Python-mode mailing list Python-mode@python.org http://mail.python.org/mailman/listinfo/python-mode
