Prev: integer >= 1 == True and integer.0 == False is bad, bad, bad!!!
Next: getting the variable type
From: Marek Kubica on 11 Jul 2010 07:51
On Sun, 11 Jul 2010 00:26:36 -0700 (PDT)
rantingrick <rantingrick(a)gmail.com> wrote:

> Another source of asininity seems to be the naming conventions of the
> Python language proper! True/False start with an upper case and i
> applaud this. However str, list, tuple, int, float --need i go
> on...?-- start with lowercase.

Achtually, these are type names with their own constructor. The name of
the type of True and False is bool and, bool() returns a bool-object.

regards,
Marek
From: News123 on 11 Jul 2010 09:46
Andre Alexander Bell wrote:
> On 07/11/2010 10:30 AM, rantingrick wrote:

>>> So, it is not a disadvantage that the functions you listed above are
>>> named in this way. In the contrary, it is an advantage, as it keeps
>>> newcomers from using stupid variable names.
>> "int" for an Integer is stupid?
>> "list" for a List is stupid?
>> "str" for a String is stupid?
>>
>> What am i missing?
>
> You are missing (from PEP 8):
>
> --- 8< --- 8< ---
> Class Names
>
> Almost without exception, class names use the CapWords convention.
> Classes for internal use have a leading underscore in addition.
>
> --- 8< --- 8< ---
>
> You may want to think of list, int, str, object, ... as classes that
> don't follow this advice with their class name.
>
> But besides that, shouldn't a variable name reflect it's purpose instead
> of it's type? E.g.

hm, well sometimes I do write generic functions, that do something with
a list or a string or an int.

However a simple way around this is to use following naming style.

to replace
def process_list(list):
dostuff_with(list)

with
def process_list(alist):
dostuff_with(alist)

or with
def process_list(a_list):
dostuff_with(a_list)

I must admit, that I have still problems
to not use the variables range or id




From: Andreas Waldenburger on 11 Jul 2010 10:24
On Sun, 11 Jul 2010 15:46:40 +0200 News123 <news1234(a)free.fr> wrote:

> Andre Alexander Bell wrote:
> > On 07/11/2010 10:30 AM, rantingrick wrote:
>
> >>> So, it is not a disadvantage that the functions you listed above
> >>> are named in this way. In the contrary, it is an advantage, as it
> >>> keeps newcomers from using stupid variable names.
> >> "int" for an Integer is stupid?
> >> "list" for a List is stupid?
> >> "str" for a String is stupid?
> >>
> >> What am i missing?
> >
> > [snip]
>
> hm, well sometimes I do write generic functions, that do something
> with a list or a string or an int.
>
> [snip]
>
> I must admit, that I have still problems
> to not use the variables range or id
>

There are several approaches:

- Use range_, id_, and so on. I think this is the proposed convention.
Slightly ugly, though.
- Use abbreviations, or misspellings like lst, Set, klass, ... Less
ugly, but can get weird.
- Prepend 'a' to a type name: alist, aset, astr. Similar weirdness
potential as above, but more consistent in terms of style. I
sometimes take this to the extreme and prepend 'some_'.

So really, this is a non issue, at least for me.

Having capitalized boolean values ... that is a bit odd, but as long as
children are starving in Africa, this isn't very high on my gripe-list.

/W

--
INVALID? DE!

From: News123 on 11 Jul 2010 10:36
Andreas Waldenburger wrote:
>
> Having capitalized boolean values ... that is a bit odd, but as long as
> children are starving in Africa, this isn't very high on my gripe-list.
>
+1
From: MRAB on 11 Jul 2010 13:23
rantingrick wrote:
> Another source of asininity seems to be the naming conventions of the
> Python language proper! True/False start with an upper case and i
> applaud this. However str, list, tuple, int, float --need i go
> on...?-- start with lowercase.
>
> Q: Well what the hell is your problem Rick. Who cares right?
>
> WRONG, I tell you what my problem is. Now i cannot "wisely" use
> variables like...
>
> str="this is a string"
> list = [1,2,3]
> def make_random_objs(range=10)
> def show_message(str)
> int = 12
>
> If we would have adopted proper naming conventions from dios numero
> uno all this nonsense would be rectified! Str, Float, List, Range,
> etc, etc. You think Python 3000 was a hump to climb over just wait for
> Python 4000.
>
> Just thoughts.

If you're so unhappy with Python, why don't you create your own
language. I suggest the name "Rantthon".
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: integer >= 1 == True and integer.0 == False is bad, bad, bad!!!
Next: getting the variable type