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
[email protected]
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 Sat, 13 Dec 2008, Guido van Rossum wrote: If you reindent, much of the history of the file is essentially lost -- "svn blame" will blame whoever reindented the code, and it's a pain to go back. I am not a subversion specialist, but it appears this part can be handled gracefully by passing -b (ignore space change) to an external diff command svn blame can rely on (svn blame -x -ub ...). At least, it seems to work on my station (GNU Diffutils, Subversion 1.5.1)! -- Sylvain ___ Python-Dev mailing list [email protected] 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 Sat, Dec 13, 2008 at 11:26 PM, Guido van Rossum wrote: > > I think we should not do this. We should use 4 space indents for new > files, but existing files should not be reindented. If you reindent, > much of the history of the file is essentially lost -- "svn blame" > will blame whoever reindented the code, and it's a pain to go back. > There's also the issue of merging between the 2.x and 3.x branches, > which we still do. "svnadmin dump" produces pretty munchable text file to pretend that there were no tabs at all. The problem may be to sync working copies with old new repository. http://svnbook.red-bean.com/en/1.5/svn.ref.svnadmin.c.dump.html svn pre-commit hook can be used to avoid any unescaped tabs in future commits. http://svnbook.red-bean.com/en/1.5/svn.ref.reposhooks.pre-commit.html Adding pre-commit hook is better than adding editor-specific comments, because it doesn't require your editor to support the syntax - regardless of editor you will have to convert tabs file to spaces anyway. -- --anatoly t. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Trap SIGSEGV and SIGFPE
On Dec 11, 2008, at 3:05 PM, Martin v. Löwis wrote: If it is actually possible to print a stack trace, that could be useful indeed. I'm then skeptical that this is possible in the general case (i.e. displaying the full C stack), but displaying (parts of) the Python stack might be possible. I think it should still proceed to dump core, so that you can then inspect the core with a proper debugger. +1. Victor, any interest in attempting to retool your patch in this direction? -- Ivan Krstić | http://radian.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] The endless GIL debate: why not remove thread support instead?
On Dec 13, 2008, at 5:47 PM, Martin v. Löwis wrote: They were originally invented in 1965, on Multics (1970) they were used to perform compilation in the background. When Unix came along, it *added* address space separation, introducing what is now known as processes. Yes, and a lot of the subsequent interest in threads came due to the historically debilitating overhead of fork() on some important Unices, notably Solaris. -- Ivan Krstić | http://radian.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Calling the GC less often when there are lots of long-lived objects
Hello, There are recurring complaints about the garbage collector degrading performance when lots of objects are created in a row. In issue #4074, I've proposed a patch which basically implements Martin's suggestion in http://mail.python.org/pipermail/python-dev/2008-June/080579.html to base the decision to do a full collection on the ratio between the number of objects surviving the (n-1) generation collection and the number of long-lived objects. I've also added a condition so that this new behaviour is only triggered when there are more than 1 long-lived objects -- therefore, cycles will still get collected quickly in lightweight programs. In Gregory's simple test of storing many tuples in a list, the behaviour has indeed changed from exponential to linear. Is anybody opposed to the principle of this proposal? Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Calling the GC less often when there are lots of long-lived objects
Antoine Pitrou wrote: I've proposed a patch which basically implements Martin's suggestion in http://mail.python.org/pipermail/python-dev/2008-June/080579.html Is anybody opposed to the principle of this proposal? Sounds okay to me. -- Greg ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Calling the GC less often when there are lots of long-lived objects
Antoine Pitrou schrieb: > Is anybody opposed to the principle of this proposal? Is it reasonable to implement multiple policies so the user can switch between them? Or is the new algorithm superior in all cases? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Calling the GC less often when there are lots of long-lived objects
Christian Heimes cheimes.de> writes: > > Is it reasonable to implement multiple policies so the user can switch > between them? Or is the new algorithm superior in all cases? We could let the user configure the threshold between the old policy and the new policy. Currently it is hard-wired to a value of 1 (that is, 1 long-lived objects tracked by the GC). ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [ANN] EuroPython 2009 – Call for Participation!
On behalf of the EuroPython 2009 organisation it is my privilege and honour to announce the 'Call for Participation' for EuroPython 2009! EuroPython is the conference for the communities around Python, including the Django, Zope and Plone communities. This years conference will be held in Birmingham, UK from Monday 29th June to Saturday 4th July 2009. Talk & Themes Do you have something you wish to present at EuroPython? Go to http://www.europython.eu/talks/cfp/ for this years themes and submissions criteria, the deadline is on 5th April 2009. Other Talks, Activities and Events Have you got something which does not fit the above? Visit http://www.europython.eu/talks/ . Help Us Out We could use a hand any contribution is welcome, please take a look at http://www.europython.eu/contact/ . Sponsors An unique opportunity to affiliate with the prestigious EuroPython conference! http://www.europython.eu/sponsors/ Spread the Word Improve our publicity by distributing this announcement in your corner of the community, please coordinate this with the organizers: http://www.europython.eu/contact/ General Information For more information about the conference, please visit http://www.europython.eu/ Looking forward to see you! The EuroPython Team ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
