learning python ...

[hw]

On 5/24/21 3:54 PM, Chris Angelico wrote:
> On Mon, May 24, 2021 at 11:35 PM hw <hw at adminart.net> wrote:
>>
>> On 5/24/21 9:52 AM, Chris Angelico wrote:
>>> Does C give you a warning if you create a function-local variable
>>> called "printf"? No, and it shouldn't. Does any other language
>>> complain if you use its scoping rules to reuse a name? Nope. Does
>>> Python? As above, no.
>>
>> Try the equivalent of above python in C:
>>
>>
>> void foo(void) {
>>       int int = 25;
>>       printf("int: %d\n", int);
>> }
>>
>> int main(int argc, char **argv) {
>>       foo();
>> }
> 
> I did specifically mention "printf", which works just fine, as you see below.

see below

>> I don't know which C compiler you're using; gcc doesn't compile this and
>> gives several error messages.  Python quietly allows things like this
>> without any warning at all, and I'm saying that's a bad thing and that
>> python seems unfinished because it doesn't even give a warning in cases
>> like this.
> 
> You keep using that word "unfinished". I do not think it means what
> you think it does.

What do you think I think it means?

> Python has keywords. C has keywords. In Python, "None" is a keyword,
> so you can't assign to it; in C, "int" is a keyword, so you can't
> assign to it. There is no fundamental difference here, and the two
> languages even have roughly the same number of keywords (35 in current
> versions of Python; about 40 or 50 in C, depending on the exact
> specification you're targeting). The only difference is that, in
> Python, type names aren't keywords. You're getting caught up on a
> trivial difference that has happened to break one particular test that
> you did, and that's all.

Then what is 'float' in the case of isinstance() as the second 
parameter, and why can't python figure out what 'float' refers to in 
this case?  Perhaps type names should be keywords to avoid confusion.

>> I don't know REXX, and I'm not sure what the equivalent would be in
>> elisp.  The issue doesn't exist in perl.  It may be intentionally so
>> that python makes it easy to defeat fundamental aspects of the language
>> simply by, accidentially or intentionally, re-defining them without
>> warning, and even if that is so, nobody else has to like a feature like
>> that just because you do like it.
> 
> REXX doesn't have keywords at all. (It has language syntax words, but
> everything is contextual, so you can quite happily say "if = 1" and
> then "if if" becomes valid.) Perl has keywords, just like everything
> else, but not for data types.
> 
> This is NOT something fundamental to the language that is "defeated".
> You have made it harder to perform isinstance checks, but that's
> neither fundamental nor defeated by this shadowing. The integer type
> still exists - you just made a new variable with the name "int". The
> float type still exists - you just made a new variable with the name
> "float".

Ok, that is an important difference.

>> Maybe you can show how this is a likeable feature.  I already understood
>> that you can somehow re-define functions in python and I can see how
>> that can be useful.  You can do things like that in elisp as well.  But
>> easily messing up built-in variable types like that is something else.
>> Why would I want that in a programming language, and why would I want to
>> use one that allows it?
> 
> Because all you did was mess with the *name* of the type. It's not
> breaking the type system at all.

And how is it a likeable feature?

> Most Python programs manage just fine
> without ever doing an isinstance check, and even if you do have to,
> it's possible to refer to the type in other ways:
> 
>>>> (1).__class__
> <class 'int'>
> 
>>>> int = 42
>>>> isinstance(int, (1).__class__)
> True
> 
> See? Not broken. All you did was change the meaning of the name "int",
> by assigning to it.

No, but I take your word for it.

>> 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.
> 
> The C language never says that Python is "unfinished". I'm not making
> assumptions, I'm reading your posts.

I never said it is unfinished, I said it /seems/ unfinished.  In any 
case, there is nothing insulting about it.  Python is still being worked 
on (which is probably a good thing), and the switch from version 2 to 
version 3 has broken a lot of software, which doesn't help in making it 
appear as finished or mature.

>> The example you want is probably this one:
>>
>>
>> #include <stdio.h>
>>
>> void foo(void) {
>>       int printf = 25;
>>       printf("int: %d\n", printf);
>> }
>>
>> int main(int argc, char **argv) {
>>       foo();
>> }
>>
>>
>> Perhaps you can't see how both examples are different because you're
>> looking at things from a python perspective.
> 
> Well, look at them from a language design perspective and tell me how
> different they really are.

Just look at what the compiler says when you try to compile these 
examples.  In the first example, you can't defeat a built-in data type 
by assigning something to it, and in the second one, you declare 
something as an instance of a build-in data type and then try to use it 
as a function.  That is so because the language is designed as it is.

And if you want to compare that to python, C is entirely clear in both 
examples while python is anything but clear.  This makes me wonder if 
people are using external tools for python to discover ambiguities 
because python is not as easy and clear to read as the designers 
intended.  Maybe at the end of the day, the good intentions aren't 
working to the benefit of the programmer as much as it would seem at 
first.  Maybe they work better for everyone else who reads a program, 
after the programmer has worked things out.