Re: [Python-Dev] Any Emacs tips for core developers?
On Feb 4, 2008 9:12 AM, <[EMAIL PROTECTED]> wrote: > To say I "use" emacs would be an understatement. I *live* in emacs. http://www.xkcd.com/378/ -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any Emacs tips for core developers?
Brett Cannon schrieb:
> I noticed on the download page that http://www.python.org/emacs is
> listed as the place to get your modes for Python development (which
> seemed to lack any mention of Vim and the support in svn; a slight
> bias =). Is this true for core development as well?
>
> Basically if someone can tell me the best place to download stuff and
> a bullet point or three for core dev new developers who use Emacs will
> thank you.
As others have said, out of the box support (python.el) is already quite
good (I'm using a patched version of python-mode.el though) -- the C mode
is good too -- my Emacs has a built-in style (for c-set-style) named
"python" for editing old-style (tabbed) CPython code, a style for new-style
CPython code can be found at http://wiki.python.org/moin/NeedForSpeed/IRCLog
(look for "python-new").
Cscope has excellent Emacs support and is helpful for navigation through
the C source.
GUD (the Emacs debugger interface) works well with gdb and pdb.
For the documentation, the Docutils svn includes a rst-mode.el (at
http://svn.berlios.de/svnroot/repos/docutils/trunk/docutils/tools/editors/emacs/).
For those who like graphical file browsers (TextMate *cough*), there's
ECB which also parses Python file structure.
Nice snippets:
;; highlight XXX style code tags in source files
(font-lock-add-keywords 'python-mode
'(("\\<\\(FIXME\\|HACK\\|XXX\\|TODO\\)" 1 font-lock-warning-face prepend)))
;; good for defeating the whitespace-normalization commit hook
(set-variable 'show-trailing-whitespace 1)
;; Custom margin keys (useful for Python indentation)
(global-set-key [?\M-\C-+] 'increase-left-margin)
(global-set-key [?\M-\C--] 'decrease-left-margin)
Georg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any Emacs tips for core developers?
[EMAIL PROTECTED] wrote: [...] > Finally, for you Ubuntu developers, I'm also using the the pre-release > XFT GNU emacs, which is very pretty. So far, despite stern and dire > warnings, it has had no stability issues: > > http://www.emacswiki.org/cgi-bin/wiki/XftGnuEmacs > > Look for the "PPA" deb lines there, and you get a nicely prepackaged, > policy-compliant version of emacs with no need to build anything > yourself. > FYI, I have built xft gnu emacs, as well as xft xemacs for fedora F7/8. I can make the srpms available if anyone wants them. I use xemacs all day every day and never see any problem (except for some slight font droppings). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any Emacs tips for core developers?
On Feb 4, 2008, at 11:12 AM, [EMAIL PROTECTED] wrote: > Personally, I have been using GNU Emacs's new python mode since I > discovered it, and I've never encountered any of the bugs you just > described. (Perhaps you are describing bugs that arise from trying to > use it with XEmacs?) I'm not using XEmacs, but perhaps its Leopard-related. jared ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any Emacs tips for core developers?
I am not a core developer but I use emacs exclusively for development
so you may find this useful.
On Feb 3, 2008, at 6:53 PM, [EMAIL PROTECTED] wrote:
> I am also the guy more-or-less responsible for syncing python-mode
> with the
> version delivered as part of the XEmacs packages (last synced about
> a week
> ago). The GNU Emacs folks wrote their own Python mode from scratch
> a couple
> years ago. Both are mentioned here:
>
>http://www.emacswiki.org/cgi-bin/wiki/PythonMode
>
> I have no experience with the GNU Emacs code.
I recently upgraded to the emacs 22.1/python.el which I tried *really*
hard to use, but eventually ended up installing python-mode again.
There are a number of problems in the emacs lisp that I was able to
get around, but eventually the bugginess overcame my will:
*R, RE, and RET (i.e. the keystroke shift-r) were bound to commands in
the major mode (meaning you couldn't type an R without triggering
python-send-string). You can comment out this line in python.el to get
around this:
;;(define-key map "\C-c\C-s" 'python-send-string)
*echoing was occurring in the run-python shell. You can easily tell
comint to process echoes for single-line commands, but if your tabs
are converted to spaces you would need to do something like this to
get rid of it in general:
;(add-hook 'inferior-python-mode-hook
; (lambda ()
; (setq comint-process-echoes t)
; (set (make-variable-buffer-local 'indent-tabs-mode) nil)))
* The emacs.py never worked for me (I ended up completely disabling it)
* Opening a run-python shell when you already have one open does not
work as you would expect. This is fixable also, but this was also the
final straw for me.
Realizing these things is very painful. Therefore I definitely
recommend python-mode.el, which you can install by adding this to
your .emacs:
;; Use a real man's python-mode
(setq auto-mode-alist (cons '("\\.py$" . python-mode) auto-mode-alist))
(setq interpreter-mode-alist (cons '("python" . python-mode)
interpreter-mode-alist))
(autoload 'python-mode "python-mode" "Python editing mode." t)
(autoload 'py-shell "python-mode" "Python shell." t nil)
Assuming the .el files are on your load-path and the .py files are in
your site-packages.
jared
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any Emacs tips for core developers?
-On [20080203 23:44], Brett Cannon ([EMAIL PROTECTED]) wrote: >And if you use something other than Vim or TextMate you can make >suggestions as well. But it should be a fairly popular editor for me >to bother to toss a slide into the tutorial. I assume you implicitly mean that you already have material on vim and/or textmate? -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ We have met the enemy and they are ours... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any Emacs tips for core developers?
On 04/02/2008, Guido van Rossum <[EMAIL PROTECTED]> wrote: > On Feb 4, 2008 9:12 AM, <[EMAIL PROTECTED]> wrote: > > To say I "use" emacs would be an understatement. I *live* in emacs. > > http://www.xkcd.com/378/ BTW, it's often worth checking out the alt text on xkcd cartoons... Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any Emacs tips for core developers?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 4, 2008, at 1:57 PM, Georg Brandl wrote: > > GUD (the Emacs debugger interface) works well with gdb and pdb. Don't forget pdbtrack which is in python-mode.el (don't know about python.el). Ken Manheimer wrote this and it rocks. It basically tracks pdb prompts in a shell buffer so it makes it really easy to just add a break point, run your code from the command line, and get dual-window tracing from the shell. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR6d4gHEjvBPtnXfVAQJg9AP/eM+6Qhni7PuEDFlfwuuVPnT/Zhhy9kdJ D2rAgGaMg8mYiBV8IGtdpG+tajmeodQUn2UFZTnN+d4CH4Z5JOGFBo4jKGI731se K8cXtmr+TV2Yv838kOKyTJvKmo8zpCTSkYaBZ2swHbTMq3FEEm1Aa7mVZyjBqYTs V8QrDYCoGAE= =JIhC -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any Emacs tips for core developers?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 4, 2008, at 1:46 PM, Neal Becker wrote: > [EMAIL PROTECTED] wrote: > > [...] >> Finally, for you Ubuntu developers, I'm also using the the pre- >> release >> XFT GNU emacs, which is very pretty. So far, despite stern and dire >> warnings, it has had no stability issues: >> >>http://www.emacswiki.org/cgi-bin/wiki/XftGnuEmacs >> >> Look for the "PPA" deb lines there, and you get a nicely prepackaged, >> policy-compliant version of emacs with no need to build anything >> yourself. >> > > FYI, I have built xft gnu emacs, as well as xft xemacs for fedora > F7/8. I > can make the srpms available if anyone wants them. > > I use xemacs all day every day and never see any problem (except for > some > slight font droppings). Me too, on multiple platforms. Specifically, 21.5.28 (or .27) on OS X (Tiger & Leopard) and Linux (Ubuntu & Gentoo). 21.5.28 has one little buglet that I've already complained to Stephen about but other than that, it works beautifully. FWIW, Skip and I will probably keep maintaining python-mode.el and I intend to update its syntax highlighting for Python 3 at some point. But for the most part, it just works well enough for me. The reason there are two Python modes is the same reason there is FSF Emacs and XEmacs . - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR6d39XEjvBPtnXfVAQLIUQQAgLbE4vsagSZPOaM5mdlXhbb75ws3oA+M WZXip9ZA3uSuResiC4miSGQNQZiBAjH4oQA+JjVOls3scOD58jq59ZSXdTSiL3oL sP/hn1zZxGoC8MF1NranPlnIpWNB9Ga6i/To0WKUiME8uXOwfwGlnTfMILYhqnYE 1inLziB5gxc= =uTN4 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any Emacs tips for core developers?
On Feb 3, 2008 3:48 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote: > I believe recent versions of Emacs and Vim have Python support > standard. At least, it's been years since I last had to do anything to > install it. > Python support is standard for Vim. But the stuff in Misc/Vim is much more up-to-date and specific to core development. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any Emacs tips for core developers?
[EMAIL PROTECTED] writes: > Finally, on a related note, François Pinard sent me a message yesterday > which I have yet to respond to. He is apparently back in the Pymacs saddle. > I think a Pymacs-based Python mode would be very cool (in part because I am > really not an Emacs Lisp person). Full agreement here. I really regret that I didn't discover Pymacs earlier. It is fun to play with it and I did some sort of completion for Python in Emacs. I used Pymacs, python-mode.el, pycompletion.el, pycompletion.py and many different ideas found somewhere and finally got something imho pretty useful. Take a look here: http://www.rwdev.eu/articles/emacspyeng HTH, Rob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Initial attempt to PyCon sprint tutorial slides are up
The 1 MB PDF can be found at http://www.cs.ubc.ca/~drifty/pycon/sprint_tutorial.pdf . If you find any bad info or some info that is really lacking, let me know. But please realize that my slides are never really meant to be read on their own as it just goes against my presentation style. So don't think that some slide doesn't go into enough detail unless there is some URL I am missing. Every slide will be discussed more during the presentation than what is on the slide. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any Emacs tips for core developers?
To say I "use" emacs would be an understatement. I *live* in emacs. On 04:32 pm, [EMAIL PROTECTED] wrote: >I recently upgraded to the emacs 22.1/python.el which I tried *really* >hard to use, but eventually ended up installing python-mode again. >There are a number of problems in the emacs lisp that I was able to >get around, but eventually the bugginess overcame my will: >*R, RE, and RET (i.e. the keystroke shift-r) were bound to commands in >the major mode (meaning you couldn't type an R without triggering >python-send-string). You can comment out this line in python.el to get >around this: Personally, I have been using GNU Emacs's new python mode since I discovered it, and I've never encountered any of the bugs you just described. (Perhaps you are describing bugs that arise from trying to use it with XEmacs?) I have, however, found that it is *less* buggy in certain circumstances; it seems to indent parentheses correctly in more circumstances, and it isn't confused by triple-quoted strings. It also has functioning support for which-func-mode which python-mode.el doesn't seem to (a hack which displays the current scope on the modeline, which is very helpful for long classes: I can just glance down and see "FooBarBaz.bozBuz()" rather than needing to hit "C-M-r ^class" As always, YMMV. Also, I use twisted-dev.el for all of my Python development. I don't think I'll ever be able to go back to F9 doing anything but running tests for the current buffer. Apparently there's a "ctypes-dev" based on those hacks in the main Python repository which basically does the same thing. (I'd also strongly recommend binding F5 to 'next-error'. It makes hopping around in the error stack nice and easy.) Finally, for you Ubuntu developers, I'm also using the the pre-release XFT GNU emacs, which is very pretty. So far, despite stern and dire warnings, it has had no stability issues: http://www.emacswiki.org/cgi-bin/wiki/XftGnuEmacs Look for the "PPA" deb lines there, and you get a nicely prepackaged, policy-compliant version of emacs with no need to build anything yourself. (I've also got a personal collection of hacks that, if anyone likes TextMate-style "snippets", I'll email you. It does stuff like turning """ into """\n(indent)\n"""\n and "class " into "class (cursor here):\n"""\n(indent)\n"""\n(indent)\n". I haven't cleaned it up for a public release since a lot of people seem to think that automatically inserting text is pretty obnoxious and I just don't have the energy for that debate.) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any Emacs tips for core developers?
Barry> The reason there are two Python modes is the same reason there is Barry> FSF Emacs and XEmacs . I remember something about some GNU person submitting an enormous patch that would have made continued distribution of python-mode.el with Python untenable because it would have been GPL'd or some such. Which reminds me. I should sync Misc/python-mode.el for both trunk and py3k branches with the latest version from the SF python-mode project. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Backporting PEP 3115
Is anyone interested in seeing PEP 3115 (Metaclasses in Python 3000, ) backported to 2.6? Actually, I guess I am interested, so perhaps I should ask 'does anyone see any objection to it being backported'? Of course there should be full backward compatibility in 2.6, but I don't see any issue preventing that, right now. (I was actually working on backporting the new super() (incorrectly described in PEP 3135) which builds on top of PEP 3115; I can backport without PEP 3115 but it would be a waste if we then backported 3115 after all.) -- Thomas Wouters <[EMAIL PROTECTED]> Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any Emacs tips for core developers?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 4, 2008, at 5:34 PM, [EMAIL PROTECTED] wrote: > >Barry> The reason there are two Python modes is the same reason > there is >Barry> FSF Emacs and XEmacs . > > I remember something about some GNU person submitting an enormous > patch that > would have made continued distribution of python-mode.el with Python > untenable because it would have been GPL'd or some such. That rings a bell. > Which reminds me. > I should sync Misc/python-mode.el for both trunk and py3k branches > with the > latest version from the SF python-mode project. Yes, thanks! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR6ede3EjvBPtnXfVAQJAVwP+Nq9nVdTVKQpsnY+zIgnhUezMbWgiUDEm ggW5fHXmUP1zuoxHRn43PRKBtbHyX/57xBqlrGCJEW5nGbm/YV2cQgdX+B9F0q26 owH4vBXLjWs3kkPxvCrpLIB1ndjXDT3Ze04Oy7013p5z9whVEb5C+KSZpxkEa5c5 AjNIFkgAzqA= =nJJI -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any Emacs tips for core developers?
Brett> Python support is standard for Vim. But the stuff in Misc/Vim is Brett> much more up-to-date and specific to core development. Brett, I should have asked this before, but what's so special about core (Python?) development that the tools should be different than for non-core development? Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any Emacs tips for core developers?
On Feb 4, 2008 2:35 PM, <[EMAIL PROTECTED]> wrote: > > Brett> Python support is standard for Vim. But the stuff in Misc/Vim is > Brett> much more up-to-date and specific to core development. > > Brett, > > I should have asked this before, but what's so special about core (Python?) > development that the tools should be different than for non-core > development? Usually the core has keywords, built-ins, etc. that have not been pushed to the release versions for various editors. I know I like having my syntax highlighting work for what I am coding against, and against trunk that can be different than what my editor came with. Plus coding guidelines might be different from PEPs 7 and 8 compared to what an editor is set to do by default. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any Emacs tips for core developers?
On Feb 4, 2008 4:47 PM, <[EMAIL PROTECTED]> wrote: > > >> I should have asked this before, but what's so special about core > >> (Python?) development that the tools should be different than for > >> non-core development? > > Brett> Usually the core has keywords, built-ins, etc. that have not been > Brett> pushed to the release versions for various editors. > > Ah, okay. Barry mentioned something about adjusting the python-mode syntax > tables to include Python 3.x stuff, though patches are always > welcome. > > Brett> Plus coding guidelines might be different from PEPs 7 and 8 > Brett> compared to what an editor is set to do by default. > > That might be a bit more challenging. I was thinking today that it would be > kind of nice to have a set of predefined settings for Python's new C style > (someone mentioned producing that). Well, I have done that for Vim. Don't know if you Emacs folks have done that yet. =) -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any Emacs tips for core developers?
>> I should have asked this before, but what's so special about core >> (Python?) development that the tools should be different than for >> non-core development? Brett> Usually the core has keywords, built-ins, etc. that have not been Brett> pushed to the release versions for various editors. Ah, okay. Barry mentioned something about adjusting the python-mode syntax tables to include Python 3.x stuff, though patches are always welcome. Brett> Plus coding guidelines might be different from PEPs 7 and 8 Brett> compared to what an editor is set to do by default. That might be a bit more challenging. I was thinking today that it would be kind of nice to have a set of predefined settings for Python's new C style (someone mentioned producing that). Should that go in the C/C++ mode or be delivered somehow else? Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Initial attempt to PyCon sprint tutorial slides are up
Brett Cannon wrote: > The 1 MB PDF can be found at > http://www.cs.ubc.ca/~drifty/pycon/sprint_tutorial.pdf . If you find > any bad info or some info that is really lacking, let me know. But > please realize that my slides are never really meant to be read on > their own as it just goes against my presentation style. So don't > think that some slide doesn't go into enough detail unless there is > some URL I am missing. Every slide will be discussed more during the > presentation than what is on the slide. I've written down some notes while I was reading your slide. Some of the information may be covered by your speech but better safe than sorry. ;) * Windows builds: Configuration "Debug" or build -c Debug builds a Py_DEBUG build. All executables and extension modules are postfixed with _d (python_d.exe, python.exe is always the standard build). Platform X64 builds for AMD64, PGO is not available in the Express edition * Windows doesn't use automake but a hand crafted PC/pyconfig.h file. * IRC is missing from the communication list (#python and #python-dev on irc.freenode.net, #python-dev gets annotations of checkins and bug tracker activity from CIA bot) * Bug reports: Don't forget to fill in target version, component (extension = Modules/), type (feature request is RFE = request for enhancements). Priority and keywords get filled in by a developer. * Checking: Don't forget to add an entry to Misc/NEWS. Always add a note like "Closed in r12345" when you close a bug. The revision is important und must have the form r12345. Add the bug tracker number #1234 to the checkin message. * Block back ports from automatic forward merging with ".../py3k$ svnmerge.py block -r 12345" or write a note in your checkin message that the revision must not be merged. * Windows tests: Use "rt -d" to run unit tests for a debug build. The rt script accepts all options regrtest.py accepts + the option -q. The argument length on Windows is limited, consider the -f file option. * Building docs on Windows: Require command line svn tool. Use make.bat in the Docs/ directory. Requires HTML Help compiler to build chm files (optional). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Initial attempt to PyCon sprint tutorial slides are up
On Feb 4, 2008 5:26 PM, Christian Heimes <[EMAIL PROTECTED]> wrote: > > Brett Cannon wrote: > > The 1 MB PDF can be found at > > http://www.cs.ubc.ca/~drifty/pycon/sprint_tutorial.pdf . If you find > > any bad info or some info that is really lacking, let me know. But > > please realize that my slides are never really meant to be read on > > their own as it just goes against my presentation style. So don't > > think that some slide doesn't go into enough detail unless there is > > some URL I am missing. Every slide will be discussed more during the > > presentation than what is on the slide. > > I've written down some notes while I was reading your slide. Some of the > information may be covered by your speech but better safe than sorry. ;) > > * Windows builds: Configuration "Debug" or build -c Debug builds a > Py_DEBUG build. All executables and extension modules are postfixed with > _d (python_d.exe, python.exe is always the standard build). Platform X64 > builds for AMD64, PGO is not available in the Express edition > Added the debug info. > * Windows doesn't use automake but a hand crafted PC/pyconfig.h file. > > * IRC is missing from the communication list (#python and #python-dev on > irc.freenode.net, #python-dev gets annotations of checkins and bug > tracker activity from CIA bot) Added. > > * Bug reports: Don't forget to fill in target version, component > (extension = Modules/), type (feature request is RFE = request for > enhancements). Priority and keywords get filled in by a developer. > Added a note to fill in all the info. > * Checking: Don't forget to add an entry to Misc/NEWS. Covered on slide 42. > Always add a note > like "Closed in r12345" when you close a bug. The revision is important > und must have the form r12345. Add the bug tracker number #1234 to the > checkin message. > I am not worrying about checkins. Figure people who have it know what to do. And anyone who gets it will be personally instructed on the spot. But when it comes time to write the docs that go on the web I will write a committer doc. > * Block back ports from automatic forward merging with ".../py3k$ > svnmerge.py block -r 12345" or write a note in your checkin message that > the revision must not be merged. > See above. > * Windows tests: Use "rt -d" to run unit tests for a debug build. The rt > script accepts all options regrtest.py accepts + the option -q. The > argument length on Windows is limited, consider the -f file option. > Added -d to the two examples. > * Building docs on Windows: Require command line svn tool. Use make.bat > in the Docs/ directory. Requires HTML Help compiler to build chm files > (optional). Mentioned the svn need and make.bat. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any Emacs tips for core developers?
On Feb 4, 2008 7:47 PM, <[EMAIL PROTECTED]> wrote: > >>> I should have asked this before, but what's so special about core >>> (Python?) development that the tools should be different than for >>> non-core development? > >Brett> Usually the core has keywords, built-ins, etc. that have not been >Brett> pushed to the release versions for various editors. > > Ah, okay. Barry mentioned something about adjusting the python-mode syntax > tables to include Python 3.x stuff, though patches are always > welcome. > >Brett> Plus coding guidelines might be different from PEPs 7 and 8 >Brett> compared to what an editor is set to do by default. > > That might be a bit more challenging. I was thinking today that it would be > kind of nice to have a set of predefined settings for Python's new C style > (someone mentioned producing that). Should that go in the C/C++ mode or be > delivered somehow else? > It's fairly trivial to adjust cc-mode to conform PEP 7 C coding convention: (defmacro def-styled-c-mode (name style &rest body) "Define styled C modes." `(defun ,name () (interactive) (c-mode) (c-set-style ,style) ,@body)) (def-styled-c-mode python-c-mode "python" (setq indent-tabs-mode t tab-width 8 c-basic-offset 8)) (def-styled-c-mode py3k-c-mode "python" (setq indent-tabs-mode nil tab-width 4 c-basic-offset 4)) -- Alexandre ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any Emacs tips for core developers?
skip> I should sync Misc/python-mode.el for both trunk and py3k branches skip> with the latest version from the SF python-mode project. Done only on trunk. I trust one of the mega-merges to the py3k branch will copy it there and that backporting to 2.5 is not desired. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any Emacs tips for core developers?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 4, 2008, at 7:47 PM, [EMAIL PROTECTED] wrote: > >>> I should have asked this before, but what's so special about core >>> (Python?) development that the tools should be different than for >>> non-core development? > >Brett> Usually the core has keywords, built-ins, etc. that have > not been >Brett> pushed to the release versions for various editors. > > Ah, okay. Barry mentioned something about adjusting the python-mode > syntax > tables to include Python 3.x stuff, though patches are always > welcome. If left to me, it might not happen until I start writing a lot of Python 3 code :). >Brett> Plus coding guidelines might be different from PEPs 7 and 8 >Brett> compared to what an editor is set to do by default. > > That might be a bit more challenging. I was thinking today that it > would be > kind of nice to have a set of predefined settings for Python's new C > style > (someone mentioned producing that). Should that go in the C/C++ > mode or be > delivered somehow else? I think it might not be horrible if python-mode.el included a function that installed Python's new C style, which you could then select through your mode hook or whatever. It's been ages since I hacked on that stuff, but I wonder how far Python's new C style differs from the built-in styles. Maybe there's one that's already close enough? - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBR6fITXEjvBPtnXfVAQIlZwQApRs/VC2tV7auSRjK2AuWuFf7i/k5EPTf ZaBSgmHtb8jENTvOZju2XOnOVdhlgHO5Zec5ptvXKc3Y1Mzl9API2RjH0jP9G8mt mzI22bGScnCbA5bpzM7kh5cyg939+GzUmUF7BsRoAquIwKRdf5NHbJG+qcxKO0pK vcKIuf6eJxM= =Ltuj -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any Emacs tips for core developers?
Georg> ... a style for new-style CPython code can be found at Georg> http://wiki.python.org/moin/NeedForSpeed/IRCLog (look for Georg> "python-new"). I whipped up a trivial patch for cc-styles.el and sent it along to the cc-modes package maintainer for inclusion in a future version of that package. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
