Re: for convenience

[Paul St George]

On 22/03/2022 18.04, dn wrote:

> and thank you - it is refreshing, if not enervating, to receive feedback
> on efforts-expended!
> 
> You will also notice, that now you understand the id() stuff, the
> tag-team effect between @Chris and I (which we have often played, albeit
> not by-design), now makes sense as an whole (if you didn't quite follow,
> earlier).
> 
> 
> My research-topic is Cognitive Psychology (how we learn - albeit not
> usually in Python). I found this conversation useful, and may well apply
> it as an example (with your permission, and suitably anonymised) - one
> doesn't need to be a 'computer person' to follow the logic and thus
> realise the dissonance!
> 
> While learning (this part of) Python and adding to 'previous
> experience', you formed a "mental-model" of how things work (just as we
> all do). However, when it came time to implement this knowledge:
> 
> - you created a 'situation'
> - (all) things didn't 'work' (which also required realisation)
> - you analysed and rationalised (but noted inconsistency)
> - you asked a question (which many of us quickly understood)
> - you've learned/corrected
> 
> 
> The 'issue' is *not* a fault on your part, nor (necessarily) a lack of
> learning or a lack of effort. So, no criticism from me!
> 
> The (under-lying) lesson, is that we (as trainers, but with application
> to all helpers, pair-programmers, mentors, documentation-writers, et al
> - working with less-experienced colleagues) shouldn't spout a whole load
> of 'facts', 'rules', and formulae/s - which we expect to be committed to
> memory. We need to help form a 'correct' mental-model ("correct" being
> defined by the Python interpreter and 'the Python gods' who build it -
> big "thank you" to them!).
> 
> Accordingly, my criticism of tests/exams which require recitation of
> facts ("parroting"), compared with "mastery" (can you actually DO what
> is being asked). More importantly, and finally getting to the point:
> 'tests' should be defined to reveal these (personal) 'quirks' of
> learning/understanding, which led to a 'faulty' mental-model!
> 
> Your rationale made sense, was logical and understandable. How are you
> to know that Python deems it 'wrong'? (until a 'test' shows you!)
> 
> The 'interest' should not be on the people who, and all the 'answers'
> which, were 'correct'. What is more informative, is why someone (aside
> from guessing, ie intelligent, reasonable, after learning the material,
> exerting effort...) got it 'wrong' - but thought his/her path was true!
> -- 
> Regards,
> =dn


Wow, this is super interesting. You have my permission, and please feel free to 
contact me offline if you want to ask anything.

Yes, I had noticed the tandem with @Chris. I think I needed both! I already 
have a folder on my Mac called ‘Cameron’. Perhaps I now need an additional 
folder. Then I can ask my question about whether Python grows to be more like 
its programmers, or do programmers learn to think Pythonically?


—
Paul St George

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

[RELEASE] Python 3.10.4 and 3.9.12 are now available out of schedule

[Łukasz Langa]

Did anybody say cursed releases 
?
 Well, it turns out that 3.10.3 and 3.9.11 both shipped a regression which 
caused those versions not to build on Red Hat Enterprise Linux 6. While this 
11-year-old version is now out of maintenance support 
, it’s still used in 
production workloads. Some of those rely on Python 3.9 and/or 3.10. In 
particular, our own manylinux2010 

 image used to build widely compatible Linux wheels is based on CentOS 6. 
(Don’t worry, we do have newer manylinux* variants, see PEP 599 
 and PEP 600 
 for details.)

Due to the out-of-schedule release, the respective versions released today 
contain a very limited set of changes. Python 3.9.12 only contains 12 other bug 
fixes on top of 3.9.11. Python 3.10.4 only contains 10 other bug fixes on top 
of 3.10.3.

Get 3.10.4 here: Python Release 3.10.4 | Python.org 

Get 3.9.12 here: Python Release 3.9.12 | Python.org 

Hopefully, the third time’s a charm and we’ll return no sooner than May with 
the regularly scheduled bug fix releases of 3.9 and 3.10.

 
We
 hope you enjoy the new releases

Your friendly release team,
Łukasz Langa @ambv 
Pablo Galindo Salgado @pablogsal 
Ned Deily @nad 
Steve Dower @steve.dower 


signature.asc
Description: Message signed with OpenPGP
-- 
https://mail.python.org/mailman/listinfo/python-list

Pyto Implementation - GROWING TREND

[Steeve Kerou via Python-list]

Hi,
We develop Pyto - the first python class with an animated character that helps 
you learn the basics concepts of Python Language like you're playing video game 
- and we'd like it to be implemented. 
Potential is limitless and can reach unlimited number of new users who will 
then use your software suite. (Don't underestimate the Happy Meal Effect !!)
Interested is growing, don’t let another IDE developer implement it before you !

We also developed a series of short classes to learn basic concepts, show the 
potential of Pyto and how it can be implemented:
https://www.youtube.com/watch?v=Eoh7FVR_QcM&list=PLipSv-7x4nWdPTwpZ0pDoOnGhhg3vboh5

Have a look,

Learn Python With 
Pytohttps://www.youtube.com/channel/uccmxvj1uadepa1ekqqwxz4galan.vec...@gmail.com
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Pyto Implementation - GROWING TREND

[Grant Edwards]

On 2022-03-24, Steeve Kerou via Python-list  wrote:

> We develop Pyto - the first python class with an animated character
> that helps you learn the basics concepts of Python Language ...

Let me guess, the character is named "clipPy"?

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

Re: for convenience

[Avi Gross via Python-list]

Hopefully, adding to what Dave said, it helps to  understand there often are
choices and tradeoffs in everything and in particular to language design.

And choices propagate so that making choice A and B may box you in so at
some point choice Z is pretty much forced unless you start over and make
other choices.

Python made lots of choices early on and then tried to graft on ever more
features, sometimes well and sometimes not optimally. The same is true
for so many other languages. A carefully designed new language built now
might analyze and make changes.

I would even argue that a new language might deliberately include a
pre-processor that works more like Paul first assumed, perhaps as
something that could be turned on and off so it only operated on designated
sections or only when some command-line switch asked for it. Some might
use that, especially if migrating code from a language that had used similar
constructs. But preprocessors work best in compiled code where it is reasonable
to make multiple passes across a changing text but not so much in an
interpreted environment that tries to read and parse things once or in small 
defined chunks dynamically evaluated.

As it happens, Paul used what is not at all the same thing as what he has
seen elsewhere or that made intuitive sense to him but a Python feature that
can (among many other considerations already discussed) effectively
do something similar enough when used carefully.

But Languages, human as well as computer, can differ widely and yet seem
natural enough to most humans who grew up with them. One of my first human
languages is not big on "gender" and many sentences are exactly the same no
matter if it was being done by a male or female or anything else. So when I 
later
learned German with tons of grammar that included three genders, that was 
annoying.
Later I learned English and it seemed more civilized to me but in some ways not.
Is there really a right way to say put verbs first versus last  or place 
adjectives
before versus after what they modify? Well every darn language I learn has
differences in these ways including exceptions and special cases galore. And
even the choice of genders for words like "ship" or "road" vary widely across
languages. You either memorize or give up, or more likely, make lots of small
mistakes that mark you as a non-native speaker.

At some point, you accept it as it IS and work with it an realize the ones you
are talking to think it works fine and gets the job done. My first approach to 
French 
was to marvel at the weird spelling and how much of it does not seem to get 
pronounced.
It seemed worse than some other Romance languages in some regards.
But over time, I got used to it. It started to feel natural, not as in THE
right way but as one of many right ways that was right for the situation.

I approach computer languages similarly albeit most were not designed over
many centuries and influenced by invaders and so on. Features of the language
cannot be assumed to be exactly the same as other languages or even assumed
to be consistent in other ways. People have made many categorizations of
such features such as how memory is managed, whether variables that are
first used will default to zero or NULL or the empty string or just generate an 
error
if not initialized and on and on. You can build sort of decision trees showing
how several languages keep diverging from others in these abstract ways
as you reach a new decision point in such trees and choose a new path.

And interestingly, one reason there are so many languages out there is that 
people seem
to have chosen quite widely among alternatives. Some older languages that stop
being used may embody decisions that turned out to be too loose or restrictive 
or
simply because a new language seemed sexier and took over. Often it may be that 
programmers do not like the way it tries to force them to think about what they 
are
doing or that it makes it hard to do common things ...

So, in a sense, the learning process is worth studying as many facets of a 
language
that diverge from expectations are either not obvious or were taken after lots 
of deep
thought by others and make sense only once the person learning it has both 
learned 
some new things and sort of let go of old things.

Languages like Python are actually a bit more of a challenge. Like many modern
languages that have been overhauled to support multiple programming 
methods/styles
(like object-oriented and functional programming) and that have been extended 
with
endless add-ons with names like modules and packages, it seems anything you 
learn
may turn out to be "wrong" in the sense that others write code completely 
differently
than you first expected. You may learn base Python and think you use lists for 
all
kinds of things and maybe even lists of lists to emulate matrices, for example.

Then one day someone shows you a program done almost completely using modules
like numpy and pandas and 

Re: for convenience

[Chris Angelico]

On Fri, 25 Mar 2022 at 04:15, Avi Gross via Python-list
 wrote:
> Python made lots of choices early on and then tried to graft on ever more
> features, sometimes well and sometimes not optimally. The same is true
> for so many other languages. A carefully designed new language built now
> might analyze and make changes.

This is technically true, but it's important to keep in mind that it's
very difficult to understand the reasons behind all the choices in a
language, so if you were to craft your own language now, you would run
the risk of throwing away *good* decisions too.

> I would even argue that a new language might deliberately include a
> pre-processor that works more like Paul first assumed, perhaps as
> something that could be turned on and off so it only operated on designated
> sections or only when some command-line switch asked for it. Some might
> use that, especially if migrating code from a language that had used similar
> constructs. But preprocessors work best in compiled code where it is 
> reasonable
> to make multiple passes across a changing text but not so much in an
> interpreted environment that tries to read and parse things once or in small
> defined chunks dynamically evaluated.

No, I would say that a preprocessor of that sort isn't necessary to a
Python-like language. If you really want one, it's honestly not that
hard to do; remember, "preprocessor" means that it processes the
source code before the main language sees it, so you can do that even
with Python as it currently is.

But I suggest that a naive preprocessor like C's wouldn't be of much
benefit. Much more interesting is the possibility of designing a
language with a proper grammar, which you then compile to Python code
and execute.

(Part of the reason that a naive preprocessor wouldn't work well is
that it would play very badly with dynamic lookups. Good luck making
those work with a source-code transformation.)

> But Languages, human as well as computer, can differ widely and yet seem
> natural enough to most humans who grew up with them. One of my first human
> languages is not big on "gender" and many sentences are exactly the same no
> matter if it was being done by a male or female or anything else. So when I 
> later
> learned German with tons of grammar that included three genders, that was 
> annoying.
> Later I learned English and it seemed more civilized to me but in some ways 
> not.
> Is there really a right way to say put verbs first versus last  or place 
> adjectives
> before versus after what they modify? Well every darn language I learn has
> differences in these ways including exceptions and special cases galore. And
> even the choice of genders for words like "ship" or "road" vary widely across
> languages. You either memorize or give up, or more likely, make lots of small
> mistakes that mark you as a non-native speaker.

Yes, and despite what some people try to claim, they're not just all
the same thing with different symbols :) Languages ARE different,
different in real ways that make them good at different things.

> Languages like Python are actually a bit more of a challenge. Like many modern
> languages that have been overhauled to support multiple programming 
> methods/styles
> (like object-oriented and functional programming) and that have been extended 
> with
> endless add-ons with names like modules and packages, it seems anything you 
> learn
> may turn out to be "wrong" in the sense that others write code completely 
> differently
> than you first expected. You may learn base Python and think you use lists 
> for all
> kinds of things and maybe even lists of lists to emulate matrices, for 
> example.
>
> Then one day someone shows you a program done almost completely using modules
> like numpy and pandas and scipy and so on with bits and pieces of what looks 
> like
> python to glue it together. Some add-ons define entirely new mini-languages 
> whose
> rules only make sense within narrow areas and do not generalize.

To a very large degree, the rules are and must be the same regardless
of the library/module.

> It is very common
> to have half a dozen ways to do anything, like formatting stuff to print even 
> within the
> base language.

That's because formatting things into strings is such an incredibly
broad subject that it's best handled in multiple ways :) You could
equally say that there are half a dozen ways to do arithmetic, which
there are (or even more, in fact).

> This reminds me too much of a recent debate here on whether the word "ELSE" 
> means one
> thing versus another in a new context and I think we had to agree to 
> disagree. Clearly
> some of us are primed to see it one way and some the other and neither of 
> them is right
> but also there is NOW a right way to view the construct within Python because 
> it is what it
> is so get over it!

I think "if/else" and "try/else" are close enough that nobody should
have any concerns about it, and that "for/else" is 

Re: for convenience

[Grant Edwards]

On 2022-03-24, Chris Angelico  wrote:

> No, I would say that a preprocessor of that sort isn't necessary to a
> Python-like language. If you really want one, it's honestly not that
> hard to do; remember, "preprocessor" means that it processes the
> source code before the main language sees it, so you can do that even
> with Python as it currently is.

And they're best used to make it look like you're actually programming
in a different language. You can make your C program look like BASIC,
or your Python program look like Pascal!

The best part is that nobody else will be able to figure out WTH is
going on, even if they are fluent in _both_ of the languages!

Amaze your friends!

Turn complete strangers into enemies!

--
Grant

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

Re: for convenience

[Chris Angelico]

On Fri, 25 Mar 2022 at 06:05, Grant Edwards  wrote:
>
> On 2022-03-24, Chris Angelico  wrote:
>
> > No, I would say that a preprocessor of that sort isn't necessary to a
> > Python-like language. If you really want one, it's honestly not that
> > hard to do; remember, "preprocessor" means that it processes the
> > source code before the main language sees it, so you can do that even
> > with Python as it currently is.
>
> And they're best used to make it look like you're actually programming
> in a different language. You can make your C program look like BASIC,
> or your Python program look like Pascal!
>
> The best part is that nobody else will be able to figure out WTH is
> going on, even if they are fluent in _both_ of the languages!
>
> Amaze your friends!
>
> Turn complete strangers into enemies!
>

Yes! This is, in a sense, the counterpart to polyglot code, where the
same script can be run with any of several interpreters. Both are
extremely effective at turning people's brains to mush.

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

Re: for convenience

[Avi Gross via Python-list]

Chris:
> No, I would say that a preprocessor of that sort isn't necessary to a
> Python-like language. If you really want one, it's honestly not that
> hard to do; remember, "preprocessor" means that it processes the
> source code before the main language sees it, so you can do that even
> with Python as it currently is.

> But I suggest that a naive preprocessor like C's wouldn't be of much
> benefit. Much more interesting is the possibility of designing a
> language with a proper grammar, which you then compile to Python code
> and execute.

> (Part of the reason that a naive preprocessor wouldn't work well is
> that it would play very badly with dynamic lookups. Good luck making
> those work with a source-code transformation.)

Again, Chris, I tend to agree and my point was not that Python needs
some preprocessor stage but that if it did, then it might make transformations
more on a textual level like Paul initially expected.

But would it be helpful? Maybe. I am thinking back to decades ago when I
did C and C++ programming and how we used it. It was way more that just:

#DEFINE TIMEZONE 5

The above use is sort of to create a constant. What we often used was ways
to customize the code so different code would be compiled say when testing
or to work one way on machine A with operating system A' versus machines
B and C, perhaps with different needs and abilities. Sometimes all kinds
of features only made it into one version of the other. The compiler saw
different code each time.

I have also written many things that effectively are read by an early stage
and selected regions are parsed and replaced with code in another language
so that by the time a compiler or interpreter sees it, ...

So sure, you could write code that reads fileA.py and outputs fileB.py and only
run fileB through the interpreter. Yes, instead of making versions which have 
all
kinds of text written in various languages, you could just have the python code
read in various files at run time or other techniques.

-Original Message-
From: Chris Angelico 
To: python-list@python.org 
Sent: Thu, Mar 24, 2022 1:37 pm
Subject: Re: for convenience


On Fri, 25 Mar 2022 at 04:15, Avi Gross via Python-list
 wrote:
> Python made lots of choices early on and then tried to graft on ever more
> features, sometimes well and sometimes not optimally. The same is true
> for so many other languages. A carefully designed new language built now
> might analyze and make changes.

This is technically true, but it's important to keep in mind that it's
very difficult to understand the reasons behind all the choices in a
language, so if you were to craft your own language now, you would run
the risk of throwing away *good* decisions too.

> I would even argue that a new language might deliberately include a
> pre-processor that works more like Paul first assumed, perhaps as
> something that could be turned on and off so it only operated on designated
> sections or only when some command-line switch asked for it. Some might
> use that, especially if migrating code from a language that had used similar
> constructs. But preprocessors work best in compiled code where it is 
> reasonable
> to make multiple passes across a changing text but not so much in an
> interpreted environment that tries to read and parse things once or in small
> defined chunks dynamically evaluated.

No, I would say that a preprocessor of that sort isn't necessary to a
Python-like language. If you really want one, it's honestly not that
hard to do; remember, "preprocessor" means that it processes the
source code before the main language sees it, so you can do that even
with Python as it currently is.

But I suggest that a naive preprocessor like C's wouldn't be of much
benefit. Much more interesting is the possibility of designing a
language with a proper grammar, which you then compile to Python code
and execute.

(Part of the reason that a naive preprocessor wouldn't work well is
that it would play very badly with dynamic lookups. Good luck making
those work with a source-code transformation.)

> But Languages, human as well as computer, can differ widely and yet seem
> natural enough to most humans who grew up with them. One of my first human
> languages is not big on "gender" and many sentences are exactly the same no
> matter if it was being done by a male or female or anything else. So when I 
> later
> learned German with tons of grammar that included three genders, that was 
> annoying.
> Later I learned English and it seemed more civilized to me but in some ways 
> not.
> Is there really a right way to say put verbs first versus last  or place 
> adjectives
> before versus after what they modify? Well every darn language I learn has
> differences in these ways including exceptions and special cases galore. And
> even the choice of genders for words like "ship" or "road" vary widely across
> languages. You either memorize or give up, or more likely, make lots of small
> mista

Re: for convenience

[Chris Angelico]

On Fri, 25 Mar 2022 at 10:44, Avi Gross  wrote:
> But would it be helpful? Maybe. I am thinking back to decades ago when I
> did C and C++ programming and how we used it. It was way more that just:
>
> #DEFINE TIMEZONE 5
>
> The above use is sort of to create a constant. What we often used was ways
> to customize the code so different code would be compiled say when testing
> or to work one way on machine A with operating system A' versus machines
> B and C, perhaps with different needs and abilities. Sometimes all kinds
> of features only made it into one version of the other. The compiler saw
> different code each time.

Yes, I'm aware of how it was used... but to what extent is that
actually necessary in Python? When do you ever need something that you
can't do with simple conditional function definition or something of
the sort?

Textual manipulation lets you create all manner of nightmares. A lot
of them are acceptable evils because of the benefits gained, but you'd
be hard-pressed to pitch those same benefits to Python programmers,
where most of the differences are already handled by (eg) the
functions in the os module.

> I have also written many things that effectively are read by an early stage
> and selected regions are parsed and replaced with code in another language
> so that by the time a compiler or interpreter sees it, ...
>
> So sure, you could write code that reads fileA.py and outputs fileB.py and 
> only
> run fileB through the interpreter. Yes, instead of making versions which have 
> all
> kinds of text written in various languages, you could just have the python 
> code
> read in various files at run time or other techniques.

And that's what I meant by having your own preprocessor. I've done
various DSLs that way, having something that effectively compiles to
Python code. (I've also used Python to write preprocessors for things
in other languages, since Python is excellent at text manipulation and
even has things like JavaScript lexers available on PyPI.)

But the best of these are NOT things that the C preprocessor would be
capable of. They can have arbitrarily complex levels of syntactic
comprehension, making them far safer to work with.

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

Re: for convenience

[Avi Gross via Python-list]

Chris:
> To a very large degree, the rules are and must be the same regardless
> of the library/module.

I may not have been clear. I am aware of all kinds of mini-languages such
as various forms of regular expressions where some string contains a fairly
complex program using existing symbols like [~* and so on with no real
relationship to the language being employed. You can often write code
using an identical regular expression and use it with functions in Python,
Perl, R, C++ and lots of other languages. Similarly, the printf() family has a 
guiding
string that uses symbols like % and : and others as a sort of mini language
that is often independent of the language it is being used in. Yes, some
languages contain functions that only support a subset of functionality
or a superset. For example, some allow you to specify an argument
that you want Perl-style matching enhancements.

So, no, I do not think what I was talking about is necessarily completely
the same as what the main language uses. And another example is how
you can sometimes change the underlying language at run time by all
kinds of techniques such as replacing built-in functions, and in languages
like R, creating all kinds of new functionality as in the pipes I mentioned
including brand new top-level operators or back in Python, tricks like 
making a new class inherit from a standard class that then over-rides and 
augments or even plays games with multiple inheritance.

I will agree that fundamentally the overall infrastructure seems the same.

But in my view, some changes step out of the original language.

As I have also mentioned, there are ways to get a program to perform
calculations in a shared way with two or more languages with data
moving back and forth as needed. Definitely that example, which I
sometimes use in my programming, literally jumps out of the initial
language.



-Original Message-
From: Chris Angelico 
To: python-list@python.org 
Sent: Thu, Mar 24, 2022 1:37 pm
Subject: Re: for convenience


On Fri, 25 Mar 2022 at 04:15, Avi Gross via Python-list
 wrote:
> Python made lots of choices early on and then tried to graft on ever more
> features, sometimes well and sometimes not optimally. The same is true
> for so many other languages. A carefully designed new language built now
> might analyze and make changes.

This is technically true, but it's important to keep in mind that it's
very difficult to understand the reasons behind all the choices in a
language, so if you were to craft your own language now, you would run
the risk of throwing away *good* decisions too.

> I would even argue that a new language might deliberately include a
> pre-processor that works more like Paul first assumed, perhaps as
> something that could be turned on and off so it only operated on designated
> sections or only when some command-line switch asked for it. Some might
> use that, especially if migrating code from a language that had used similar
> constructs. But preprocessors work best in compiled code where it is 
> reasonable
> to make multiple passes across a changing text but not so much in an
> interpreted environment that tries to read and parse things once or in small
> defined chunks dynamically evaluated.

No, I would say that a preprocessor of that sort isn't necessary to a
Python-like language. If you really want one, it's honestly not that
hard to do; remember, "preprocessor" means that it processes the
source code before the main language sees it, so you can do that even
with Python as it currently is.

But I suggest that a naive preprocessor like C's wouldn't be of much
benefit. Much more interesting is the possibility of designing a
language with a proper grammar, which you then compile to Python code
and execute.

(Part of the reason that a naive preprocessor wouldn't work well is
that it would play very badly with dynamic lookups. Good luck making
those work with a source-code transformation.)

> But Languages, human as well as computer, can differ widely and yet seem
> natural enough to most humans who grew up with them. One of my first human
> languages is not big on "gender" and many sentences are exactly the same no
> matter if it was being done by a male or female or anything else. So when I 
> later
> learned German with tons of grammar that included three genders, that was 
> annoying.
> Later I learned English and it seemed more civilized to me but in some ways 
> not.
> Is there really a right way to say put verbs first versus last  or place 
> adjectives
> before versus after what they modify? Well every darn language I learn has
> differences in these ways including exceptions and special cases galore. And
> even the choice of genders for words like "ship" or "road" vary widely across
> languages. You either memorize or give up, or more likely, make lots of small
> mistakes that mark you as a non-native speaker.

Yes, and despite what some people try to claim, they're not just all
the same thing with d

Re: for convenience

[Avi Gross via Python-list]

Yes, Chris, you can do all kinds of useful things in Python and I can not make 
much of
a case for requiring a pre-processor. The main reason would be to make code
that interprets faster or produces a smaller file of Python commands.

All I was saying was that there might be a scenario where a textual replacement
method could happen the way Paul sort of guessed.

I note that some Python files can be partially processed once into bytecode and 
then
run many times. That may be a level where a preprocessor phase might customize 
it
better so what runs is already half-configured.

And as noted, anyone porting code from another language where the code is
already segmented with #IFDEF statements and other such fairly primitive
methods might have to work harder to move that too into their Python program.

I vaguely recall having to write such a preprocessor once upon a time as an 
exercise
for a programming class and it definitely would have been much easier to do in
Python. 


-Original Message-
From: Chris Angelico 
To: python-list@python.org 
Sent: Thu, Mar 24, 2022 7:57 pm
Subject: Re: for convenience


On Fri, 25 Mar 2022 at 10:44, Avi Gross  wrote:
> But would it be helpful? Maybe. I am thinking back to decades ago when I
> did C and C++ programming and how we used it. It was way more that just:
>
> #DEFINE TIMEZONE 5
>
> The above use is sort of to create a constant. What we often used was ways
> to customize the code so different code would be compiled say when testing
> or to work one way on machine A with operating system A' versus machines
> B and C, perhaps with different needs and abilities. Sometimes all kinds
> of features only made it into one version of the other. The compiler saw
> different code each time.

Yes, I'm aware of how it was used... but to what extent is that
actually necessary in Python? When do you ever need something that you
can't do with simple conditional function definition or something of
the sort?

Textual manipulation lets you create all manner of nightmares. A lot
of them are acceptable evils because of the benefits gained, but you'd
be hard-pressed to pitch those same benefits to Python programmers,
where most of the differences are already handled by (eg) the
functions in the os module.

> I have also written many things that effectively are read by an early stage
> and selected regions are parsed and replaced with code in another language
> so that by the time a compiler or interpreter sees it, ...
>
> So sure, you could write code that reads fileA.py and outputs fileB.py and 
> only
> run fileB through the interpreter. Yes, instead of making versions which have 
> all
> kinds of text written in various languages, you could just have the python 
> code
> read in various files at run time or other techniques.

And that's what I meant by having your own preprocessor. I've done
various DSLs that way, having something that effectively compiles to
Python code. (I've also used Python to write preprocessors for things
in other languages, since Python is excellent at text manipulation and
even has things like JavaScript lexers available on PyPI.)

But the best of these are NOT things that the C preprocessor would be
capable of. They can have arbitrarily complex levels of syntactic
comprehension, making them far safer to work with.


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

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