RE: learning python ...

[Avi Gross via Python-list]

I have studied many programming languages and am amused when people attack 
python as if every other language is somehow more optimal.

Cameron and others have provided examples but look at positives AND negatives.

Yes code like: num = int(num)

does look a tad off as it reuses the same name for something that is actually 
in many ways different. You could easily use a new name. But then you would 
have TWO variables in your name space and the old one would not be garbage 
collected unless you explicitly removed it. If you follow this path, would you 
suggest not writing: X = X + 1 either? 

It is actually a fairly common practice in many languages to have code like 
this:

Var = read in something from a file and make some structure like a data.frame
Var = remove some columns from the above thing pointed to by Var
Var = make some new calculated columns ditto
Var = remove some rows ...
Var = set some kind of grouping on the above or sort it and so on.

As you go along you may keep transforming but have no need for earlier results, 
just the new and improved one. So why keep changing names? Some languages 
support not having any names for intermediate results by using nested function 
calls or pipelines.

The reality is that most languages have a series of what I loosely would call 
environments or name tables and as they run, new ones regularly get created and 
removed and even the order of them may change. The algorithm for searching for 
a name varies and can be in some sense linear or more complex. When looking in 
context for a function name, you may follow a different trail or the same one 
as for a variable holding a string and in some implementations the same name 
shadows and in others does not. Wait till you try to figure out the diamond 
pattern of inheritance when you create classes that depend on multiple other 
classes ad nauseum and you try to call a method and it tries to find the one 
you wanted by searching backwards in an interesting way. Many other languages 
decided to just not allow multiple inheritance!

How can you write a recursive function without this kind of variable shadowing? 
Each invocation of a function places the internal namespace in front of the 
parent so the meaning of a variable name used within is always backed by  all 
the iterations before it. But with some kinds of closures, a function may be 
gone and yet variables it had within it persists. Lots of odd examples more 
make this a complex set of CHOICES. 

So what if you suggest we allow re-use of names but WARN you. OK, Python is a 
largely interpreted language. Normally if you ask to use a variable called X, 
it starts a search in the nearest place then the next one and so on till it 
finds it or fails. In many programs, variables are fairly local and found 
easily. But if you want, you can search dozens or hundreds of places and find 
each and every use of X visible at THIS moment and tell the user there are 82 
places it can be seen and here they are. Now what? The first 50 places may be 
in other instances of the recursive function and you have already been warned 
this way 49 times and soon will be warned a few more as it continues to recurse 
as it travels down a tree or graph structure quite legitimately. Some of the 
other  places X may be in use are in some package in a part you are not even 
using indirectly or in middle of a for-loop as a token variable and so on. I 
suspect that 99.99% of the time re-using a name has no negative consequence. 
Making someone keep choosing names like X12346 because there is somewhere an 
X12345 seems a tad silly. But why go to all that expense at run-time versus in 
some lint program?

I recently studied a language called GO that goes to some length to protect  
the user from themselves and often at great expense to getting programming 
done. It won't compile a program if it declares a variable and does not use it. 
Fair enough but I often want to write a sort of shell of a program and check as 
I go to make sure it works before adding more. If I will need 5 variables, I 
might declare them up-front then work on interactions and calculations that 
only include some of them and later I plan on connecting the rest. Nope, it 
won't let me unless I use it as in a print statement or comment it out or just 
remove it. Ah, but then it is not happy I did not initialize it so I set it to 
zero or something. Later, when I finally use it as intended, I need to remove 
the junk. 

Some of this annoyance is so common that they had to come up with a way to shut 
it up. Consider this line:

Result, err = functionA(args)

It returns two arguments. Sometimes it seems silly to worry about the error but 
you MUST write a line of code like:

If (err != nil) {
Do_something
}

Other times you just care if it worked and don't want the result. So placing an 
_ for one or the other is a signal to shut the darn compiler up that you are 
DELIBERATELY ignoring the return value you did not w

Re: learning python ...

[Cameron Simpson]

On 25May2021 06:08, hw  wrote:
>On 5/25/21 12:37 AM, Greg Ewing wrote:
>>If you rebind a name, and it held the last reference to an
>>object, there is no way to get that object back.
>
>Are all names references?

Yes.

>When I pass a name as a parameter to a function, does the object the 
>name is referring to, when altered by the function, still appear 
>altered after the function has returned?  I wouldn't expect that ...

Yes. Please ready the language specification. This is basic to Python's 
function.

>>On the other hand, if you shadow a name, the original name
>>still exists, and there is usually some way to get at it,
>>e.g.
>>
>> >>> int = 42
>> >>> int
>>42
>> >>> __builtins__.int
>>
>> >>>
>>
>
>You mean built-in objects never go away, even when they are no longer 
>referenced?

Well, the builtins module itself has a reference. But what greg's 
showing you above it the "int" class/type. You've got an in in play in 
the code above - the class will of course exist. But the builtin classes 
(and other names) always exist because they're built in.

Cheers,
Cameron Simpson 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Cameron Simpson]

On 25May2021 05:53, hw  wrote:
>That seems like an important distinction.  I've always been thinking of 
>variables that get something assigned to them, not as something that is 
>being assigned to something.

They are what you thought. But it's references to objects what are being 
passed around.  C is a deliberately "close to the machine" language, and 
things a CPU can store in a register are natural types (ints of various 
sizes, etc). But consider a C string:

char *s = "foo";

The compiler here allocates some char storage, puts "foo\0" in it, and 
puts a reference in "s".

char *t = strcpy(s)
char *t2;
t2 = s;
t2 = t;

Here "s", "t" and "t2" are all of type (char*), and store references.  
When you pass "s" or "t" around, eg as above in an assignment, or when 
you pass it to a function, you're not copying the storage, just the 
reference.

Same with Python, except that all the basic types like int and float are 
also done with references.

Cheers,
Cameron Simpson 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[hw]

On 5/25/21 12:37 AM, Greg Ewing wrote:

On 25/05/21 9:27 am, Cameron Simpson wrote:

On 24May2021 16:17, hw  wrote:

 >

Or it doesn't forget
about the old one and the old one becomes inaccessible (unless you
have a reference to it, if there is such a thing in python).  How do
you call that?


You're conflating values
(objects, such as an int or a string) with variables (which _are_
references in Python,


I think hw might have meant the C++ notion of a reference to
a *variable*. There is no equivalent of that in Python.


yes, or a reference in perl


Python does have references to *objects*. All objects live on
the heap and are kept alive as long as there is at least one
reference to them.

If you rebind a name, and it held the last reference to an
object, there is no way to get that object back.


Are all names references?  When I pass a name as a parameter to a 
function, does the object the name is referring to, when altered by the 
function, still appear altered after the function has returned?  I 
wouldn't expect that ...



On the other hand, if you shadow a name, the original name
still exists, and there is usually some way to get at it,
e.g.

 >>> int = 42
 >>> int
42
 >>> __builtins__.int

 >>>



You mean built-in objects never go away, even when they are no longer 
referenced?

--
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[hw]

On 5/24/21 4:28 PM, Michael Torrie wrote:

On 5/24/21 8:17 AM, hw wrote:

What does python actually do in the first example?  Does it overshadow a
variable or does it change one?  If it overshadows a variable, it would
be dubious, if it doesn't, it won't be dubious.


Are you referring to this?

   num = input("Enter a number: ")
   num = int(num)


yes


No it is not "overshadowing" a variable.  You cannot get back to the
original string value for num.


So the other example that uses a second variable to avoid possible 
ambiguity could be considered as bloating because it keeps both 
variables around.



There are more alternatives:  Python might create a new variable with
the same name and forget about the old one.  Or it doesn't forget about
the old one and the old one becomes inaccessible (unless you have a
reference to it, if there is such a thing in python).  How do you call that?


Python variables are not memory boxes like in a compiled language.  They
are names bound to objects, as Mr Simpson alluded to.


That seems like an important distinction.  I've always been thinking of 
variables that get something assigned to them, not as something that is 
being assigned to something.



So in the first
line, the name num is bound to a string.  In the second line, the name
is re-bound to an int object.


I would think of it as assigning a string to a variable and then 
changing the content of the variable by assigning something else to the 
same variable.  When variables are typeless, it doesn't matter if a 
string or an integer is assigned to one (which is weird but can be very 
useful).


It seems much more practical to assign different strings to the same 
variable rather than assigning a different variable to each string, or 
to assign a string to a variable and then to assign an integer to it.


Isn't that what variables are for?


Furthermore, if num had come from the
global name scope, either of these lines would create a local name num
that does shadow the name from the global scope.

Hope that helps.




Yes, I guess it will be interesting not to think of variables but of 
objects.

--
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[hw]

On 5/24/21 4:37 PM, Chris Angelico wrote:

On Tue, May 25, 2021 at 12:31 AM Michael Torrie  wrote:


On 5/24/21 8:24 AM, Chris Angelico wrote:

On Tue, May 25, 2021 at 12:18 AM hw  wrote:

There are more alternatives:  Python might create a new variable with
the same name and forget about the old one.  Or it doesn't forget about
the old one and the old one becomes inaccessible (unless you have a
reference to it, if there is such a thing in python).  How do you call that?


It's the latter option: create a new variable, and the old one becomes
inaccessible. That's called "shadowing". It's how scoping works in
most languages (called "lexical scope").


Is it really shadowing, though?  The old one is not only inaccessible,
it's possibly reaped by the garbage collector, no?  Both nums are in the
same scope so the one overwrote the other in the name table.  Or am I
missing something.



We're talking about many different things. If it's simply "num = ..."
followed by "num = ...", then it's not a new variable or anything,
it's simply rebinding the same name. But when you do "int = ...", it's
shadowing the builtin name.


Why?  And how is that "shadowing"?

What if I wanted to re-define the built-in thing?
--
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[hw]

On 5/24/21 4:41 PM, Michael Torrie wrote:

On 5/24/21 8:21 AM, Michael Torrie wrote:

Given your posts thus far, hw, I don't think Python is a good fit for
you. You're better off learning a language that more closely aligns with
the statically-typed languages you already know.


Maybe it is, maybe it isn't; I've been thinking about it for a while now.


That was unnecessarily harsh; my apologies.  I can see now that you
might be comparing some features to Perl, which is a more dynamic
language.  I see in your recent posts that you are trying to understand
how Python works, and that is good.  Hopefully you'll find Python a
dynamic and useful tool.  If not, that's perfectly okay. Use the right
tool for the job.



That's what I'm trying to do.  I'm just using a particular problem I 
want to solve as an occassion to maybe learn python because it seems 
much easier to solve in python than in perl.


--
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[hw]

On 5/24/21 3:54 PM, Chris Angelico wrote:

On Mon, May 24, 2021 at 11:35 PM hw  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__




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 

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 la

Re: learning python ...

[Jon Ribbens via Python-list]

On 2021-05-24, 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.

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...
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Alan Gauld via Python-list]

On 24/05/2021 19:48, Grant Edwards wrote:

>> Traceback (  File "", line 1
>> if = 1.234
>>^
>> SyntaxError: invalid syntax
> 
> I must admit it might be nice if the compiler told you _why_ the
> syntax is invalid (e.g. "expected conditional expression while parsing
> 'if' statement").

Although wouldn't it be "expected boolean expression" rather than
conditional expression? Python doesn't care how the argument  to 'if'
is arrived at so long as it's a boolean. And with assignment
expressions, conditional expressions and literals all possible
unambiguous error messages get harder and harder to figure out.

But I do accept the general point that slightly more information
about syntax errors would be nice.

-- 
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


-- 
https://mail.python.org/mailman/listinfo/python-list

RE: Question for potential python development contributions on Windows

[pjfarley3]

> -Original Message-
> From: Terry Reedy 
> Sent: Sunday, May 23, 2021 10:05 PM
> To: python-list@python.org
> Subject: Re: Question for potential python development contributions on
> Windows
 
> I am pretty sure that VS2019 output is binary compatible with with output from
> VS2017 and VS2015.  I believe the only issue would be is one were developing a
> patch to a CPython .c file and one used recent C## features not allowed in
> CPython code.
> 
> You could open an issue on bugs.python.org asking that the doc be clarified.

I have received several positive answers on the python-dev list since I posted 
the question here.  The answer is yes, VS2019 and all VS20xx releases since 
VS2015 are correct to use for Windows contributions until MS changes the binary 
C/C++ ABI, currently at level V14x.

The core dev's have indicated that the Python Development Guide documentation 
needs updating to reflect this fact.

Peter

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Alan Gauld via Python-list]

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


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Dan Stromberg]

On Sun, May 23, 2021 at 12:35 PM hw  wrote:

> I don't know about shadowing.  If I have defeated a whole variable type
> by naming a variable like a variable type, I would think it is a bad
> idea for python to allow this without warning.  It seems like a recipie
> for creating chaos.
>

It strikes me as a pretty natural consequence of types being first class
objects in Python.  There's a little unlearning to do if you're coming from
a more traditional language, but it's not difficult once you know how
Python does its thing.

Have you ever tried to put int (not an int, the type int) in a variable in
C?  You can sort of do it with the C PreProcessor, but that's always been a
bit of a kludge.

IOW, in Python everything is an object.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Greg Ewing]

On 25/05/21 9:27 am, Cameron Simpson wrote:

On 24May2021 16:17, hw  wrote:

>

Or it doesn't forget
about the old one and the old one becomes inaccessible (unless you
have a reference to it, if there is such a thing in python).  How do
you call that?


You're conflating values
(objects, such as an int or a string) with variables (which _are_
references in Python,


I think hw might have meant the C++ notion of a reference to
a *variable*. There is no equivalent of that in Python.

Python does have references to *objects*. All objects live on
the heap and are kept alive as long as there is at least one
reference to them.

If you rebind a name, and it held the last reference to an
object, there is no way to get that object back.

On the other hand, if you shadow a name, the original name
still exists, and there is usually some way to get at it,
e.g.

>>> int = 42
>>> int
42
>>> __builtins__.int

>>>

--
Greg

--
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Cameron Simpson]

On 24May2021 16:17, hw  wrote:
>On 5/24/21 11:33 AM, Cameron Simpson wrote:
>>Note that in this function:
>>
>> x = 1
>> y = 2
>>
>> def f(a):
>> x = 3
>> print(x, y)
>>
>>"x" is local, because the function contains an assignment to it. "y"
>>comes from an outer scope (in this case, the global scope) because
>>there's no assignment to it.
>
>Thanks!  That basically works the same as in perl then.

ISTR that Perl needed me to declare locals with my(). Locals are deduced 
from the code in Python.

As Stestagg has mentioned, there are also tools called linters which
warn you about issues like this. Tools like pyflakes, pylint,
pycodestyle all inspect your code for a wide variety of potential errors
and discouraged habits.  Not to mention tools like mypy which do type
validation.
>>>
>>>So you're saying one can't really go without those unless you want to
>>>take the risk?
>>
>>Self restraint and developing good habits does 99% of the work. Linters
>>are great for catching various accidents.
>
>I never needed one before.

I programmed for years in Python (and Perl etc etc) without bothing with 
linters. As I said, 99% of the work can be achieved with a loittle self 
discipline. But linters are good for catching mistakes - computers don't 
get bored. And they can also catch things you weren't considering.

I used to use lint in C and liked the attention to tedious detail.

So for my environment I wrote myself a "lint" script which runs the 
linters I like with the options I like, and linting is now an easy step 
that I perform at my choosing (generally post bug fixing or feature 
implementing).

>>[...]
>>>I'm not saying it shouldn't be allowed to defeat or to re-define stuff,
>>>only that it shouldn't go through quietly.
>>
>>Well, most of us use linters to exhibit that noise, rather than
>>requiring the code to be littered with special directives.
>>
>>I usually code without much linter fuss until I've got the latest batch
>>of work (eg feature or fix) ready, commit the changes, then lint
>>vigorously and commit that polish before merging with the main line of
>>code.
>
>Maybe python requires a different approach than other languages in 
>that it doesn't allow for the overhead that can be used to make things 
>easy to read and without guessing in other languages.  That overhead 
>can be a disadvantage, yet getting to used to not having it could take 
>a while.

The approach isn't required. I find the approach useful to me.

>>Finally, consider this code:
>>
>> num = input("Enter a number: ")
>> num = int(num)
>>
>>input() returns a string, which would need converting to a number before
>>some numeric stuff. Plenty of people write the above. To my mind, this
>>is also a kind of shadowing, and I like this instead:
>>
>> num_s = input("Enter a number: ")
>> num = int(num_s)
>>
>>where the "_s" indicates quietly that this variable holds a string.
>
>Isn't that a kind of overhead python is trying to avoid?

It's a style or work practice of my own choosing. Python itself is happy 
with either code.

>>Is that shadowing to your mind? Or not? If yes, should the language emit
>>noise there, too? Remembering that Python _values_ are strongly typed,
>>though the variables are not (a variable might reference any kind of
>>object, as above).
>
>No, I don't see any shadowing in either example.  In the first one, 
>you (seem to) make sure that you get an integer (not considering what 
>happens when the input is not something that can be cast into an 
>integer) using the same variable by altering its contents.
>
>In the second example, you're using two different variables, trying to 
>cast the first one to an integer while assigning it to a second one 
>which is implicitly declared.
>
>If anything, I could argue that this is convoluted code because you're 
>doing lots of stuff implicitly --- and that could be argued for both 
>examples.  You could make it worse like
>
>  if(int(num = input("foo: ")) == 5):
>pass
>
>involving side effects, but I don't know if python would allow you to 
>do that.  (Not that I would want to do something like this, but it 
>would make sense to me if it could be done ...)
>
>>I wouldn't say that your opinion would be wrong regardless of what side
>>of this question you come down on, but Python's chosen a side: noise for
>>nonsensical things, but not noise for dubious things. But plenty of
>>linters to complain about dubious things.
>
>What does python actually do in the first example?  Does it overshadow 
>a variable or does it change one?  If it overshadows a variable, it 
>would be dubious, if it doesn't, it won't be dubious.

Variables are just names which reference objects. The first example 
causes "num" to reference the string returned by input(), then it causes 
"num" to reference the int returned by int().

If you think of them like C pointers the analogy works well. They're not 
pointers (i.e. they're not memory addresse

Re: Question for potential python development contributions on Windows

[Terry Reedy]

On 5/23/2021 10:05 PM, Terry Reedy wrote:

On 5/23/2021 12:20 PM, pjfarl...@earthlink.net wrote:
I asked this question on python-dev last week but did not get an 
answer.  If

anyone here know the answer I would appreciate it.

The Python Developers Guide specifically states to get VS2017 for 
developing

or enhancing python on a Windows system.

Is it still correct to specifically use VS2017 , or is VS2019 also
acceptable?


pjfarley just got answers on pydev.  For anyone else, they are no, not 
only VS2017, and yes, VS2019 is fine.  The same will be true of a 
possible VS2021 as long as the compiler version remain 14.something.


--
Terry Jan Reedy


--
https://mail.python.org/mailman/listinfo/python-list

Re: f-strings and internationalisation.

[Barry Scott]

> On 24 May 2021, at 19:30, Antoon Pardon  wrote:
> 
> I have now come across several occasion where an author advice the use
> of f-strings above the %-formatting and the format method. However it
> seems these authors were only thinking about rather straight forward
> english communication.
> 
> So what if you want your application to work with multiple languages.
> Can that be done with f-strings?

No it cannot be done. This is because a translation can reorder
the parts of the string is drastic ways that f'strings' does not allow for.

You need to use this style:

_('This %(arg1)s and %(arg2)s') % {'arg1': value_arg1, 'arg2': 
value_arg2}

or
_('This {arg1} and {arg2}').format(arg1=value_args, arg2=values_arg2)

A translator would be free to swap arg1 and arg2 order in a translation.

See https://docs.python.org/3/library/gettext.html for more details.
And https://www.mattlayman.com/blog/2015/i18n/ looks useful as well.

Then you can use use the I18N gettext tools to make a .pot and .po files.

Barry
 


> 
> -- 
> Antoon Pardon.
> -- 
> https://mail.python.org/mailman/listinfo/python-list
> 

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Grant Edwards]

On 2021-05-24, Dennis Lee Bieber  wrote:

>   Attempting to rebind a keyword in Python will produce an error...
>
 if = 1.234
> Traceback (  File "", line 1
> if = 1.234
>^
> SyntaxError: invalid syntax

I must admit it might be nice if the compiler told you _why_ the
syntax is invalid (e.g. "expected conditional expression while parsing
'if' statement").

It's usually fairly obvious, but...

--
Grant



-- 
https://mail.python.org/mailman/listinfo/python-list

f-strings and internationalisation.

[Antoon Pardon]

I have now come across several occasion where an author advice the use
of f-strings above the %-formatting and the format method. However it
seems these authors were only thinking about rather straight forward
english communication.

So what if you want your application to work with multiple languages.
Can that be done with f-strings?

-- 
Antoon Pardon.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Alan Gauld via Python-list]

On 24/05/2021 07:21, hw wrote:

>> Inside the function f() the name 'x" shadows the global "x"; references
>> to "x" are to the function's local vairable. Which is very desireable.
> 
> If it works that way, I would consider it an entirely different 
> variable.  

Remember that in Python variables are just names.
They are literally keys to a dictionary and the value that is
associated with the name can change. It may be a literal value,
a function or a class or a type.

Names can be anything that is not a reserved word. (Provided
they keep within the naming grammar rules)

Also, unlike some other languages, type names are not reserved
words.

 by naming a variable like a variable type, I would think it is a bad
 idea for python to allow this without warning.

It does warn you, that's what the message it printed said:

 print(isinstance(int, float))
TypeError: isinstance() arg 2 must be a type or tuple of types


There is only on possible cause for that error. float is not
a type or a tuple of types. Therefore you must have changed
it somewhere.

Since this is the first place in the program that python can
identify an error, this is where the message gets printed.

You are working in a dynamic language that allows you to do
whatever you want to do.

-- 
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


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Use Chrome's / Firefox's dev-tools in python

[max pothier]

Found this:
https://pastebin.com/fvLkSJRp
with use-select tags.
I'll try to use selenium and select the page.
But using the JSON packet that's sent will still be more practical.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Michael F. Stemper]

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.
--
https://mail.python.org/mailman/listinfo/python-list

Re: Use Chrome's / Firefox's dev-tools in python

[max pothier]

Ok,
So here's a screenshot:
https://ibb.co/2dtGr3c
1 is the website's scrollbar and 2 is Firefox's scrollbar.
Seems like it uses a strange embed thing.
The packet follows:
https://pastebin.com/2qEkhZMN
@Martin Di Paola: I sent you the pastebin password per email so that you're the 
only one who can access it, I just don't want anyone who passes by to be able 
to see my quotes...
What is that CSS tag? I could try to disable it in the inspector.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Rob Cliffe via Python-list]

Please don't be put off by your experience so far.  Everyone stumbles 
along the way and runs into "gotchas" when learning a new language.  
Python is a fantastic language for development.  One of my early 
"epiphany" moments was experimenting with different algorithms to try to 
find the right one for a tricky task.  If I remember rightly it took me 
about 2 weeks, on and off.  I could never have done it in any flavour of 
C in 6 months, or at all for that matter.  Python's built-in lists, 
dictionaries and memory management saved so much donkey work and made it 
so easy to throw ideas around!

Regards
Rob Cliffe

--
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Michael Torrie]

On 5/24/21 8:42 AM, Schachner, Joseph wrote:
> OMG that is awful abuse of Python!  You have overloaded two Python
> keywords by making variables of that name.

Nitpick. hw did not overload keywords. Python does not allow keywords to
be overloaded.  Instead hw overwrote type names.  Upon learning that
type names are not keywords and can be overwritten, hw aw asked a
legitimate question: why does Python allow you to do that?  I don't
believe the OP found the answer acceptable, though.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Rob Cliffe via Python-list]

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
--
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Michael Torrie]

On 5/24/21 8:37 AM, Chris Angelico wrote:
> We're talking about many different things. 

Indeed.

The context of that original question about whether this was shadowing
or not seemed to be specifically about the num=input(); num=int(num)
example that Cameron Simpson posted.  Although hw was not clear on that.
-- 
https://mail.python.org/mailman/listinfo/python-list

RE: learning python ...

[Schachner, Joseph]

OMG that is awful abuse of Python!  You have overloaded two Python keywords by 
making variables of that name.  As a result, float is no longer a type name, it 
is a variable name that refers to the value 6.67 !

Type(int) is int; type(float) is float, but isinstance(int,float) doesn't work 
because float is not a type in your script because you assigned float=6.67 and 
the local variable dictionary is searched first!

To fix this, make your variable name myfloat.   Change it wherever the variable 
name is wanted.  In particular, the last line should be 
print(isinstance(myfloat, float)).  The first argument is the variable, the 
second should be type name.

--- Joseph S.



Teledyne Confidential; Commercially Sensitive Business Data

-Original Message-
From: hw  
Sent: Sunday, May 23, 2021 3:34 PM
To: python-list@python.org
Subject: Re: learning python ...

On 5/23/21 7:28 PM, Peter Otten wrote:
> On 23/05/2021 06:37, hw wrote:
>>
>> Hi,
>>
>> I'm starting to learn python and have made a little example program 
>> following a tutorial[1] I'm attaching.
>>
>> Running it, I'm getting:
>>
>>
>> Traceback (most recent call last):
>>    File "[...]/hworld.py", line 18, in 
>>  print(isinstance(int, float))
>> TypeError: isinstance() arg 2 must be a type or tuple of types
>>
>>
>> I would understand to get an error message in line 5 but not in 18.  
>> Is this a bug or a feature?
> 
> It is a bug in your code (which you don't provide). Did you assign 
> some value to float, e. g.:
> 
>  >>> float = 42.0
>  >>> isinstance(int, float)
> Traceback (most recent call last):
>    File "", line 1, in 
>      isinstance(int, float)
> TypeError: isinstance() arg 2 must be a type or tuple of types
> 
> If you do not shadow the built-in you should get
> 
>  >>> isinstance(int, float)
> False
> 

Apparently the attachment was stripped from my message.  I'll put a smaller 
version directly into this message instead of an attachment:


#!/usr/bin/python

print("world!")

int = 17
print("world", int)

float = 6.670
print("world", float)

foo = 0
print(type(int))
print(type(float))
print(type(foo))

print(isinstance(foo, str))
print(isinstance(int, float))
print(isinstance(float, float))


I don't know about shadowing.  If I have defeated a whole variable type 
by naming a variable like a variable type, I would think it is a bad 
idea for python to allow this without warning.  It seems like a recipie 
for creating chaos.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Michael Torrie]

On 5/24/21 8:21 AM, Michael Torrie wrote:
> Given your posts thus far, hw, I don't think Python is a good fit for
> you. You're better off learning a language that more closely aligns with
> the statically-typed languages you already know.

That was unnecessarily harsh; my apologies.  I can see now that you
might be comparing some features to Perl, which is a more dynamic
language.  I see in your recent posts that you are trying to understand
how Python works, and that is good.  Hopefully you'll find Python a
dynamic and useful tool.  If not, that's perfectly okay. Use the right
tool for the job.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Chris Angelico]

On Tue, May 25, 2021 at 12:31 AM Michael Torrie  wrote:
>
> On 5/24/21 8:24 AM, Chris Angelico wrote:
> > On Tue, May 25, 2021 at 12:18 AM hw  wrote:
> >> There are more alternatives:  Python might create a new variable with
> >> the same name and forget about the old one.  Or it doesn't forget about
> >> the old one and the old one becomes inaccessible (unless you have a
> >> reference to it, if there is such a thing in python).  How do you call 
> >> that?
> >
> > It's the latter option: create a new variable, and the old one becomes
> > inaccessible. That's called "shadowing". It's how scoping works in
> > most languages (called "lexical scope").
>
> Is it really shadowing, though?  The old one is not only inaccessible,
> it's possibly reaped by the garbage collector, no?  Both nums are in the
> same scope so the one overwrote the other in the name table.  Or am I
> missing something.
>

We're talking about many different things. If it's simply "num = ..."
followed by "num = ...", then it's not a new variable or anything,
it's simply rebinding the same name. But when you do "int = ...", it's
shadowing the builtin name.

But the rules are very close to the same in most modern high level
languages. There are some small differences (eg Python doesn't have
sub-function scope, but C-like languages can do that; JavaScript kinda
does and kinda doesn't, because JavaScript), but by and large, the
same rules apply.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Michael Torrie]

On 5/24/21 8:17 AM, hw wrote:
> What does python actually do in the first example?  Does it overshadow a 
> variable or does it change one?  If it overshadows a variable, it would 
> be dubious, if it doesn't, it won't be dubious.

Are you referring to this?

  num = input("Enter a number: ")
  num = int(num)

No it is not "overshadowing" a variable.  You cannot get back to the
original string value for num.

> There are more alternatives:  Python might create a new variable with 
> the same name and forget about the old one.  Or it doesn't forget about 
> the old one and the old one becomes inaccessible (unless you have a 
> reference to it, if there is such a thing in python).  How do you call that?

Python variables are not memory boxes like in a compiled language.  They
are names bound to objects, as Mr Simpson alluded to.  So in the first
line, the name num is bound to a string.  In the second line, the name
is re-bound to an int object.  Furthermore, if num had come from the
global name scope, either of these lines would create a local name num
that does shadow the name from the global scope.

Hope that helps.


-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Michael Torrie]

On 5/24/21 8:24 AM, Chris Angelico wrote:
> On Tue, May 25, 2021 at 12:18 AM hw  wrote:
>> There are more alternatives:  Python might create a new variable with
>> the same name and forget about the old one.  Or it doesn't forget about
>> the old one and the old one becomes inaccessible (unless you have a
>> reference to it, if there is such a thing in python).  How do you call that?
> 
> It's the latter option: create a new variable, and the old one becomes
> inaccessible. That's called "shadowing". It's how scoping works in
> most languages (called "lexical scope").

Is it really shadowing, though?  The old one is not only inaccessible,
it's possibly reaped by the garbage collector, no?  Both nums are in the
same scope so the one overwrote the other in the name table.  Or am I
missing something.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Chris Angelico]

On Tue, May 25, 2021 at 12:18 AM hw  wrote:
> There are more alternatives:  Python might create a new variable with
> the same name and forget about the old one.  Or it doesn't forget about
> the old one and the old one becomes inaccessible (unless you have a
> reference to it, if there is such a thing in python).  How do you call that?

It's the latter option: create a new variable, and the old one becomes
inaccessible. That's called "shadowing". It's how scoping works in
most languages (called "lexical scope").

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Michael Torrie]

On 5/24/21 7:34 AM, hw wrote:
> Perhaps you can't see how both examples are different because you're 
> looking at things from a python perspective.

Sorry but they aren't all that different.  In both cases you're
shadowing printf.  The difference is that C is a statically-typed,
compiled language, so the compiler complains that an int is not
callable, whereas  Python is a dynamic language so lookups are done at
run time, not compile time.

I don't know your background, but it sounds like you've not had a lot of
experience with dynamic languages. Certainly you have never used a
language like Scheme or LISP!  Or Smalltalk!

What is your purpose here?  Why are you learning Python when it's
apparently that you have very little desire to understand the hows and
whys of Python and its idioms and paradigms, and to find its strengths.
 You've encountered some things that to you are unexpected.  That
happens when learning any language.

Unfortunately from time to time we see someone come to the list
apparently trying to do battle with the language; rather than learn how
to work with the language they try to twist python to their preconceived
notions of what a proper language should be, whether that's by getting
hung up on a specific criticism of the grammar, or by trying to program
Python in another language (often Java).  Such encounters always lead to
frustration and such posters most often walkaway disillusioned and even
bitter.  It's a bit of an odd thing to watch, and always sad because the
outcome simply hinges on the attitude of the person learning the
language. Someone that works with the language finds it's a very
expressive and powerful tool.

Given your posts thus far, hw, I don't think Python is a good fit for
you. You're better off learning a language that more closely aligns with
the statically-typed languages you already know.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[hw]

On 5/24/21 11:33 AM, Cameron Simpson wrote:

On 24May2021 08:21, hw  wrote:

On 5/24/21 12:03 AM, Cameron Simpson wrote:

On 23May2021 21:02, Stestagg  wrote:

On Sun, 23 May 2021 at 20:37, hw  wrote:

I don't know about shadowing.


Shadowing is effectively saying “within this bit of code, (scope) I’m going
to use an already-used name for my own value”


An example might make this clearer:

 x = 1 # global variable

 def f(a):
 x = a * 2
 return x

Inside the function f() the name 'x" shadows the global "x"; references
to "x" are to the function's local vairable. Which is very desireable.


If it works that way, I would consider it an entirely different
variable.  Is there a way to access the global x from within a
function without transferring it through parameters of the function?
Than can also sometimes be useful.


Sure. You can declare a name like this:

 def f(a):
 global x  # find x in the global namespace (the module)
 x = a * 2
 return x

This is pretty rare and usually discouraged. Of there are times when it
is useful.

Note that in this function:

 x = 1
 y = 2

 def f(a):
 x = 3
 print(x, y)

"x" is local, because the function contains an assignment to it. "y"
comes from an outer scope (in this case, the global scope) because
there's no assignment to it.


Thanks!  That basically works the same as in perl then.


As Stestagg has mentioned, there are also tools called linters which
warn you about issues like this. Tools like pyflakes, pylint,
pycodestyle all inspect your code for a wide variety of potential errors
and discouraged habits.  Not to mention tools like mypy which do type
validation.


So you're saying one can't really go without those unless you want to
take the risk?


Self restraint and developing good habits does 99% of the work. Linters
are great for catching various accidents.


I never needed one before.


[...]

I'm not saying it shouldn't be allowed to defeat or to re-define stuff,
only that it shouldn't go through quietly.


Well, most of us use linters to exhibit that noise, rather than
requiring the code to be littered with special directives.

I usually code without much linter fuss until I've got the latest batch
of work (eg feature or fix) ready, commit the changes, then lint
vigorously and commit that polish before merging with the main line of
code.


Maybe python requires a different approach than other languages in that 
it doesn't allow for the overhead that can be used to make things easy 
to read and without guessing in other languages.  That overhead can be a 
disadvantage, yet getting to used to not having it could take a while.



Finally, consider this code:

 num = input("Enter a number: ")
 num = int(num)

input() returns a string, which would need converting to a number before
some numeric stuff. Plenty of people write the above. To my mind, this
is also a kind of shadowing, and I like this instead:

 num_s = input("Enter a number: ")
 num = int(num_s)

where the "_s" indicates quietly that this variable holds a string.


Isn't that a kind of overhead python is trying to avoid?


Is that shadowing to your mind? Or not? If yes, should the language emit
noise there, too? Remembering that Python _values_ are strongly typed,
though the variables are not (a variable might reference any kind of
object, as above).


No, I don't see any shadowing in either example.  In the first one, you 
(seem to) make sure that you get an integer (not considering what 
happens when the input is not something that can be cast into an 
integer) using the same variable by altering its contents.


In the second example, you're using two different variables, trying to 
cast the first one to an integer while assigning it to a second one 
which is implicitly declared.


If anything, I could argue that this is convoluted code because you're 
doing lots of stuff implicitly --- and that could be argued for both 
examples.  You could make it worse like


  if(int(num = input("foo: ")) == 5):
pass

involving side effects, but I don't know if python would allow you to do 
that.  (Not that I would want to do something like this, but it would 
make sense to me if it could be done ...)



I wouldn't say that your opinion would be wrong regardless of what side
of this question you come down on, but Python's chosen a side: noise for
nonsensical things, but not noise for dubious things. But plenty of
linters to complain about dubious things.


What does python actually do in the first example?  Does it overshadow a 
variable or does it change one?  If it overshadows a variable, it would 
be dubious, if it doesn't, it won't be dubious.


There are more alternatives:  Python might create a new variable with 
the same name and forget about the old one.  Or it doesn't forget about 
the old one and the old one becomes inaccessible (unless you have a 
reference to it, if there is such a thing in python)

Re: learning python ...

[Chris Angelico]

On Mon, May 24, 2021 at 11:35 PM hw  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.

> 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.

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.

> 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".

> 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. 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__


>>> 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.

> 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.

> The example you want is probably this one:
>
>
> #include 
>
> 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.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[hw]

On 5/24/21 9:52 AM, Chris Angelico wrote:

On Mon, May 24, 2021 at 3:25 PM hw  wrote:


On 5/23/21 10:02 PM, Stestagg wrote:



On Sun, 23 May 2021 at 20:37, hw mailto:h...@adminart.net>> wrote:

 On 5/23/21 7:28 PM, Peter Otten wrote:
  > On 23/05/2021 06:37, hw wrote:
  >>
  >> Hi,
  >>
  >> I'm starting to learn python and have made a little example program
  >> following a tutorial[1] I'm attaching.
  >>
  >> Running it, I'm getting:
  >>
  >>
  >> Traceback (most recent call last):
  >>File "[...]/hworld.py", line 18, in 
  >>  print(isinstance(int, float))
  >> TypeError: isinstance() arg 2 must be a type or tuple of types
  >>
  >>
  >> I would understand to get an error message in line 5 but not in 18.
  >> Is this a bug or a feature?
  >
  > It is a bug in your code (which you don't provide). Did you
 assign some
  > value to float, e. g.:
  >
  >  >>> float = 42.0
  >  >>> isinstance(int, float)
  > Traceback (most recent call last):
  >File "", line 1, in 
  >  isinstance(int, float)
  > TypeError: isinstance() arg 2 must be a type or tuple of types
  >
  > If you do not shadow the built-in you should get
  >
  >  >>> isinstance(int, float)
  > False
  >

 Apparently the attachment was stripped from my message.  I'll put a
 smaller version directly into this message instead of an attachment:


 #!/usr/bin/python

 print("world!")

 int = 17
 print("world", int)

 float = 6.670
 print("world", float)

 foo = 0
 print(type(int))
 print(type(float))
 print(type(foo))

 print(isinstance(foo, str))
 print(isinstance(int, float))
 print(isinstance(float, float))


 I don't know about shadowing.


Shadowing is effectively saying “within this bit of code, (scope) I’m
going to use an already-used name for my own value”


That should give at least a warning.


No, it shouldn't, because it's a deliberate feature. The entire point
of scoping rules - whether you're in C, Python, REXX, or any other
language - is to *allow* you to use a name for what you intend it to
be.

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 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.


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.


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?


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 example you want is probably this one:


#include 

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.

--
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Cameron Simpson]

On 24May2021 08:21, hw  wrote:
>On 5/24/21 12:03 AM, Cameron Simpson wrote:
>>On 23May2021 21:02, Stestagg  wrote:
>>>On Sun, 23 May 2021 at 20:37, hw  wrote:
I don't know about shadowing.
>>>
>>>Shadowing is effectively saying “within this bit of code, (scope) I’m going
>>>to use an already-used name for my own value”
>>
>>An example might make this clearer:
>>
>> x = 1 # global variable
>>
>> def f(a):
>> x = a * 2
>> return x
>>
>>Inside the function f() the name 'x" shadows the global "x"; references
>>to "x" are to the function's local vairable. Which is very desireable.
>
>If it works that way, I would consider it an entirely different 
>variable.  Is there a way to access the global x from within a 
>function without transferring it through parameters of the function?  
>Than can also sometimes be useful.

Sure. You can declare a name like this:

def f(a):
global x  # find x in the global namespace (the module)
x = a * 2
return x

This is pretty rare and usually discouraged. Of there are times when it 
is useful.

Note that in this function:

x = 1
y = 2

def f(a):
x = 3
print(x, y)

"x" is local, because the function contains an assignment to it. "y" 
comes from an outer scope (in this case, the global scope) because 
there's no assignment to it.

>>As Stestagg has mentioned, there are also tools called linters which
>>warn you about issues like this. Tools like pyflakes, pylint,
>>pycodestyle all inspect your code for a wide variety of potential errors
>>and discouraged habits.  Not to mention tools like mypy which do type
>>validation.
>
>So you're saying one can't really go without those unless you want to 
>take the risk?

Self restraint and developing good habits does 99% of the work. Linters 
are great for catching various accidents.

[...]
>I'm not saying it shouldn't be allowed to defeat or to re-define stuff, 
>only that it shouldn't go through quietly.

Well, most of us use linters to exhibit that noise, rather than 
requiring the code to be littered with special directives.

I usually code without much linter fuss until I've got the latest batch 
of work (eg feature or fix) ready, commit the changes, then lint 
vigorously and commit that polish before merging with the main line of 
code.

Finally, consider this code:

num = input("Enter a number: ")
num = int(num)

input() returns a string, which would need converting to a number before 
some numeric stuff. Plenty of people write the above. To my mind, this 
is also a kind of shadowing, and I like this instead:

num_s = input("Enter a number: ")
num = int(num_s)

where the "_s" indicates quietly that this variable holds a string.

Is that shadowing to your mind? Or not? If yes, should the language emit 
noise there, too? Remembering that Python _values_ are strongly typed, 
though the variables are not (a variable might reference any kind of 
object, as above).

I wouldn't say that your opinion would be wrong regardless of what side 
of this question you come down on, but Python's chosen a side: noise for 
nonsensical things, but not noise for dubious things. But plenty of 
linters to complain about dubious things.

Cheers,
Cameron Simpson 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Peter J. Holzer]

On 2021-05-24 07:20:39 +0200, hw wrote:
> python is too unfinished to be used.

You have to realize that different programming languages have different
goals and develop in different directions. Python is not an "unfinished
Java" (and neither is Java an "unfinished Python"). The scoping and
binding rules of Python were a conscious decision, not a quick hack
intended to be fixed later.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Chris Angelico]

On Mon, May 24, 2021 at 3:25 PM hw  wrote:
>
> On 5/23/21 10:02 PM, Stestagg wrote:
> >
> >
> > On Sun, 23 May 2021 at 20:37, hw  > > wrote:
> >
> > On 5/23/21 7:28 PM, Peter Otten wrote:
> >  > On 23/05/2021 06:37, hw wrote:
> >  >>
> >  >> Hi,
> >  >>
> >  >> I'm starting to learn python and have made a little example program
> >  >> following a tutorial[1] I'm attaching.
> >  >>
> >  >> Running it, I'm getting:
> >  >>
> >  >>
> >  >> Traceback (most recent call last):
> >  >>File "[...]/hworld.py", line 18, in 
> >  >>  print(isinstance(int, float))
> >  >> TypeError: isinstance() arg 2 must be a type or tuple of types
> >  >>
> >  >>
> >  >> I would understand to get an error message in line 5 but not in 18.
> >  >> Is this a bug or a feature?
> >  >
> >  > It is a bug in your code (which you don't provide). Did you
> > assign some
> >  > value to float, e. g.:
> >  >
> >  >  >>> float = 42.0
> >  >  >>> isinstance(int, float)
> >  > Traceback (most recent call last):
> >  >File "", line 1, in 
> >  >  isinstance(int, float)
> >  > TypeError: isinstance() arg 2 must be a type or tuple of types
> >  >
> >  > If you do not shadow the built-in you should get
> >  >
> >  >  >>> isinstance(int, float)
> >  > False
> >  >
> >
> > Apparently the attachment was stripped from my message.  I'll put a
> > smaller version directly into this message instead of an attachment:
> >
> >
> > #!/usr/bin/python
> >
> > print("world!")
> >
> > int = 17
> > print("world", int)
> >
> > float = 6.670
> > print("world", float)
> >
> > foo = 0
> > print(type(int))
> > print(type(float))
> > print(type(foo))
> >
> > print(isinstance(foo, str))
> > print(isinstance(int, float))
> > print(isinstance(float, float))
> >
> >
> > I don't know about shadowing.
> >
> >
> > Shadowing is effectively saying “within this bit of code, (scope) I’m
> > going to use an already-used name for my own value”
>
> That should give at least a warning.

No, it shouldn't, because it's a deliberate feature. The entire point
of scoping rules - whether you're in C, Python, REXX, or any other
language - is to *allow* you to use a name for what you intend it to
be.

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.

> It seems dangerous and seems to show that python is too unfinished to be
> used.  For all I know, it makes it easy to, for example, drop a whole
> table in a database because something was shadowed without warning.

No, it doesn't. It simply allows you to use a name the way you choose
to. And if you want to learn how to use Python, stop insulting it -
calling it "too unfinished to be used" is a tad unfair to a language
that has been used in production code for three decades. All you're
really doing is proving the Blub Paradox - look it up.

> I can imagine that there can be all kinds of situations in which
> something like that happens, and you can spend hours or days trying to
> figure out what's wrong and may never find it.

What happens more often with me is that I'm typing out a perfectly
reasonable section of code, and my editor highlights some word, and I
realize that I'm shadowing some obscure standard library name or
something. (And then I usually just carry on, because there's no way
that it's going to matter.)

> > One thing to learn to
> > look out for is if you assign to a name, then use that name on a
> > different context, expecting it to be different, then that’s not likely
> > to work as you expect.
>
> Then why doesn't give it at least a warning?

Because there's no difference between shadowing a standard library
name and shadowing your own name. And there's absolutely nothing wrong
with that.

> There is even no indication from the output from the program before it
> aborts with an error message that something might be wrong:  For
> 'type(float)', it prints "" just like it does for int.
> How is anyone supposed to debug stuff like that?

You debug it by noticing that you changed the value of "float" between
where you printed it and where you tried to call it. Or changed the
value of "type", either way. You debug it by printing things out
*right where the exception is happening*. You debug it, especially, by
*reading the exception traceback* to figure out where your code isn't
doing the right thing.

This is what it is to be a programmer.

> Why doesn't print(type(float)) give an error message after the variable
> type was already defeated (or prints something else)?  What is it
> actually printing?

It's calling type, whatever that is, with the value of float, whatever
that is, and then printing out the result. This