Re: [Python-Dev] Wow!
http://en.wikipedia.org/wiki/Kessler_Syndrome On Fri, Feb 13, 2009 at 1:12 PM, Raymond Hettinger wrote: > > http://www.latimes.com/news/science/la-sci-satellite-collision15-2009feb15,0,7901281.story > ___ > 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/kirklin.mcdonald%40gmail.com > ___ 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] Status of PEP 3143?
What is the status of PEP 3143? It appears to be aimed at 3.2, but there does not appear to be a resolution on it. ___ 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 PEP about 2.6 -> 3000 code transition?
On Mon, Jul 21, 2008 at 2:37 PM, Lennart Regebro <[EMAIL PROTECTED]> wrote: > On Mon, Jul 21, 2008 at 20:16, Brett Cannon <[EMAIL PROTECTED]> wrote: >> But waiting until all the betas have gone out totally defeats the >> purpose of the betas! > > I agree. Writing an actual *guide* can wait, but documenting the > differences with code examples is a work that can start now, and I > agree that it would be great if this would start now. > > But writing a guide might not be a good idea until we know what the > changes are, and if the API is changing quickly now we don't. :-) > I am the nominal maintainer of the D programming language's bindings to the Python/C API.[1] Keeping on top of the changes in the C API is therefore of some interest to me. At the heart of these bindings is 3000 or so lines of D code containing the translated C headers. Adding the changes made in 3.0 (and 2.6, for that matter) will probably have to be done by hand. Any document detailing every change, from the broadest refactorings to the tiniest name-changes, will therefore be of invaluable assistance to me. Obviously, I don't plan on even starting this upgrade until the C API is nailed down and such a document exists. But any drafts, or even a bulleted list of changes, would at least give me an idea of the scope of what I'm in for. [1] http://pyd.dsource.org -Kirk McDonald ___ 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] Reindenting the C code base?
On Mon, Dec 15, 2008 at 11:21 AM, Brett Cannon wrote:
> On Mon, Dec 15, 2008 at 00:20, Georg Brandl wrote:
> > Jeffrey Yasskin schrieb:
> >> On Sun, Dec 14, 2008 at 8:26 AM, Guido van Rossum
> wrote:
> >>> On Sat, Dec 13, 2008 at 2:11 PM, Antoine Pitrou
> wrote:
> >>>> Guido van Rossum python.org> writes:
> >>>>>
> >>>>> I think we should not do this. We should use 4 space indents for new
> >>>>> files, but existing files should not be reindented.
> >>>>
> >>>> Well, right now many files are indented with a mix of spaces and tabs,
> depending
> >>>> on who did the edit and how their editor was configured at the time.
> >>>
> >>> That's a shame. We used to have more rigorous standards than allowing
> that.
> >>>
> >>>> Perhaps a graceful policy would be to mandate that all new edits be
> made with
> >>>> spaces without touching other functions in the file. Then hopefully
> the code
> >>>> base would gradually converge to a tabless scheme.
> >>>
> >>> I don't think so. I find local consistency more important than global
> >>> consistency. A file can become really hard to read when different
> >>> indentation schemes are used in random parts of the code.
> >>>
> >>> If you have a problem configuring your editor, just say so and someone
> >>> will explain how to do it.
> >>
> >> I've never figured out how to configure emacs to deduce whether the
> >> current file uses spaces or tabs and has a 4 or 8 space indent. I
> >> always try to get it right anyway, but it'd be a lot more convenient
> >> if my editor did it for me. If there are such instructions, perhaps
> >> they should be added to PEPs 7 and 8?
> >
> > I use this little hack to detect indentation in Python's C files:
> >
> > (defun c-select-style ()
> > "Hack: Select the C style to use from buffer indentation."
> > (save-excursion
> >(if (re-search-forward "^\t" 3000 t)
> >(c-set-style "python")
> > (c-set-style "python-new"
> >
> > (add-hook 'c-mode-hook 'c-select-style)
> >
> > -- where "python" and "python-new" are two appropriate c-mode styles.
> >
>
> Anyone have something similar for Vim?
>
> -Brett
>
Something along the lines of:
:fu Select_c_style()
: if search('^\t')
: set noet
" etc.
: el
: set et
" etc.
: en
:endf
:au BufRead *.[ch] call Select_c_style()
-Kirk McDonald
___
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
