On 24/05/2021 14:34, hw wrote:
>
> Your claim that I'm insulting python or anoyone is ridiculous.
> According to your logic, C is insulting python.  I suggest you stop
> making assumptions.
Calling a mature, widely used language "unfinished" because of what
*you* see as a defect *is* insulting.
(Of course, all languages evolve, and Python is no exception.  But the
change you are in effect proposing won't happen.)
And using a hectoring arrogant tone as a self-confessed Python beginner
when addressing veterans with decades of experience in *developing
Python* as well as developing with Python (disclosure: I'm not
describing myself) is unlikely to endear anyone to your views.

Python has few keywords (deliberately so), and anything that is not a
keyword can be used as an identifier.  That will stop your program from
crashing in 5 years time if a new built-in type is added to the language
that happens to have the same name as an identifier you used (like maybe
'quaternion'  'matrix'  'group'  'query', to imagine a few).

One day you may want to write (as you can in Python)

    class int(int):
        .....

to shadow the built-in 'int' type with a modified version.  I'm not
suggesting this has many real world applications, but it can be fun to
play with.  Python has a "consenting adults" policy: it assumes that if
you do something weird, you're doing it deliberately, and it doesn't try
to stop you.  I am sure after a little more experience with Python you
will remember the commonest built-in types (int, float, list, dict, str
etc.).

Regards
Rob Cliffe

On 24/05/2021 09.32, Rob Cliffe wrote:

> One day you may want to write (as you can in Python)
>
>     class int(int):
>         .....
>
> to shadow the built-in 'int' type with a modified version.  I'm not
> suggesting this has many real world applications, but it can be fun to
> play with.  Python has a "consenting adults" policy: it assumes that if
> you do something weird, you're doing it deliberately, and it doesn't try
> to stop you.  I am sure after a little more experience with Python you
> will remember the commonest built-in types (int, float, list, dict, str

In my early days of writing python, I created lists named "list",
dictionaries named "dict", and strings named "str". I mostly know better
now, but sometimes still need to restrain my fingers.

--
Michael F. Stemper
Nostalgia just ain't what it used to be.

On 24/05/2021 16:54, Michael F. Stemper wrote:

> In my early days of writing python, I created lists named "list",
> dictionaries named "dict", and strings named "str". I mostly know better
> now, but sometimes still need to restrain my fingers.

I think most newbie programmers make that mistake. I certainly
did when learning Pascal back in the 80's.

But I was lucky, the tutorials were run by a guy who penalized
bad variable names severely and took a half-mark off for every
bad name. We very quickly learned to choose names that were
descriptive of the purpose rather than the type.

Its a lesson that I've never forgotten!

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos

On 2021-05-24, Alan Gauld <alan.gauld@yahoo.co.uk> wrote:
> On 24/05/2021 16:54, Michael F. Stemper wrote:
>
>> In my early days of writing python, I created lists named "list",
>> dictionaries named "dict", and strings named "str". I mostly know better
>> now, but sometimes still need to restrain my fingers.
>
> I think most newbie programmers make that mistake. I certainly
> did when learning Pascal back in the 80's.
>
> But I was lucky, the tutorials were run by a guy who penalized
> bad variable names severely and took a half-mark off for every
> bad name. We very quickly learned to choose names that were
> descriptive of the purpose rather than the type.

Tricky when you're writing general utility functions.
What would you call the argument to a function that
returns, say, an upper-cased version of its input?
(Pretending for a moment that Python didn't already
have such a function built-in ;-) )

I mean, sure, you could call it "inputString" or
something but that sort of thing gets annoyingly
verbose very quickly. If you're using type
annotations then "input: str" would be ok but if
you're not then just "input" is overly opaque
(not to mention shadowing a builtin).

This is why it's good when languages have conventions
like "types and classes start with an upper-case letter",
so that you can do "string = String()" without problems...

On 25/05/2021 00:41, Jon Ribbens via Python-list wrote:

> What would you call the argument to a function that
> returns, say, an upper-cased version of its input?

Probably 'candidate' or 'original' or 'initial' or
somesuch. Or even just 's'. Single character names
are OK when there is no significant meaning to convey!

But never a type name since the type could change or
be extended (like bytes or even a user defined string
subclass.)

The exception being where it's a teaching exercise
where the type is important, but even there I'd precede
it with an article: aString, the_string or similar.

--
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos

On 24/05/2021 18.30, Alan Gauld wrote:
> On 24/05/2021 16:54, Michael F. Stemper wrote:
>
>> In my early days of writing python, I created lists named "list",
>> dictionaries named "dict", and strings named "str". I mostly know better
>> now, but sometimes still need to restrain my fingers.
>
> I think most newbie programmers make that mistake. I certainly
> did when learning Pascal back in the 80's.
>
> But I was lucky, the tutorials were run by a guy who penalized
> bad variable names severely and took a half-mark off for every
> bad name. We very quickly learned to choose names that were
> descriptive of the purpose rather than the type.

And when I write code that models something physical, I'll create
an object with attributes named after the real-world attributes
that such an object has. For instance, a generator (NOT in the
python sense) might have attributes such as:
RealPower
ReactivePower
IncrementalCostCurve (an object all on its own)
DispatchedPower

But, when I mess around with number theory, if I need a dict
that has naturals as keys and their aliquot sums as values, it's
easy enough to fall into that trap; especially if I already have
a function AliquotSum() that populates the dictionary as it grows.

--
Michael F. Stemper
Deuteronomy 10:18-19