learning python ...

[hw]

On 5/25/21 10:32 AM, Chris Angelico wrote:
> On Tue, May 25, 2021 at 1:00 PM hw <hw at adminart.net> wrote:
>>
>> On 5/24/21 3:54 PM, Chris Angelico wrote:
>>> 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?
> 
> I think it means that the language is half way through development,
> doesn't have enough features to be usable, isn't reliable enough for
> production, and might at some point in the future become ready to use.

Right, that is what it seemed.

> None of which is even slightly supported by evidence.

That's not true.  Remember the change from version 2 to 3 and ask 
yourself how likely it is that breaking things like that happens again. 
  You may find a statement from developers about a policy that changes 
are to be announced a year before they go in, and that is evidence enough.

What you make of this policy and what it means to you is for you to 
decide, but the evidence is clearly there.

>>> 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.
> 
> It's a name. In Python, any name reference is just a name reference.
> There's no magic about the language "knowing" that the isinstance()
> function should take a keyword, especially since there's no keywords
> for these things.

When I look at the error message, it seems to indicate that python knows 
very well what kind of parameter is expected.

>>>> 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?
> 
> You can complain about whether it's likeable or not, but all you're
> doing is demonstrating the Blub Paradox.

And you remain unable to show how python making it easy to mess up type 
names is a likeable feature.

>>> 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.
> 
> It's been around for thirty years. Quit fudding. You're getting very
> close to my killfile.

I take it you can't stand it when someone thinks differently than you 
do.  Good for you that you have a kill file to protect you from 
different thoughts and ideas.

> Python 3 has been around since 2009. Are you really telling me that
> Python looks unfinished because of a breaking change more than a
> decade ago?

It looked unfinished to me because it doesn't even give an error message 
when I assign something to a type name as if it was a variable.

Breaking things like that doesn't help, and it doesn't matter that it 
happened a while ago because I still have to deal with the issues it caused.

That something has been around for a while doesn't have anything to do 
with how finished or unfinished it may appear.

> The Go language didn't even *exist* before Python 3 - does
> that mean that Go is also unfinished?

Go is one of the games I never learned to play, though it seems kinda 
interesting.

>> 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.
> 
> Yes, because C uses keywords for types. That's the only difference
> you're seeing here. You keep getting caught up on this one thing, one
> phenomenon that comes about because of YOUR expectations that Python
> and C should behave the same way. If you weren't doing isinstance
> checks, you wouldn't even have noticed this! It is *NOT* a fundamental
> difference.

When it doesn't make a difference, then why doesn't python just use 
keywords for types and avoids all this ambiguity?

> Also, you keep arguing against the language, instead of just using it
> the way it is. It really sounds to me like you'd do better to just
> give up on Python and go use some language that fits your brain
> better. If you won't learn how a language works, it's not going to
> work well for you.

I'm not arguing against the language but discussing it with people who 
are trying to defend it.  I tried to use it yesterday and failed because 
the documentation of a library I wanted to use it with is bad, and 
because maybe it wasn't such a good library.  I would use it with 
another library for another purpose, but there is no documentation for 
that library at all, so I can't use it.  So currently, it's not looking 
good for learning python.