On Fri, Dec 30, 2005 at 10:16:43AM -0500, Barry Warsaw wrote:
> On Thu, 2005-12-29 at 22:29 -0600, Ka-Ping Yee wrote:
> > In a fair number of cases, Python doesn't follow its own recommended
> > naming conventions. Changing these things would break backward
> > compatibility, so they are out of th
I think the discussion is coming to a clear conclusion here not to do
this (except for the standard library classes like anydbm.error). I'm
piping in with my own -1 (for all the sane reasons) to hopefully stop
this thread quickly. We don't need more noise here.
--Guido
On 12/29/05, Ka-Ping Yee <[
On Thu, 2005-12-29 at 22:29 -0600, Ka-Ping Yee wrote:
> In a fair number of cases, Python doesn't follow its own recommended
> naming conventions. Changing these things would break backward
> compatibility, so they are out of the question for Python 2.*, but
> it would be nice to keep these in min
On Fri, 30 Dec 2005, Fred L. Drake, Jr. wrote:
> On Friday 30 December 2005 06:31, Ka-Ping Yee wrote:
> > Is there a really good reason to do that? It's not obvious to me.
>
> No more than there is to rename None to none or NONE.
For that, there is a reason: None is not a class.
-- ?!ng
__
?!ng proposes:
> Constants in all caps:
> NONE, TRUE, FALSE, ELLIPSIS
>
> Classes in initial-caps:
> Object, Int, Float, Str, Unicode, Set, List, Tuple, Dict,
> and lots of classes in the standard library, e.g.
> anydbm.error, csv.excel, imaplib.error, mutex.
On Friday 30 December 2005 06:31, Ka-Ping Yee wrote:
> Is there a really good reason to do that? It's not obvious to me.
No more than there is to rename None to none or NONE.
-Fred
--
Fred L. Drake, Jr.
___
Python-Dev mailing list
Python-Dev@p
On Friday 30 December 2005 06:10, Ka-Ping Yee wrote:
> > In fact, I like it that the basic Python functions
>
> I didn't say anything about renaming functions. Functions in lowercase
> are one of the naming conventions that Python does follow consistently.
well, it is not consistent when looking
Ka-Ping Yee wrote:
> On Fri, 30 Dec 2005, "Martin v. Löwis" wrote:
>
>>Ka-Ping Yee wrote:
>>
>>>That would be cool. If so, it would make sense for them to be all in
>>>lowercase.
>>
>>And rename None to null in the process :-)
>
>
> Is there a really good reason to do that? It's not obvious to
On Fri, 30 Dec 2005, "Martin v. Löwis" wrote:
> Ka-Ping Yee wrote:
> > That would be cool. If so, it would make sense for them to be all in
> > lowercase.
>
> And rename None to null in the process :-)
Is there a really good reason to do that? It's not obvious to me.
-- ?!ng
__
Ka-Ping Yee wrote:
>>Actually, I thought some of them would become reserved words in P3k,
>>anyway.
>
>
> That would be cool. If so, it would make sense for them to be all in
> lowercase.
And rename None to null in the process :-)
Regards,
Martin
___
Brett Cannon wrote:
> I am fine with changing the built-in types, but changing the built-in
> singletons just looks *really* odd to me. So odd that I just don't
> want to see them changed. I mean when I think of constants, I think
> of a variable that references an object and that reference never
On Fri, 30 Dec 2005, Reinhold Birkenfeld wrote:
> Ka-Ping Yee wrote:
> > Constants in all caps:
> > NONE, TRUE, FALSE, ELLIPSIS
>
> That's ugly.
I know it looks ugly to you now. But there's a good reason why we use
capitalization for class names -- anyone reading code who comes across
Brett Cannon wrote:
> I am fine with changing the built-in types, but changing the built-in
> singletons just looks *really* odd to me. So odd that I just don't
> want to see them changed. I mean when I think of constants, I think
> of a variable that references an object and that reference never
Ka-Ping Yee wrote:
> In a fair number of cases, Python doesn't follow its own recommended
> naming conventions. Changing these things would break backward
> compatibility, so they are out of the question for Python 2.*, but
> it would be nice to keep these in mind for Python 3K.
>
> Constants
On 12/29/05, Ka-Ping Yee <[EMAIL PROTECTED]> wrote:
> In a fair number of cases, Python doesn't follow its own recommended
> naming conventions. Changing these things would break backward
> compatibility, so they are out of the question for Python 2.*, but
> it would be nice to keep these in mind
In a fair number of cases, Python doesn't follow its own recommended
naming conventions. Changing these things would break backward
compatibility, so they are out of the question for Python 2.*, but
it would be nice to keep these in mind for Python 3K.
Constants in all caps:
NONE, TRU
16 matches
Mail list logo
