Re: Question about learning Python

[Chris Angelico]

On Sat, 10 Sept 2022 at 06:45, Dennis Lee Bieber  wrote:
>
> On Thu, 8 Sep 2022 07:42:19 +1200, dn 
> declaimed the following:
>
> >TSRs? Now that was an ugly period of history! (trying to make a
> >single-process operating system do multi-processing - only to find that
> >many program[me]s assumed they had full use and undisputed control of
> >the computer. Happy days...)
> >
>
> I laughed when M$ MSDOS (2?) introduced TSRs... My TRS-80 running
> L(S)DOS had similar things at least a year earlier. And these were
> /run-time/ loadable. They called them "filters" (and device drivers were
> also an option). Key-click was one such -- though it also showed some
> quirks (like... If the processor was really busy, the key-board driver
> would buffer key-strokes, but the filter activated when an application
> /read/ the key-board). Filter to control printer formatting, a JobLog
> filter, Key-Stroke Multiply filter (I never used it, but it apparently uses
> a table of special keys and expands them to longer strings). Commands to
> load device drivers (or remove them!). Could even change the number of
> cylinders for a floppy drive -- My drives were "loose" enough to allow my
> to add 2 cylinders.
>

To be fair on MS-DOS, you didn't *have* to use a TSR to hook
interrupts, and the same idea of those filters would work (just hook
the keyboard interrupt in a cooperative way; last installed is first
executed). But the OS offered only one option for a program to run and
put itself somewhere: "terminate process and increase the base segment
address for subsequent processes", which would allow you to leave any
amount of memory (on a sixteen-byte boundary) active.

There's no reason that filters couldn't have been written that blit
themselves into some other part of memory, point some interrupt
vectors there, and then fully terminate. Sure, the OS wouldn't have
offered any protection, but the OS didn't offer any actual protection
anyway. All we'd need is a spare slab of memory for things to put
their code into, one which everyone could allocate and deallocate
from. oh. Yeah, like virtual memory.

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

Re: Question about learning Python

[Chris Angelico]

On Sat, 10 Sept 2022 at 06:38, Greg Ewing  wrote:
>
> On 8/09/22 6:57 am, Chris Angelico wrote:
> > Not as detrimental as starting with BASIC, and then moving on to x86
> > assembly language, and trying to massage the two together using CALL
> > ABSOLUTE in order to get mouse input in your GW-BASIC programs.
>
> Or starting with hand-assembled SC/MP machine code and then moving
> on to Applesoft BASIC.
>

I have no idea how we survived.

Though, "survived with our sanity intact" clearly didn't happen, so
perhaps there's that.

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

Re: Question about learning Python

[Dennis Lee Bieber]

On Thu, 8 Sep 2022 07:42:19 +1200, dn 
declaimed the following:

>TSRs? Now that was an ugly period of history! (trying to make a
>single-process operating system do multi-processing - only to find that
>many program[me]s assumed they had full use and undisputed control of
>the computer. Happy days...)
>

I laughed when M$ MSDOS (2?) introduced TSRs... My TRS-80 running
L(S)DOS had similar things at least a year earlier. And these were
/run-time/ loadable. They called them "filters" (and device drivers were
also an option). Key-click was one such -- though it also showed some
quirks (like... If the processor was really busy, the key-board driver
would buffer key-strokes, but the filter activated when an application
/read/ the key-board). Filter to control printer formatting, a JobLog
filter, Key-Stroke Multiply filter (I never used it, but it apparently uses
a table of special keys and expands them to longer strings). Commands to
load device drivers (or remove them!). Could even change the number of
cylinders for a floppy drive -- My drives were "loose" enough to allow my
to add 2 cylinders.

>On the other hand, one can start too 'high' or too 'modern'. Like the
>person enthusing about MSFT's and AWS' programming AIs, thinking that
>such tools will replace programmers (one of the aims of the COBOL
>language back in the 1960s). His short-form description spoke volumes:
>'it saves anyone from having to look-up Stack Overflow any more' - a
>'blind' cut-and-paste prospect that saves the 'author' from the
>difficulties of 'learning stuff'; until it is time to, um, learn-stuff -
>to know why one needs to learn-stuff BEFORE taking from SO/AI.

I once worked with someone whose idea of programming was to find
examples of working code, and cut snippets to make an application. We
needed to control four devices via GPIB... She wrote four short programs
and a DCL script to run them in sequence.

Problem: each program had to issue a GPIB initialization command before
it could continue to talk to any device. But each initialization command
would UNDO any configuration the previous program had set up! We discovered
THAT when TDY to the remote site (and she'd already returned home). I had
to debug the situation, and rewrite the four programs into a single
consolidate program over a weekend (and I'd never worked with GPIB before
this -- my task was the post processing of the data that was collected
after the GPIB chain had been set up for data collection).

I think I'm not giving away any secrets these days, but this was a
Quick Response Contract for a proof of concept -- that a geo-bird could
catch over the horizon GPS signals, and thereby improve the satellite
tracking data for ephemeris generation. Had to be over-the-horizon as
geo-birds are above GPS, and GPS aims signals down to earth. We had to
catch side-lobes as GPS birds were high enough to avoid
ionosphere/troposphere effects.



-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about learning Python

[Meredith Montgomery]

 writes:

> Maybe we should ask WHY the person asking the question about how to learn a
> computer language called Python is pairing it with the idea of whether to
> also learn C.

Excellent point!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about learning Python

[Greg Ewing]

On 8/09/22 6:57 am, Chris Angelico wrote:

Not as detrimental as starting with BASIC, and then moving on to x86
assembly language, and trying to massage the two together using CALL
ABSOLUTE in order to get mouse input in your GW-BASIC programs.


Or starting with hand-assembled SC/MP machine code and then moving
on to Applesoft BASIC.

--
Greg

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

Question about learning Python

[Fulian Wang]

Python is an appropriate computer language for kids and teenagers. A very good 
book for beginners: Invent Your Own computer games with Python
Author: Al Sweigart
It's free online, but it's worth to have one.

Get Outlook for iOS<https://aka.ms/o0ukef>

From: Python-list  on 
behalf of avi.e.gr...@gmail.com 
Sent: Wednesday, September 7, 2022 7:32:11 PM
To: python-list@python.org 
Subject: RE: Question about learning Python

Chris,

I started with BASIC in high school and kept shifting my focus from one
computer language to another long before I even looked at Python.

Arguably each language had a REASON for existing so it supported some ideas
or paradigms or ways of looking at things. Many at first were rather focused
on doing one or a few things well, and others not so well or not at all. No
need to rehash it.

In a sense, many modern languages can be viewed as containing multiple
overlapping modules which collectively do all kinds of things in many ways
and can do whatever many earlier initial releases of earlier languages did,
sometimes better but also sometimes slower. If you look at Python as a base
and added modules, it can do all the mathematical things of say FORTRAN,
manipulate text and produce reports and on and on. But it also can NOT do
things done in basic, or at least not easily, like subroutines and goto's
that are associated with a more primitive way to solve problems.

Is there any purpose in teaching new students how to structure your code so
that you use such methods? Well, maybe. I mean we have all kinds of slightly
hidden ways to do a GOTO in some languages such as breaking out of a nested
loop. Underneath it all, an IF/THEN/ELSE type of statement has regions you
jump between. But arguably it is helpful to see operations on a higher level
and leave the details of how it is accomplished in well tested code within
the interpreter or compiler.

C was designed on purpose to do some things that a language like PASCAL was
designed not to allow or make easy. Both started off though as fairly simple
languages that did things somewhat linearly. You can obviously emulate many
things using a simplified subset of Python that would allow programs in
those languages to be done. If that is all you want to learn, fine. But if
your goal is to make use of OO and functional programming and other
paradigms supported, ...

As I posted elsewhere, I ask why the questioner specifically mentioned C. I
also use R and there too, C is only needed if you want to speed up some
function by writing parts in their version of C or C++. The fact that many
interpreters are written (or sometimes were written) in C is not really
relevant.


-Original Message-
From: Python-list  On
Behalf Of Chris Angelico
Sent: Wednesday, September 7, 2022 2:58 PM
To: python-list@python.org
Subject: Re: Question about learning Python

On Thu, 8 Sept 2022 at 04:54, Grant Edwards 
wrote:
>
> On 2022-09-07, Chris Angelico  wrote:
> > On Thu, 8 Sept 2022 at 01:50, Maruful Islam 
wrote:
> >>
> >> I want to start learning python. I have a question about learning
python.
> >>
> >> Is learning C essential or not for learning python?
> >
> > Absolutely not essential. In fact, I would strongly recommend
> > learning Python before ever picking up C, as it's much easier to
> > mess around in Python.
>
> If you're a beginning programmer, then IMO learning C first is
> probably detrimental. C has quite a few quirks and pitfalls that will
> a) frustrate you and waste time, and b) influence your way of thinking
> about programs in a way that will be unhelpful for higher level
> languages.

Not as detrimental as starting with BASIC, and then moving on to x86
assembly language, and trying to massage the two together using CALL
ABSOLUTE in order to get mouse input in your GW-BASIC programs.

Don't be me, folks.

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

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

RE: Question about learning Python

[avi.e.gross]

Chris,

I started with BASIC in high school and kept shifting my focus from one
computer language to another long before I even looked at Python. 

Arguably each language had a REASON for existing so it supported some ideas
or paradigms or ways of looking at things. Many at first were rather focused
on doing one or a few things well, and others not so well or not at all. No
need to rehash it.

In a sense, many modern languages can be viewed as containing multiple
overlapping modules which collectively do all kinds of things in many ways
and can do whatever many earlier initial releases of earlier languages did,
sometimes better but also sometimes slower. If you look at Python as a base
and added modules, it can do all the mathematical things of say FORTRAN,
manipulate text and produce reports and on and on. But it also can NOT do
things done in basic, or at least not easily, like subroutines and goto's
that are associated with a more primitive way to solve problems. 

Is there any purpose in teaching new students how to structure your code so
that you use such methods? Well, maybe. I mean we have all kinds of slightly
hidden ways to do a GOTO in some languages such as breaking out of a nested
loop. Underneath it all, an IF/THEN/ELSE type of statement has regions you
jump between. But arguably it is helpful to see operations on a higher level
and leave the details of how it is accomplished in well tested code within
the interpreter or compiler.

C was designed on purpose to do some things that a language like PASCAL was
designed not to allow or make easy. Both started off though as fairly simple
languages that did things somewhat linearly. You can obviously emulate many
things using a simplified subset of Python that would allow programs in
those languages to be done. If that is all you want to learn, fine. But if
your goal is to make use of OO and functional programming and other
paradigms supported, ...

As I posted elsewhere, I ask why the questioner specifically mentioned C. I
also use R and there too, C is only needed if you want to speed up some
function by writing parts in their version of C or C++. The fact that many
interpreters are written (or sometimes were written) in C is not really
relevant.


-Original Message-
From: Python-list  On
Behalf Of Chris Angelico
Sent: Wednesday, September 7, 2022 2:58 PM
To: python-list@python.org
Subject: Re: Question about learning Python

On Thu, 8 Sept 2022 at 04:54, Grant Edwards 
wrote:
>
> On 2022-09-07, Chris Angelico  wrote:
> > On Thu, 8 Sept 2022 at 01:50, Maruful Islam 
wrote:
> >>
> >> I want to start learning python. I have a question about learning
python.
> >>
> >> Is learning C essential or not for learning python?
> >
> > Absolutely not essential. In fact, I would strongly recommend 
> > learning Python before ever picking up C, as it's much easier to 
> > mess around in Python.
>
> If you're a beginning programmer, then IMO learning C first is 
> probably detrimental. C has quite a few quirks and pitfalls that will
> a) frustrate you and waste time, and b) influence your way of thinking 
> about programs in a way that will be unhelpful for higher level 
> languages.

Not as detrimental as starting with BASIC, and then moving on to x86
assembly language, and trying to massage the two together using CALL
ABSOLUTE in order to get mouse input in your GW-BASIC programs.

Don't be me, folks.

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

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

RE: Question about learning Python

[avi.e.gross]

Maybe we should ask WHY the person asking the question about how to learn a
computer language called Python is pairing it with the idea of whether to
also learn C.

What are they preparing for? Most people using Python have absolutely no
reason to learn C, or C++  or C# or JAVA or one of a bewildering number of
other languages. They may end up using functions that unknown to them have
been partially implemented using libraries created in C or other languages
but so what? They never see that except if they want to look at source code.

So are they looking for a job that will require not just Python but also C?

If anything, it is an impediment for many people to learn two rather
different languages at about the same time as many things are very different
and lessons in one often do not carry over well to the other. As examples, C
uses braces to group things and Python uses indentation and C tends to need
things like data types spelled out and Python mostly does not care what type
it is.

Now if a question is asked about how to learn a relatively few languages
with different paradigms that represent an assortment of ways to think about
and solve problems, sure, C might take a slot. But arguably you may want
something more modern that is somewhat descended from C as a compiled
language.

If your goal is to use Python in ways it is designed to be used, learning C
first may spoil your thinking and you may implement algorithms in Python
that loosely translate the way it is done in C but can be done much nicer
using Python costructs.


-Original Message-
From: Python-list  On
Behalf Of Meredith Montgomery
Sent: Wednesday, September 7, 2022 3:35 PM
To: python-list@python.org
Subject: Re: Question about learning Python

Maruful Islam  writes:

> I want to start learning python. I have a question about learning python. 
>
> Is learning C essential or not for learning python?

Surely not necessary.  There's a generous recent thread about books on
Python.  Have a look at it.
--
https://mail.python.org/mailman/listinfo/python-list

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

Re: Question about learning Python

[Meredith Montgomery]

Maruful Islam  writes:

> I want to start learning python. I have a question about learning python. 
>
> Is learning C essential or not for learning python?

Surely not necessary.  There's a generous recent thread about books on
Python.  Have a look at it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about learning Python

[dn]

On 08/09/2022 07.15, Chris Angelico wrote:
> On Thu, 8 Sept 2022 at 05:09, Grant Edwards  wrote:
>>
>> On 2022-09-07, Chris Angelico  wrote:
>>> On Thu, 8 Sept 2022 at 04:54, Grant Edwards  
>>> wrote:
>>>
 If you're a beginning programmer, then IMO learning C first is
 probably detrimental. [...]
>>>
>>> Not as detrimental as starting with BASIC, and then moving on to x86
>>> assembly language, and trying to massage the two together using CALL
>>> ABSOLUTE in order to get mouse input in your GW-BASIC programs.
>>
>> Ah the "good old days".
>>
> 
> Indeed. The 1990s gave me all manner of skills, including the
> aforementioned mouse control in a BASIC program, writing a
> Terminate-and-Stay-Resident program that hooks an interrupt, tricks
> for *not* writing a TSR and still acting like one, building GUIs using
> pixel precision, building GUIs using pixel precision but fully
> automatically, using HTML tables to create layouts oh, yes, so
> many skills... To anyone suffering from https://xkcd.com/1479/ right
> now, I can assure you, quite a lot of that knowledge DOES eventually
> become obsolete when better methods come along. It just sometimes
> takes a decade or more.
> 
> (And then occasionally it still haunts you. I'm finding table-based
> layouts in a site that I now have to manage. Eventually I'll fix it
> all, eventually)

OP: Python!

Python has become one of the most popular first-languages to use in
universities (etc). On-the-ground this varies by country, even by
province/state. However, starting at a higher-level is recommendable -
and should the learner decide that 'this computer stuff is not for me'
(XKCD not withstanding) then the cost of effort-expended will be less.
Also, there are are plenty of coders 'out there' who don't seem to have
learned, or even need, the detail one acquires using a lower-level
language. (no further comment on that!)


TSRs? Now that was an ugly period of history! (trying to make a
single-process operating system do multi-processing - only to find that
many program[me]s assumed they had full use and undisputed control of
the computer. Happy days...)

History has its value. Talking to a group the other day, showed how
IT-skills from patterns (eg Factory, Strategy, Decorator) and paradigms
(eg Modular Programming, Structured Programming) through to
Architectural Principles (eg SOLID) and project management approaches
(eg Waterfall, Agile, SCRUM) all descend from hard-won knowledge and
sometimes bitter-experience. Chunks of which pre-date Dartmouth BASIC,
PCs, mini-computers, and 'family'/standardised-hardware operating systems!

On the other hand, one can start too 'high' or too 'modern'. Like the
person enthusing about MSFT's and AWS' programming AIs, thinking that
such tools will replace programmers (one of the aims of the COBOL
language back in the 1960s). His short-form description spoke volumes:
'it saves anyone from having to look-up Stack Overflow any more' - a
'blind' cut-and-paste prospect that saves the 'author' from the
difficulties of 'learning stuff'; until it is time to, um, learn-stuff -
to know why one needs to learn-stuff BEFORE taking from SO/AI.

-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Question about learning Python

[Chris Angelico]

On Thu, 8 Sept 2022 at 05:09, Grant Edwards  wrote:
>
> On 2022-09-07, Chris Angelico  wrote:
> > On Thu, 8 Sept 2022 at 04:54, Grant Edwards  
> > wrote:
> >
> >> If you're a beginning programmer, then IMO learning C first is
> >> probably detrimental. [...]
> >
> > Not as detrimental as starting with BASIC, and then moving on to x86
> > assembly language, and trying to massage the two together using CALL
> > ABSOLUTE in order to get mouse input in your GW-BASIC programs.
>
> Ah the "good old days".
>

Indeed. The 1990s gave me all manner of skills, including the
aforementioned mouse control in a BASIC program, writing a
Terminate-and-Stay-Resident program that hooks an interrupt, tricks
for *not* writing a TSR and still acting like one, building GUIs using
pixel precision, building GUIs using pixel precision but fully
automatically, using HTML tables to create layouts oh, yes, so
many skills... To anyone suffering from https://xkcd.com/1479/ right
now, I can assure you, quite a lot of that knowledge DOES eventually
become obsolete when better methods come along. It just sometimes
takes a decade or more.

(And then occasionally it still haunts you. I'm finding table-based
layouts in a site that I now have to manage. Eventually I'll fix it
all, eventually)

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

Re: Question about learning Python

[Grant Edwards]

On 2022-09-07, Chris Angelico  wrote:
> On Thu, 8 Sept 2022 at 04:54, Grant Edwards  wrote:
>
>> If you're a beginning programmer, then IMO learning C first is
>> probably detrimental. [...]
>
> Not as detrimental as starting with BASIC, and then moving on to x86
> assembly language, and trying to massage the two together using CALL
> ABSOLUTE in order to get mouse input in your GW-BASIC programs.

Ah the "good old days".


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

Re: Question about learning Python

[Chris Angelico]

On Thu, 8 Sept 2022 at 04:54, Grant Edwards  wrote:
>
> On 2022-09-07, Chris Angelico  wrote:
> > On Thu, 8 Sept 2022 at 01:50, Maruful Islam  wrote:
> >>
> >> I want to start learning python. I have a question about learning python.
> >>
> >> Is learning C essential or not for learning python?
> >
> > Absolutely not essential. In fact, I would strongly recommend learning
> > Python before ever picking up C, as it's much easier to mess around in
> > Python.
>
> If you're a beginning programmer, then IMO learning C first is
> probably detrimental. C has quite a few quirks and pitfalls that will
> a) frustrate you and waste time, and b) influence your way of thinking
> about programs in a way that will be unhelpful for higher level
> languages.

Not as detrimental as starting with BASIC, and then moving on to x86
assembly language, and trying to massage the two together using CALL
ABSOLUTE in order to get mouse input in your GW-BASIC programs.

Don't be me, folks.

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

Re: Question about learning Python

[Grant Edwards]

On 2022-09-07, Chris Angelico  wrote:
> On Thu, 8 Sept 2022 at 01:50, Maruful Islam  wrote:
>>
>> I want to start learning python. I have a question about learning python.
>>
>> Is learning C essential or not for learning python?
>
> Absolutely not essential. In fact, I would strongly recommend learning
> Python before ever picking up C, as it's much easier to mess around in
> Python.

If you're a beginning programmer, then IMO learning C first is
probably detrimental. C has quite a few quirks and pitfalls that will
a) frustrate you and waste time, and b) influence your way of thinking
about programs in a way that will be unhelpful for higher level
languages.

> Learning C will definitely help you to become a better programmer, but
> you can leave it until later.

Unless it's to work on a real project that's written in C, I'd put C a
fair ways down the list of languages to learn. I'd probably put Python
and then Scheme at the top of the list. Then maybe Smalltalk and
something a bit more functional.

--
Grant

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

Re: Question about learning Python

[Chris Angelico]

On Thu, 8 Sept 2022 at 01:50, Maruful Islam  wrote:
>
> I want to start learning python. I have a question about learning python.
>
> Is learning C essential or not for learning python?

Absolutely not essential. In fact, I would strongly recommend learning
Python before ever picking up C, as it's much easier to mess around in
Python.

Learning C will definitely help you to become a better programmer, but
you can leave it until later.

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

Re: Question about learning Python

[Thomas Passin]

On 9/7/2022 6:28 AM, Maruful Islam wrote:

I want to start learning python. I have a question about learning python.

Is learning C essential or not for learning python?


Not at all.

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

Re: Question about learning Python

[Lars Liedtke]

Hello and welcome,

the answer is a definitive "it depends" ;-)

Generally you do not need knowledge in C for learning Python.

But I'd say that it will not hurt to have some knowledge. Especially 
some packages use C-code to extend Python. But it seems to me that you 
are completely starting to learn how to program. Please correct me if I 
am wrong. So you can definitely learn how to program with learning 
Python and you can learn C afterwards if you need to.


Cheers

Lars


--
Lars Liedtke
Software Entwickler


Phone:  
Fax:+49 721 98993-
E-mail: l...@solute.de


solute GmbH
Zeppelinstraße 15   
76185 Karlsruhe
Germany


Marken der solute GmbH | brands of solute GmbH
billiger.de | Shopping.de 



Geschäftsführer | Managing Director: Dr. Thilo Gans, Bernd Vermaaten
Webseite | www.solute.de
Sitz | Registered Office: Karlsruhe
Registergericht | Register Court: Amtsgericht Mannheim
Registernummer | Register No.: HRB 110579
USt-ID | VAT ID: DE234663798


Informationen zum Datenschutz | Information about privacy policy
http://solute.de/ger/datenschutz/grundsaetze-der-datenverarbeitung.php

Am 07.09.22 um 12:28 schrieb Maruful Islam:

I want to start learning python. I have a question about learning python.

Is learning C essential or not for learning python?


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

Re: Question about learning Python

[Sandro Volery]

Hey Maruf

> I want to start learning python.
Good for you! Fun times ahead.

> Is learning C essential or not for learning python?
No, I would not say that learning C is essential for learning Python. However, 
C can serve as a great set of fundamentials in programming and understanding 
machines on a low level, such as memory management, etc., which all had to be 
done manually at this time.

It also seems important to note the differences between execution on runtime, 
and compiled languages, but there is many videos / articles that do a better 
job at explaining it than it do.

Best,
Sandro
-- 
https://mail.python.org/mailman/listinfo/python-list

Question about learning Python

[Maruful Islam]

I want to start learning python. I have a question about learning python. 

Is learning C essential or not for learning python?
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[황병희]

hw  writes:

> 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?
>
>
> [1]: https://www.learnpython.org/en/Variables_and_Types
>

OK man i saw your code other messages. That is simple.
You wrote 'Python's default keywords' so that occurs conflict.

Bomb.

To avoid conflict, i append some prefix like as "_" or "__" when i
write down var/func names sometimes...

Sincerely, Gnus fan Byung-Hee

-- 
^고맙습니다 _救濟蒼生_ 감사합니다_^))//
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Michael Torrie]

On 5/27/21 12:29 PM, hw wrote:
> When the idea is to learn something, it's not exactly helpful to abandon 
> that idea when encountering the first obstacle or when someone tells you 
> you don't like it as much as they do ...

We've had many new users approach the mailing list over the years.
Always, early on, one can tell what the chances of success are, and
which will end poorly.  This is why I questioned whether Python was a
good fit for you. Your attitude early on kind of raised alarm bells.
We've seen this before.  Many people on this list have patiently
answered you questions.  And while you seem to be holding on longer than
many, it's not clear to me you want to learn Python.  If your goal is to
learn and use python for some purpose, whining about how it acts
differently than you think it should, or how you would do something
different than Guido did, is not helpful to that purpose.  Why would you
think it is?  My prediction is your attitude will cause you to abandon
Python very soon, and you'll go away from this list with a sour taste in
your mouth, which is unfortunate, but completely of your own making.

Python is a powerful and expressive language and one I really enjoy
using, probably more so than any language I've ever used over the
decades.  It has warts of course.  Python makes a very poor C, Java, or
even Perl.  It's not for everyone or every purpose.

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

RE: learning python ...

[Avi Gross via Python-list]

HomeWork,

Nobody is suggesting that you change your attitude because of one obstacle.

But what if EVERYBODY here gives you similar feedback that python IS the way it 
is irrelevant of what other language designers have chosen or you expect?

Even if you propose a change that might be nice but it would break lots of 
existing programs, do you think it likely it would be done and time soon when 
the 2.x to 3.x transition has been so traumatic to some?

The reality is that you are here as a potential USER of Python or some other 
language and probably have not read enough about Python methods and features to 
be able to make the judgements you make. You do not seem able to handle some 
aspects of abstraction such as why you might want to write code that allows you 
to make some arbitrary changes. Wait till you find out how you can use Python 
to change the meaning of "+" to mean "-"  or anything else you want. But that 
same feature might let you redefine addition of two objects of a string-like 
nature to mean concatenation with a comma and space between them or whatever.

Clearly I can now conclude it is not worth continuing to do more discussion 
with you. I am not learning anything and neither are you, apparently. So you go 
do whatever it is you want and I will ignore and do something potentially of 
minimal use.

I have plenty of things in Python I am not thrilled with at times but I see 
that it is what it is. So, I use other languages for places where I see them as 
better or easier. But even when I do not love some feature, I do generally know 
why it is like it is and that generally someone else wanted it that way. It 
might be for efficiency or because it was easier to program it that way or even 
that my preferred way has problems I was not aware of. But generally, most 
languages have been fairly well thought-out with specific ideas in mind and are 
in many ways FINISHED albeit can often grow later.

-Original Message-
From: Python-list  On 
Behalf Of hw
Sent: Thursday, May 27, 2021 2:30 PM
To: python-list@python.org
Subject: Re: learning python ...


When the idea is to learn something, it's not exactly helpful to abandon that 
idea when encountering the first obstacle or when someone tells you you don't 
like it as much as they do ...

On 5/25/21 7:56 AM, Avi Gross via Python-list wrote:
> 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 variable

Re: learning python ...

[Christian Gollwitzer]

Am 25.05.21 um 06:08 schrieb hw:

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

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




Yes, it does. It is a common pitfall for newbie Python programmers.

def f(a):
a.append(2)

l=[1, 2, 3]

f(l)
print(l)


==> [1, 2, 3, 2]

The strange thing, coming from a different language, is the apparent 
difference, if instead of a list, you pass an integer:


def f(a):
a=5

l=3

f(l)
print(l)

> 3

Here, the "l" is not changed. The reason is that the statement "a=5" 
does NOT modify the object in a, but instead creates a new one and binds 
it to a. l still points to the old one. Whereas a.append() tells the 
object pointed to by a to change.


Christian

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

Re: learning python ...

[Michael F. Stemper]

On 27/05/2021 16.13, Christian Gollwitzer wrote:

Am 25.05.21 um 06:08 schrieb hw:

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

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


The strange thing, coming from a different language, is the apparent 
difference, if instead of a list, you pass an integer:


def f(a):
 a=5

l=3

f(l)
print(l)

> 3

Here, the "l" is not changed. The reason is that the statement "a=5" 
does NOT modify the object in a, but instead creates a new one and binds 
it to a. l still points to the old one. Whereas a.append() tells the 
object pointed to by a to change.


What was fun in Fortran was that you could do the following:

  CALL SS(3)
  PRINT *, 3
  END
  SUBROUTINE SS(K)
  K = 5
  RETURN
  END

The output of this gem would be 5, at least though Fortran 77. It was
call by reference, even for constants. (Every manual said not to do
this, of course.)

--
Michael F. Stemper
Outside of a dog, a book is man's best friend.
Inside of a dog, it's too dark to read.
--
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Peter J. Holzer]

On 2021-05-27 20:59:47 +0200, hw wrote:
> On 5/25/21 3:09 PM, Greg Ewing wrote:
> > On 25/05/21 5:56 pm, Avi Gross wrote:
> > > 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 long as all the values are of the same type, this isn't too bad,
> > although it might interfere with your ability to give the intermediate
> > results names that help the reader understand what they refer to.
> > 
> > A variable that refers to things of different *types* at different
> > times is considerably more confusing, both for a human reader and
> > for any type checking software you might want to use.
> 
> How would this matter when the variables are typeless?

It doesn't matter for Python. It does matter for some people -
especially those that think that variables have (or should have) a type.

Of course "type checking software" follows that paradigm.


> Often times, it's not very practical to figure out the type of a value
> before assigning it to a variable ...

In statically typed languages (like C, Java, Go, ...) you have to do
that. In dynamically typed languages like Python you don't and in
general can't.


> > > 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.
> > 
> > Um, no. What you're describing is called "dynamic scoping", and
> > Python doesn't have it. Python is *lexically* scoped, meaning that
> > only scopes that textually enclose the function in the source are
> > searched for names. Frames on the call stack don't come into it.
> > 
> > > So what if you suggest we allow re-use of names but WARN you. ...
> > > The first 50 places may be in other instances of the recursive
> > > function and you have already been warned this way 49 times
> > 
> > If this were to be done, the shadowing would be detected at compile
> > time, so you would only be warned once.
> 
> Works fine in perl (and you can have it without warnings if you want to,
> though that's not recommended):
> 
> 
> perl -e 'use warnings; my $shadow; my $shadow; my $shadow';
> "my" variable $shadow masks earlier declaration in same scope at -e line 1.
> "my" variable $shadow masks earlier declaration in same scope at -e line 1.

That's something different. Here you are redeclaring the same variable
in the same scope (Note that this cannot happen in Python because you
don't declare variables in Python). 

If you write something like this:


#!/usr/bin/perl
use v5.12;
use warnings;

my $x = 5;
{
my $x = 10; 
say $x;
}
say $x;


You won't get a warning, and the program will print 
--
10
5
--


But dynamic scope is something different. It's based on the call stack,
not syntax. In Perl, you get dynamically scoped variables with local.
This is quite deprecated and mostly used to temporarily shadow
predefined variables like $/ (although I've occasionally used it for
other purposes, too).

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

[hw]

On 5/25/21 3:09 PM, Greg Ewing wrote:

On 25/05/21 5:56 pm, Avi Gross wrote:
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 long as all the values are of the same type, this isn't too bad,
although it might interfere with your ability to give the intermediate
results names that help the reader understand what they refer to.

A variable that refers to things of different *types* at different
times is considerably more confusing, both for a human reader and
for any type checking software you might want to use.


How would this matter when the variables are typeless?

Often times, it's not very practical to figure out the type of a value 
before assigning it to a variable ...


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.


Um, no. What you're describing is called "dynamic scoping", and
Python doesn't have it. Python is *lexically* scoped, meaning that
only scopes that textually enclose the function in the source are
searched for names. Frames on the call stack don't come into it.

So what if you suggest we allow re-use of names but WARN you. ... The 
first 50 places may be in other instances of the recursive function 
and you have already been warned this way 49 times


If this were to be done, the shadowing would be detected at compile
time, so you would only be warned once.


Works fine in perl (and you can have it without warnings if you want to, 
though that's not recommended):



perl -e 'use warnings; my $shadow; my $shadow; my $shadow';
"my" variable $shadow masks earlier declaration in same scope at -e line 1.
"my" variable $shadow masks earlier declaration in same scope at -e line 1.


"Mask" seems like a much better word for this than "shadow" ...
--
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[hw]

s and even suggesting changes. 
I simply suggest when others push back and tell you it was designed this way 
for darn good reasons and many LIKE IT the way it is, ...


-Original Message-
From: Python-list  On 
Behalf Of Cameron Simpson
Sent: Monday, May 24, 2021 5:34 AM
To: python-list@python.org
Subject: Re: learning python ...

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



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

Re: learning python ...

[Greg Ewing]

On 26/05/21 7:15 pm, hw wrote:
it could at least figure out which, the 
type or the variable, to use as parameter for a function that should 
specify a variable type when the name is given.  Obviously, python knows 
what's expected, so why not chose that.


It knows, but not until *after* the function is called. Not
when the parameters are being evaluated.

Note that not even C does what you're asking for. If you use
a type name where a variable name is expected or vice versa
in C, you get a compile-time error. It doesn't try to
automagically figure out what you mean. The only difference
is that Python gives you the error at run time.

Also, you seem to be thinking only of the case where the type
name appears directly in the call. But what about this:

int = 42
type = int
if isinstance(something, type):
...

Would you expect Python to auto-correct this as well?

Maybe a special 
syntax for declaring type names which then can not become ambigous so 
easily would be a good thing?


The fact that types are treated as a form of data is a useful
feature. It means you can use the full power of the language on
them. Dividing names into two kinds, types and non-types, would
severely diminish that power.

I already wondered that the scope of variables is not limited to the 
context they are declared within:


for number in something:
     # do stuff


This has been a subject of debate for quite a long time.
Many people feel that a for-loop variable should be local to
the loop, but Guido deliberately didn't make it that way.
He felt it was useful to be able to refer to the loop
variable after the loop finishes. That way you can do things
like search for something in a loop, break out early when it's
found, and the loop variable then contains the thing you found.

It also has the benefit of being simple and consistent with
the way scoping and assignments work in the rest of the language.

There are other ways to code a search, of course, but it's been
the way it is from the beginning, and changing it now would be
massively disruptive.

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

Re: learning python ...

[Chris Angelico]

On Wed, May 26, 2021 at 5:49 PM hw  wrote:
>
> On 5/25/21 10:32 AM, Chris Angelico wrote:
> > On Tue, May 25, 2021 at 1:00 PM hw  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.

And that's where you're insulting (a) the Python devs, (b) the Python
user community, and (c) everyone who dares to use such a language in
production.

Without evidence.

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

Ah yes. A breaking change *a decade ago*, and which has been clearly
stated as not being repeated, is cause for you to be scared. Can you
quit fudding please?

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

Exactly what I'm saying about Blub. You assume that every language has
to treat type names as keywords, because that's the only model that
fits inside your brain.

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

That's because a type name IS a variable, yet you can't understand
that this is a good thing.

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

Because Python has a lot of types, and lets you create your own.
Fundamentally it *cannot* use keywords for every type name that you
might create.

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

Yes, you are arguing against the language.

I'm done arguing with you. Clearly you do not want to use Python - you
want to warp it to fit inside your own brain. Go use something else
that actually works for you, and let the rest of us be productive with
languages that are more powerful than you dare imagine.

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

Re: learning python ...

[hw]

nce.


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.

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

Re: learning python ...

[hw]

On 5/25/21 9:42 AM, Greg Ewing wrote:

On 25/05/21 2:59 pm, hw wrote:
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? 


You seem to be asking for names to be interpreted differently
when they are used as parameters to certain functions.


Sure, why not.  Since python allows me to use the name of a variable 
type as a name for a variable, it could at least figure out which, the 
type or the variable, to use as parameter for a function that should 
specify a variable type when the name is given.  Obviously, python knows 
what's expected, so why not chose that.



Python doesn't do that sort of thing. The way it evaluates
expressions is very simple and consistent, and that's a good
thing. It means there aren't any special cases to learn and
remember.


Ok, that's certainly a valid point.  It could be a general case that 
python picks for functions what is expected of their parameters when 
their parameters have ambigous names.



Maybe you're not aware that isinstance is just a function,
and not any kind of special syntax?


Perhaps type names should be keywords to avoid confusion.


Python has quite a lot of built-in types, some of them in
the builtin namespace, some elsewhere. Making them all keywords
would be impractical, even if it were desirable.

And what about user-defined types? Why should they be treated
differently to built-in types? Or are you suggesting there
should be a special syntax for declaring type names?


I don't know; how many different types does it have?  Maybe a special 
syntax for declaring type names which then can not become ambigous so 
easily would be a good thing?


I already wondered that the scope of variables is not limited to the 
context they are declared within:



for number in something:
# do stuff

# do more stuff or not ...
print(number)


When you do something like that in perl, the variable you declared is 
out of scope outside the loop whereas python surprises me by keeping it 
around.  Somehow, the more I learn about python, the harder it becomes 
for me to read.


Maybe that changes over time, yet keeping variables around like that is 
not something I would prefer.

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

Re: learning python ...

[Greg Ewing]

On 2021-05-24, Alan Gauld via Python-list  wrote:

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.


This isn't really true either. Almost every object in Python has
an interpretation as true or false, and can be used wherever a
boolean value is needed.

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

Re: learning python ...

[Greg Ewing]

On 26/05/21 3:33 am, Dennis Lee Bieber wrote:

the OBJECTS have a type and can not change type.


Well... built-in types can't, but...

>>> class A:
...  pass
...
>>> class B:
...  pass
...
>>> a = A()
>>> type(a)

>>> a.__class__ = B
>>> type(a)


--
Greg

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

Re: learning python ...

[Manfred Lotz]

On Mon, 24 May 2021 08:14:39 +1200
Ron.Lauzon@f192.n1.z21.fsxnet (Ron Lauzon) wrote:

> -=> hw wrote to All <=-  
> 
>  hw> Traceback (most recent call last):
>  hw>File "[...]/hworld.py", line 18, in 
>  hw>  print(isinstance(int, float))
>  hw> TypeError: isinstance() arg 2 must be a type or tuple of types  
> 
>  hw> I would understand to get an error message in line 5 but not in
>  hw> 18.  Is this a bug or a feature?  
> 
> Python is case sensitive.  Is that supposed to be "isInstance"?
> 
> 

This is easy to check

$ python3
Python 3.9.5 (default, May 14 2021, 00:00:00) 
[GCC 11.1.1 20210428 (Red Hat 11.1.1-1)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> isinstance

>>> isInstance
Traceback (most recent call last):
  File "", line 1, in 
NameError: name 'isInstance' is not defined


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

Re: learning python ...

[Michael F. Stemper]

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

Re: learning python ...

[Grant Edwards]

On 2021-05-25, Michael F. Stemper  wrote:
> On 24/05/2021 23.08, hw wrote:
>> On 5/25/21 12:37 AM, Greg Ewing wrote:
>> 
>> 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 ...
>
> I just ran a quick check and java (Ack, spit) does the same thing.

PHP might or might not do the same thing. There might or might not be
extra syntax to specify which you want. Where that syntax goes and how
it works varies depending on the version of PHP. There might also be a
global config file where you can change the "default" behavior. Or
not.

In PHP, there's nothing _but_ special cases to try to remember. And
the details for those cases change from one version to the next.

If ever there was a language that's perpetually unfinished, it's PHP.





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

Re: learning python ...

[Michael F. Stemper]

On 24/05/2021 23.08, hw wrote:

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



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


I just ran a quick check and java (Ack, spit) does the same thing.


--
Michael F. Stemper
Isaiah 10:1-2
--
https://mail.python.org/mailman/listinfo/python-list

Re: learning python ...

[Grant Edwards]

On 2021-05-25, Greg Ewing  wrote:
> On 25/05/21 5:56 pm, Avi Gross wrote:
>> 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 long as all the values are of the same type, this isn't too bad,
> although it might interfere with your ability to give the intermediate
> results names that help the reader understand what they refer to.

I do vaguely recall 20+ years ago when I first started writing Python
I recoiled at it, but now I don't find it to be a problem if all of
the assignments are close together as above (so that it's not possible
to see one and miss the others) and there's only one execution path
through that chunk of code.

I try to avoid it if they're spread out over hundreds of lines of code
or if there are paths that result in different types at the end.

> A variable that refers to things of different *types* at different
> times is considerably more confusing, both for a human reader and
> for any type checking software you might want to use.

Ah, I've never tried any type checking software, so that may explain
my lax attitude.

--
Grant

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

Re: learning python ...

[Grant Edwards]

On 2021-05-24, Alan Gauld via Python-list  wrote:
> 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.

Indeed -- after posting that I realized that "conditional expression"
was not the best phrase to choose because that's often used to refer
to an expression involving the new ternary operator. I should have
said "boolean valued expression".  Though in the syntax for the
ternary operator expression I've seen such a boolean valued expression
called a "conditional expression".

https://realpython.com/python-conditional-statements/

if  else 


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

Re: learning python ...

[Greg Ewing]

On 25/05/21 5:56 pm, Avi Gross wrote:

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 long as all the values are of the same type, this isn't too bad,
although it might interfere with your ability to give the intermediate
results names that help the reader understand what they refer to.

A variable that refers to things of different *types* at different
times is considerably more confusing, both for a human reader and
for any type checking software you might want to use.


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.


Um, no. What you're describing is called "dynamic scoping", and
Python doesn't have it. Python is *lexically* scoped, meaning that
only scopes that textually enclose the function in the source are
searched for names. Frames on the call stack don't come into it.


So what if you suggest we allow re-use of names but WARN you. ... The first 50 
places may be in other instances of the recursive function and you have already 
been warned this way 49 times


If this were to be done, the shadowing would be detected at compile
time, so you would only be warned once.

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

Re: learning python ...

[Greg Ewing]

On 25/05/21 2:59 pm, hw wrote:
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?  


You seem to be asking for names to be interpreted differently
when they are used as parameters to certain functions.

Python doesn't do that sort of thing. The way it evaluates
expressions is very simple and consistent, and that's a good
thing. It means there aren't any special cases to learn and
remember.

Maybe you're not aware that isinstance is just a function,
and not any kind of special syntax?


Perhaps type names should be keywords to avoid confusion.


Python has quite a lot of built-in types, some of them in
the builtin namespace, some elsewhere. Making them all keywords
would be impractical, even if it were desirable.

And what about user-defined types? Why should they be treated
differently to built-in types? Or are you suggesting there
should be a special syntax for declaring type names?

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

Re: learning python ...

[Alan Gauld via Python-list]

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


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

Re: learning python ...

[Michael Torrie]

On 5/24/21 9:53 PM, 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.

Your thinking is not incorrect.  Assignment is how you set a variable to
something.  For the most part the details of how the variables work
doesn't matter all that much.  An expression in Python works about the
same as it does in other languages.  Where it becomes important to
understand the name binding mechanism is in situations like you found
yourself.  What happens, for example, when you do something like
float=5? Hence the discussion about name shadowing.

The reason I brought up the distinction of how python's variables work
compared to a language like C is because under the hood Python's
assignment doesn't "alter" the variable.  Assignment replaces it
entirely in the name space.  This is consistent with a more formal
definition of variable found in lambda calculus.  I learned in uni there
are some formal languages that don't allow any variable names to be
rebound at all, which makes formal proofs and analysis easier. But I
digress.

There are also implications for parameter passing.  All of this is in
the language reference documentation of course.  But even still there
have been many arguments about whether Python is pass by value or pass
by reference.  Consider:

def foo(bar):
bar += 1

a = 5
foo(a)
print(a)

or

def frob(foo):
foo.append('bar')

a = [ 'one', 'two' ]
frob(a)
print(a)

The truth is Python might be said to "pass by object."  In other words
when you call a function, it goes through the names table and extracts
references to all the objects involves with the arguments and passes
those objects to the function.  Objects that are mutable can be changed
by a function, and those changes are visible in the code that called it,
since both caller and callee are dealing with the *same object*, just by
different names (aliases).  Strings and other values like ints are
*immutable*.  They cannot be changed.  Assignment will not change them,
only overwrite the names in the locals table.

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

Yes that's how it's done in many lower-level languages.  Python does not
assign that way, though. It's not clearing the contents and placing
something else there. Instead assignment overwrites the binding in the
name table, connecting the name to the new string object that was
created. The old object is dereferenced, and the garbage collector will
eventually remove it.

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

How exactly would one overwrite an integer in memory with a string,
though?  You would have to either preallocate a lot of memory for it in
case something large were to be written to the variable, or you'd
allocate it on the heap on demand and use a reference for it.  Under the
hood, Python does the second.  How else would you do it?

> Isn't that what variables are for?

In the formal sense, variables are just names that stand in for values.
 Don't get too hung up on the mechanics of how one implements that as
being a formal part of the definition, and don't think that one
language's implementation of variables is the only way to do it.

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

Re: learning python ...

[Richard Damon]

On 5/25/21 12:08 AM, hw wrote:
>
> 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 ...

If you mutate the object the parameter was bound to, the calling
function will see the changed object. (This requires the object to BE
mutateable, like a list, not an int)

If you rebind that parameter to a new object, the calling function
doesn't see the change, as its name wasn't rebound.

-- 
Richard Damon

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

Shadowing, was Re: learning python ...

[Peter Otten]

On 25/05/2021 05:20, hw wrote:


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?



When you write

foo

in a module the name "foo" is looked up in the module's global 
namespace. If it's not found it is looked up in builtins. If that lookup 
fails a NameError exception is raised.


>>> import builtins
>>> builtins.foo = "built-in foo"
>>> foo
'built-in foo'
>>> foo = "module-global-foo"  # at this point builtins.foo is shadowed
>>> foo
'module-global-foo'
>>> del foo # delete the global to make the built-in visible again:
>>> foo
'built-in foo'

That mechanism allows newbies who don't know the builtins to write

list = [1, 2, 3]

without affecting other modules they may use. It also allows old scripts 
that were written when a builtin name did not yet exist to run without 
error.


The problem you ran into, using a name in two roles

float = float("1.2")

could be circumvented by writing

float = builtins.float("1.2")

but most of the time it is more convenient to think of builtins as names 
that are predefined in your current module and act accordingly.


As you see redefining a builtin is as easy as importing builtins and 
setting the respective attribute


>>> builtins.float = int
>>> float(1.23)
1

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

Re: learning python ...

[Chris Angelico]

On Tue, May 25, 2021 at 1:00 PM hw  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.

None of which is even slightly supported by evidence.

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

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

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

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? The Go language didn't even *exist* before Python 3 - does
that mean that Go is also unfinished?

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

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.

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

RE: learning python ...

[Avi Gross via Python-list]

mpson
Sent: Monday, May 24, 2021 5:34 AM
To: python-list@python.org
Subject: Re: learning python ...

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

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

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 

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

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

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

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 

Re: learning python ...

[hw]

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.



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.


There are some reasons why allowing this is quite nice. And there’s
actually a ton of corner cases to consider when thinking about changing the
rules


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?



Interestingly python 3 made this a little bit better by stopping you from
rebinding (shadowing) a number of built ins, such as True and False.

In your case, I agree that it is super confusing. One thing to learn to
look out for is if you assign to line 9, in 

print(type(str))
TypeError: 'int' object is not callablea name, then use that name on a 
different

context, expecting it to be different, then that’s not likely to work as
you expect.

It seems like a recipie

for creating chaos.


The runtime lets you do all sorts of things. Linters and type checkers
exist to help you notice if you're writing such a recipe.

There _are_ times when it is useful to shadow a builtin name. Not being
able to prevents a useful activity.

A common example in my own code is this:

 from cs.upd import Upd, print

which shadows the print() builtin. The Upd class maintains status lines
such as progress bars and so forth. It provides a print() function which
withdraws the status lines, runs the builtin print, then restores them,
allowing normal idiomatic use of print() in scripts making use of the
status lines.

Similar situations abound.


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

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

Re: learning python ...

[hw]

PS:

On 5/24/21 7:20 AM, hw wrote:
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?


Ok, it prints "" for type(str) when str hasn't been defeated.

But still:


#!/usr/bin/python

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


line 9, in 
print(type(str))
TypeError: 'int' object is not callable


How is this /not/ bad?  It seems like a no-go for any programming 
language that isn't designed for the programmer to shoot into thier own 
feet.

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

Re: learning python ...

[Igor Korot]

Hi,

On Mon, May 24, 2021 at 12:26 AM 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.
>
> > 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.
> >
> >
> > There are some reasons why allowing this is quite nice. And there’s
> > actually a ton of corner cases to consider when thinking about changing
> > the rules
>
> Perl has a way to turn off unwanted warnings.  It won't change the rules
> to give a warning.
>
> > Interestingly python 3 made this a little bit better by stopping you
> > from rebinding (shadowing) a number of built ins, such as True and False.
> >
> > In your case, I agree that it is super confusing.
>
> 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.
>
> 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.
>
> > 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?
>
> 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?
>
> 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 seems like a recipie
> > for creating chaos.
> >
> >
> > Luckily almost every python code checker and/or linter will highlight
> > this for you.
> >
> > If you’re learning python, I’d highly recommend doing so in an ide or
> > editor that has a code checker running.
>
> Emcas highlights the syntax fine; I don't know if it can do more for
> python.  It shouldn't need to.
>
> Things get creepy when a programming language makes it so that the
> programmer can't figure out anymore how a result produced by his program
> has come about.

Remember - python is an untyped language.
It is not C, C++ or even Pascal.

So there is no difference whether you write

float = 5.0

or

float1 = 5.0

Thank you.

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

Re: learning python ...

[hw]

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.


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. 



There are some reasons why allowing this is quite nice. And there’s 
actually a ton of corner cases to consider when thinking about changing 
the rules


Perl has a way to turn off unwanted warnings.  It won't change the rules 
to give a warning.


Interestingly python 3 made this a little bit better by stopping you 
from rebinding (shadowing) a number of built ins, such as True and False.


In your case, I agree that it is super confusing.


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.


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.


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?

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?


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 seems like a recipie
for creating chaos.


Luckily almost every python code checker and/or linter will highlight 
this for you.


If you’re learning python, I’d highly recommend doing so in an ide or 
editor that has a code checker running.


Emcas highlights the syntax fine; I don't know if it can do more for 
python.  It shouldn't need to.


Things get creepy when a programming language makes it so that the 
programmer can't figure out anymore how a result produced by his program 
has come about.

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

Re: learning python ...

[Cameron Simpson]

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 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.
>
>There are some reasons why allowing this is quite nice. And there’s
>actually a ton of corner cases to consider when thinking about changing the
>rules

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.

>Interestingly python 3 made this a little bit better by stopping you from
>rebinding (shadowing) a number of built ins, such as True and False.
>
>In your case, I agree that it is super confusing. 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.
>
>It seems like a recipie
>> for creating chaos.

The runtime lets you do all sorts of things. Linters and type checkers 
exist to help you notice if you're writing such a recipe.

There _are_ times when it is useful to shadow a builtin name. Not being 
able to prevents a useful activity.

A common example in my own code is this:

from cs.upd import Upd, print

which shadows the print() builtin. The Upd class maintains status lines 
such as progress bars and so forth. It provides a print() function which 
withdraws the status lines, runs the builtin print, then restores them, 
allowing normal idiomatic use of print() in scripts making use of the 
status lines.

Similar situations abound.

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

Re: learning python ...

[Stestagg]

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”

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.


There are some reasons why allowing this is quite nice. And there’s
actually a ton of corner cases to consider when thinking about changing the
rules

Interestingly python 3 made this a little bit better by stopping you from
rebinding (shadowing) a number of built ins, such as True and False.

In your case, I agree that it is super confusing. 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.

It seems like a recipie
> for creating chaos.


Luckily almost every python code checker and/or linter will highlight this
for you.

If you’re learning python, I’d highly recommend doing so in an ide or
editor that has a code checker running.


> --



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

Re: learning python ...

[MRAB]

On 2021-05-23 20:34, 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.  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.

The example you're following calls the variables "myfloat", etc, not 
"float", etc, so, yes, you're hiding the names of the types. Don't do that.


As far as Python is concerned, it's just a name that refers to 
something. It doesn't care whether that something is a type or a 
function or something else, it's just a name that refers to something.

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

Re: learning python ...

[hw]

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

[Peter Otten]

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

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

learning python ...

[hw]

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?



[1]: https://www.learnpython.org/en/Variables_and_Types
--
https://mail.python.org/mailman/listinfo/python-list

Re: learning python building 2nd app, need advices

[Phil Boutros]

Loris Bennett  wrote:

> As an Emacs user, personally I would use the command 
>
>   M-x untabify
>
> within Emacs.  I assume that Vim has something similar.

It does.  ':retab' is what you want.  If you have tabstop set to a
specific value, it'll use that.  If not, you can do ':retab ',
where  is an integer defining how many spaces to replace a tab
with.

Don't add the quote symbols ('), I added it for readability!

As others have mentionned, 'expand' from the shell also works. 

Phil
-- 
AH#61  Wolf#14  BS#89  bus#1  CCB#1  SENS  KOTC#4
ph...@philb.ca  http://philb.ca
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python building 2nd app, need advices

[Grant Edwards]

On 2021-01-11, 2qdxy4rzwzuui...@potatochowder.com 
<2qdxy4rzwzuui...@potatochowder.com> wrote:
> On 2021-01-11 at 06:34:42 -0800,
> pascal z via Python-list  wrote:
>
>> On Monday, January 11, 2021 at 2:07:03 PM UTC, Chris Angelico wrote:
>
>> > Easy fix: stop looking at the Google Group page. 
>>
>> ok, emails show post fine. 10 years ago or something, I was quite
>> involved to comp.lang.c and I don't remember having this issue. Of
>> course, only Python needs formatting speficities but from what I can
>> remember, indentation was working fine then. One more thing, is that
>> there was a lot less ads than now. And comp.lang.python seems to show
>> more ads than other groups like comp.lang.c
>
> I read the mailing list.  With an email client.  No ads.
>
> Start at , join the mailing
> list, and stop using Google.

Or point your favorite NNTP client at 
nntp://news.gmane.io/gmane.comp.python.general

Google Groops is definitely the wrong answer.

--
Grant





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

Re: learning python building 2nd app, need advices

[Grant Edwards]

On 2021-01-11, pascal z via Python-list  wrote:

> tab to space on linux is not something easy to do,

Nonsense, there's a command _specifically_ for that:

$ man expand

--
Grant

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

Re: learning python building 2nd app, need advices

[Terry Reedy]

On 1/11/2021 6:46 AM, pascal z via Python-list wrote:

tab to space on linux is not something easy to do,


IDLE has a tab to spaces command on the format menu.


--
Terry Jan Reedy

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

Re: learning python building 2nd app, need advices

[2QdxY4RzWzUUiLuE]

On 2021-01-11 at 06:34:42 -0800,
pascal z via Python-list  wrote:

> On Monday, January 11, 2021 at 2:07:03 PM UTC, Chris Angelico wrote:

> > Easy fix: stop looking at the Google Group page. 
> > 
> > ChrisA
> ok, emails show post fine. 10 years ago or something, I was quite
> involved to comp.lang.c and I don't remember having this issue. Of
> course, only Python needs formatting speficities but from what I can
> remember, indentation was working fine then. One more thing, is that
> there was a lot less ads than now. And comp.lang.python seems to show
> more ads than other groups like comp.lang.c

I read the mailing list.  With an email client.  No ads.

Start at , join the mailing
list, and stop using Google.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python building 2nd app, need advices

[pascal z via Python-list]

On Monday, January 11, 2021 at 2:07:03 PM UTC, Chris Angelico wrote:
> On Tue, Jan 12, 2021 at 1:01 AM pascal z via Python-list 
>  wrote: 
> > 
> > On Monday, January 11, 2021 at 1:45:31 PM UTC, Greg Ewing wrote: 
> > > On 12/01/21 1:12 am, pascal z wrote: 
> > > > As alternative, I pasted it into github and pasted it back into this 
> > > > page, it's ok when pasting but when posting it fails keeping spaces... 
> > > The indentation in your last three posts looks fine here in 
> > > the comp.lang.python newsgroup. If it doesn't look right to 
> > > you, it may be the fault of whatever you're using to read 
> > > the group. 
> > > 
> > > -- 
> > > Greg 
> > 
> > @Greg, then if you want, you can post these from what you're using. I tried 
> > sending a few times and it seemed it didn't work when refreshing the google 
> > group discussion page. However, just looking now at the discussion through 
> > emails, shows indentation right. I'm using firefox. I'll try using chromium 
> > for later posts if that makes things easier. 
> >
> Easy fix: stop looking at the Google Group page. 
> 
> ChrisA
ok, emails show post fine. 10 years ago or something, I was quite involved to 
comp.lang.c and I don't remember having this issue. Of course, only Python 
needs formatting speficities but from what I can remember, indentation was 
working fine then. One more thing, is that there was a lot less ads than now. 
And comp.lang.python seems to show more ads than other groups like comp.lang.c
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python building 2nd app, need advices

[Chris Angelico]

On Tue, Jan 12, 2021 at 1:01 AM pascal z via Python-list
 wrote:
>
> On Monday, January 11, 2021 at 1:45:31 PM UTC, Greg Ewing wrote:
> > On 12/01/21 1:12 am, pascal z wrote:
> > > As alternative, I pasted it into github and pasted it back into this 
> > > page, it's ok when pasting but when posting it fails keeping spaces...
> > The indentation in your last three posts looks fine here in
> > the comp.lang.python newsgroup. If it doesn't look right to
> > you, it may be the fault of whatever you're using to read
> > the group.
> >
> > --
> > Greg
>
> @Greg, then if you want, you can post these from what you're using. I tried 
> sending a few times and it seemed it didn't work when refreshing the google 
> group discussion page. However, just looking now at the discussion through 
> emails, shows indentation right. I'm using firefox. I'll try using chromium 
> for later posts if that makes things easier.
>

Easy fix: stop looking at the Google Group page.

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

Re: learning python building 2nd app, need advices

[pascal z via Python-list]

On Monday, January 11, 2021 at 1:45:31 PM UTC, Greg Ewing wrote:
> On 12/01/21 1:12 am, pascal z wrote: 
> > As alternative, I pasted it into github and pasted it back into this page, 
> > it's ok when pasting but when posting it fails keeping spaces...
> The indentation in your last three posts looks fine here in 
> the comp.lang.python newsgroup. If it doesn't look right to 
> you, it may be the fault of whatever you're using to read 
> the group. 
> 
> -- 
> Greg

@Greg, then if you want, you can post these from what you're using. I tried 
sending a few times and it seemed it didn't work when refreshing the google 
group discussion page. However, just looking now at the discussion through 
emails, shows indentation right. I'm using firefox. I'll try using chromium for 
later posts if that makes things easier.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: learning python building 2nd app, need advices

[Greg Ewing]

On 12/01/21 1:12 am, pascal z wrote:

As alternative, I pasted it into github and pasted it back into this page, it's 
ok when pasting but when posting it fails keeping spaces...


The indentation in your last three posts looks fine here in
the comp.lang.python newsgroup. If it doesn't look right to
you, it may be the fault of whatever you're using to read
the group.

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

Re: learning python building 2nd app, need advices

[pascal z via Python-list]

On Monday, January 11, 2021 at 12:00:28 PM UTC, Loris Bennett wrote:
> pascal z  writes: 
> 
> > tab to space on linux is not something easy to do 
> 
> I would argue that you are mistaken, although that depends somewhat on 
> your definition of 'easy'. 
> 
> > , I had to launch windows and use notepad++. 
> 
> There is the Linux command 'expand' , which I have never used, but which 
> sounds like it will do what you want: 
> 
> $ expand --help 
> Usage: expand [OPTION]... [FILE]... 
> Convert tabs in each FILE to spaces, writing to standard output. 
> 
> As an Emacs user, personally I would use the command 
> 
> M-x untabify 
> 
> within Emacs. I assume that Vim has something similar. 
> 
> Cheers, 
> 
> Loris 
> 
> -- 
> This signature is currently under construction.


Thanks, I'm going to try

As alternative, I pasted it into github and pasted it back into this page, it's 
ok when pasting but when posting it fails keeping spaces... Until I can find a 
way to do it, this is the github link 

https://github.com/barpasc/listfiles/blob/main/pyFilesGest_6B18.py
-- 
https://mail.python.org/mailman/listinfo/python-list