Coding style question

[Sean Cazzell]

The TurboGears site suggests PEP 8 style be used but I have noticed
CherryPy, SQLObject and TG mostly use mixedCase style for method names.
So is the official recommendation PEP 8 but mixedCase methods?


Kind Regards,

Sean Cazzell

[Ian Bicking]

Sean Cazzell wrote:
> The TurboGears site suggests PEP 8 style be used but I have noticed
> CherryPy, SQLObject and TG mostly use mixedCase style for method names.
> So is the official recommendation PEP 8 but mixedCase methods?

SQLObject gets that style from Webware. But otherwise I've personally
moved to underscore separated in my other projects. But it's really
mixed everywhere; I can't even figure out what Zope 3 prefers, for
instance (they often have good style guidelines, but unfortunately
sometimes as vague as everyone else). PEP 8 is vaguely neutral on
underscores vs. mixed case, at least for methods.

--
Ian Bicking | ia...@colorstudy.com | http://blog.ianbicking.org

[Sean Cazzell]

I don't have very strong feelings one way or the other as long as things
are consistent. It is annoying to have to constantly stop and try to
remember if a method is foo.doSomething or foo.do_something.

But I am noticing the core of TG and most of the third-party components
use mixedCase while some of the newer TG code is dutifully following the
recommended PEP 8 underscore style. This means TG is not even using
consistent naming itself.

Since SQLObject and CherryPy use mixedCase style TG probably should
break with the PEP in this case.

FWIW, I don't think that PEP 8 is neutral on this topic, but we have to
live with what we have.


Kind Regards,

Sean Cazzell

[Kevin Dangoor]

On 11/5/05, Sean Cazzell <seanc...@gmail.com> wrote:
> I don't have very strong feelings one way or the other as long as things
> are consistent. It is annoying to have to constantly stop and try to
> remember if a method is foo.doSomething or foo.do_something.
>
> But I am noticing the core of TG and most of the third-party components
> use mixedCase while some of the newer TG code is dutifully following the
> recommended PEP 8 underscore style. This means TG is not even using
> consistent naming itself.
>
> Since SQLObject and CherryPy use mixedCase style TG probably should
> break with the PEP in this case.
>
> FWIW, I don't think that PEP 8 is neutral on this topic, but we have to
> live with what we have.

Personally, I am a fan of mixedCase (possibly just got used to it from
Java, but I think it's more likely that i like it because it's faster
to type). But, having PEP8 around is nice because it's a thorough
style guide that is already written. That was why I opted for PEP8.

You're correct that some of the earlier TurboGears bits did not follow
PEP8, and that should be fixed.

I *would* actually agree with you that breaking from PEP8 for
mixedCase is a good thing (and you're correct that it's not neutral on
this topic). However, there was this thread on the CherryPy list:
http://tinyurl.com/74kzo

So, CP 2.2 might be switching to PEP8. I should probably query about
that, though. If CP is switching to PEP8, then I'll try to make
TurboGears consistently names_with_underscores before 1.0. If CP is
going to stick with mixedCase, then changing TurboGears to mixedCase
is a good idea.

Kevin

[Kevin Dangoor]

Hi Sean,

On 11/5/05, Sean Cazzell <seanc...@gmail.com> wrote:

> Since SQLObject and CherryPy use mixedCase style TG probably should
> break with the PEP in this case.
>
> FWIW, I don't think that PEP 8 is neutral on this topic, but we have to
> live with what we have.

I got confirmation from a CherryPy developer (Robert "fumanchu"
Brewer) that CP 2.2 and onward are moving to PEP8
names_with_underscores.

So, we'll just work on fixing up the stragglers in the TurboGears code
and at least CP and TurboGears will be in sync.

Kevin

[Sean Cazzell]

Kevin,

Great, I saw your post on CP-dev. I wonder if Ian would consider
transitioning SQLObject? I know he mentioned earlier that all of his
new code (in other projects) is using names_with_underscores.

But there is a very clear line between your model objects and TG, so I
don't think having different naming in that case is going to be too
difficult for anyone.


Sean Cazzell

[Ian Bicking]

Sean Cazzell wrote:
> Great, I saw your post on CP-dev. I wonder if Ian would consider
> transitioning SQLObject? I know he mentioned earlier that all of his
> new code (in other projects) is using names_with_underscores.

I'm not sure how feasible it really is. It's an annoying transition to
make, as it breaks everything, but only *barely* breaks everything.
SQLObject generally provides good backward compatibility. Also, there's
quite a bit of indirect documentation out there, little of which is
likely to be updated.

I am changing some names as I reimplement things (like the new joins are
ManyToMany and OneToMany), and new functions added will probably be
underscore separated (and it's not uncommon that functions and methods
have different styles). But I'm not sure if I can change the naming
convention.

--
Ian Bicking / ia...@colorstudy.com / http://blog.ianbicking.org

[Leandro Lucarella]

Ian Bicking, el lunes 7 de noviembre a las 11:40 me escribiste:

It's not that hard to keep both naming conventions to keep backward
compatibility, deprecating the old names, like:

class Something:
def some_old_method(self):
pass
someOldMethod = some_old_method

You can (probably) even add some sort of decorator to someOldMethod to
automatically throw a deprecation warning or something. For example:

class Something:
def some_old_method(self):
pass
someOldMethod = deprecated(some_old_method)

--
Leandro Lucarella (luca) | Blog colectivo: http://www.mazziblog.com.ar/blog/
.------------------------------------------------------------------------,
\ GPG: 5F5A8D05 // F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05 /
'--------------------------------------------------------------------'
No es malo que en la condición humana exista la mentira. Miente el púber
si quiere ponerla.
-- Ricardo Vaporeso. Madrid, 1921.