On 3/20/07, Christoph Zwerschke <[EMAIL PROTECTED]> wrote:
> Chuck Esterbrook schrieb:
> > What about [EMAIL PROTECTED]'s suggestion:
> > """
> > What if you stayed with tabs and then added a converter, so that you
> > can quickly convert the tabs to the number of spaces that you want?
> > In fact, this might be a good idea for a lot of free source Python
> > projects distributed on the web -- though I would suspect it would be
> > better to use tabs as the default and offer the ability to convert to
> > space because sometimes it's possible it might not look quite right
> > converting a project coded for spaces to tabs.
> > """
> >
> > It allows everyone to use their favorite approach.
> >
> > You mentioned something about patches being a mess, but I don't see
> > why. People could send in patches as "all spaces" or "all tabs" or am
> > I not thinking of something?
>
> I saw the problem in converting to the number of spaces "that you want".
> As long as the converter uses a fixed size, it would not be a mess.
Why couldn't it be to the number "that you want" and then back? That
might be nice. Some people like 2, some 3 and some 4. A clever tabify
could even detect it.
But nevermind because I see your point further below.
> It still would be inconvenient, because you always have to think about
> this issue and either convert back and forth manually, or use a script,
> or change the settings in your editor. I'm working with a lot of Python
> code from various sources, and they all use 4 spaces for indentation
> since it's recommended in PEP8. I do not even need to think about tabs
> and tab sizes any more, it's only Webware where I need to worry.
Well, actually why do you need to worry? I set my editor to Tab Size =
4 years ago and that was it. You can even do Tab = 3 or Tab = 2 if
your preference is different than mine.
> It's not a big deal and I can live with tabs very well, but if we want
> to change, this release would be a good opportunity.
Ah ha! You said, "I can live with tabs very well."
But even if we did it, I'd prefer any major change after the 1.0 release.
> > I suppose there would then be a burden on people who use spaces to
> > invoke a script prior to checkin, but could that also be done via a
> > script? Something like:
> >
> > # ci
> > tabify -r .
> > svn ci $*
> > spacify -r .
>
> I'm not sure how to do this on the server (repository) side. On the
> client side people also use IDEs or TortoiseSVN to check code in. And
> this should only run for Webware, not for other projects. Generally I
> don't like too much automagic because then you always have to worry
> whether it is really active etc.
Yeah I see what you're saying about IDEs, Tortoise, etc. Good point.
I still think that leaving tabs in place allows people to set the size
to what they want.
I read that Guido likes 4 spaces, but Google, where he now works,
mandates 2. If Guido had mandated tabs and tabs only (1 per indent)
then people could use whatever they want. If he's now mandating 4
spaces for future versions of Python, then he's ramming his preference
down his coworkers' throat. (In this argument, I'll also add a rule of
"no tabs after indentation".) On the other hand, maybe he has other
reasons for doing it ("normalizing" Python source code appearance in
print, for example).
-Chuck
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Webware-devel mailing list
Webware-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/webware-devel
