[Python-Dev] Re: Some pattern annoyance

[Stephen J. Turnbull]

Christian Tismer-Sperling writes:

 > I thought this list would always stay intact as an alternatice
 > to the web things. How sad!

The list is alive.  You got an immediate answer, did you not?  It's
just that almost all of the people who are engaged with discussion
every day have found alternative platforms more productive.

Partly because that's where the other discussants are (the network
externality is undeniably powerful), and partly (I believe) because
effective use of email is a skill that requires effort to acquire.
Popular mail clients are designed to be popular, not to make that
expertise easy to acquire and exercise.  Clunky use of email makes
lists much less pleasant for everyone than they could be.

I guess that's sad (I am, after all, a GNU Mailman developer), but
it's reality.

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7IBBTTSI3Q3WX3MXBGMFJ2GKX6MTE67V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 638: Syntactic macros

[Stephen J. Turnbull]

Stéfane Fermigier writes:

 > NB: on a very basic level, I remember trying, a few years ago, to use the
 > Unicode "empty set" symbol as a synonym for set(), and it didn't end well,
 > for several reasons, including the fact that Python didn't like it as a
 > variable name.

I know about the issue that '∅' is not valid in identifiers, but I'm
curious about these other "several reasons".



___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7OHL242ZWVOYTBKTZOC72PQK5V4BKX2I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 638: Syntactic macros

[Stephen J. Turnbull]

cd...@cam.ac.uk writes:

 > I think that's exactly the problem with a lack of Python
 > macros. The full quote, of course, goes: "There should be one-- and
 > preferably only one --*obvious* way to do it."

You understand that the Zen is humorous?  Most of the Zen, if taken
universally and seriously, advocates the impossible.  And as a whole,
it's definitely impossible even in the limited scope it's intended to
apply to -- it's internally inconsistent.

 > Often, there's a mathematical notation for something, and *this* is
 > the only obvious way to write anything out.

But that's not the way Python looks at it, you see.  First, "a"
mathematical notation doesn't exclude multiple notations, and for most
mathematical concepts there are indeed multiple common notations (eg,
for multiplication, juxtaposition of the factors, *, ・, and × are all
in common use depending on the kind of multiplication).  I'm pretty
sure Tim Peters was well aware of such.  Frequently the most commonly
used expressions are really ugly (at least in my experience in
mathematical applications to game theory ;-).  Now, you can recover
your position from that issue by appealing to other more or less Zen
desiderata (readability counts, for example), but they're not quite as
strong arguments here.

The second objection is more serious: the Zen is intended to be
restricted to Python.  "There should be one-- and preferably only one
--obvious way to do it [*in Python*]."  Guido (and the other OG core
devs) wanted consistent and obvious ways to do it *in Python*.  The
consistent and obvious way to write "X ~ N(0,1)" (oops, not so obvious
after all!) in Python is "X = Normal(0,1)", where presumably the
Normal class provides facilities such as CDF and PDF as well as the
PRNG of random.normalvariate.

 > Not to mention, DSLs are forced to adopt all kinds of weird syntax

This is more or less intentional, though, as is the restriction to a
predefined set of operator symbols (you can't define ・ as an operator
symbol when you need two kinds of multiplication for example).  Python
has consistently refused to be turned into a platform for DSLs for
almost 3 decades.  Ruby and Lisps are better for that.

You don't have to like that (quite a few people don't, of course
that's why MacroPy was written), but it's really not un-Pythonic.
There is method to this madness: Python aims for readability and
flexibility for the community of Python programmers who might
encounter the code, rather than catering to authors and their domain
specialist community.  The fact that Python adoption is still growing
should tell you something about the preferences and needs of the
general Python community.

 > I don't want to be forced to learn lots of weird little functions
 > like `np.matmul(x1, x2)` when there's already one obvious syntax
 > I'm very familiar with: `x1 * x2`.

I don't recall ever writing matrix multiplication that way in
mathematics though.  That's universally written as juxtaposition in my
experience.  And the obvious way to write it in Python (and np) has
been "x1 @ x2" for some years now.  In np, "*" means element-wise
multiplication, I believe.

Perhaps some BDFL will arise to merge the benefits of Python with
those of Julia, but for the near term we're all going to have to
choose one or the other.

Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/D2427HD63JN5MTBFQL2SZFBJU3UEXE3L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 638: Syntactic macros

[Stephen J. Turnbull]

Joshua Herman writes:

 > I think that this would be better as a library in my opinion. 

There's a third party package called MacroPy that provides macros,
although I haven't heard anything about it in a couple of years.

I seem to recall that it's a preprocessor that hooks into the import
system.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VRY55MMVRVZGHJRPPWWHKHLPPI2HLHZR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [Suspected Spam]Requesting a review on a PR

[Stephen J. Turnbull]

Wheeler Law writes:

 > I opened an issue[1] related to respecting the
 > `http.client.HTTPConnection.debuglevel` value; I opened a
 > subsequent PR[2] that fixes the issue back in November and I was
 > wondering if I could get some feedback on it.

I can't help you with that, but this list is now pretty much
deprecated in favor of developer channels on discuss.python.org.
Sorry I can't be more help in directing you to which channel, I
haven't been following dev closely for quite a while (still hoping to
get back into it though!)


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/E4WE3B6VQKWV7WAWSBRIFD3NO6MSVH4H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] C- Python on Windows

[Stephen J. Turnbull]

Guenther Sohler writes:

Hi, Guenther!

 > I have successfully used C-Python (3) in a software project in unix and its
 > great stuff!
 > The environment was cmake using g++ in Linux

Congratulations!

 > Now when i want to get my project compiled in windows, whats the easiest
 > development chain ?

That depends.  One option is one of the environments (MSYS or Cygwin)
based on the GNU compiler chain.  There is a python DLL supplied in
the Windows environment.  Mingwin (+ MSYS?) should work with that, I'm
not sure if Cygwin does.  Cygwin is more Unix-like, Mingwin is just a
GNU compiler chain for Windows.  The other is the standard (and I
believe free) Visual C compiler from Microsoft.

Try https://docs.python.org/3/ for the docs you want: "Extending and
Embedding" and "Python/C API".

By the way, this isn't the appropriate place for this question.  This
list is for development discussion of Python itself, and in fact is
very close to being phased out in favor of forums on discuss.python.org.

For further discussion, you probably want the "python-l...@python.org"
mailing list, or the "python help" "discuss" channel for "development
*with* Python" questions.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WWLI6KODY6PSVANNXI3V4JK7DUQ5U7GD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Stephen J. Turnbull]

Cameron Simpson writes:

 > I'm presuming we're talking about ways to bidirectionally mirror between 
 > mailman and a Discourse forum.

Yes.

 > None of that is easy to fix - mailing lists essentially just forward 
 > messages, with some gatewaying of what messages they allow inbound 
 > depending on the list. By contrast, Discourse posts have authors which 
 > must be Discourse users.

That's not a problem in principle, because Mailman at python.org
insists on list membership for posts.  It could be a minor annoyance
for users because Mailman allows a user to have a variety of email
addresses, so you actually have to check which address you've been
using.  Perhaps people with multiple Mailman subscriptions would have
to reconfigure their so they all use the address that Discourse knows,
and their Mailman subscriptions to access mail from that address.  I
don't think that's a big deal, but it's there.

 > I suspect any `In-Reply-To` or `References` would be ignored.

That could be problematic.  Not sure about that.

 > For replies, the email goes to a post-specific address which is used to 
 > stitch the message into an existing Topic discussion thread.

This could work!  I guess for "to message" replies it would cut
Mailman out of the loop (the reply would go author -> Discourse ->
Mailman), so it might be a little odd in the user's mail client and in
Mailman archives (assuming they were desired and permitted).

 > The outgoing `In-Reply-To` and `References` headers are made on the
 > fly when Discourse sends the post as email to whichever users are
 > set up to receive an email copy. The source `Message-ID` is
 > preserved.

I don't see why that would be a big problem.  Threading would be a
little less robust, but would work 99% as well as with full
References.

 > Letting _nonDiscourse_ users reply or post to Discourse is not
 > trivial.

I don't think that would be desired.  It would be nice for users if
existing Mailman User addresses could be grandfathered into Discourse
just to save them ten minutes navigating the Discourse signup, but
it's not obvious to me that's desirable or desired by Discourse
admins.  On the other hand, Discourse's members-only policy is
basically the same as Mailman's, so we'd probably lose a boatload of
python-dev lurkers, but nobody can complain about the principle.

Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/K22PHXRTDV24WA5QAXO2PB46DEXTA3V4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Stephen J. Turnbull]

Baptiste Carvello writes:

 > There is a small catch though: unless I'm mistaken, Discourse won't let
 > you subscribe to just a set of categories, so any filtering has to
 > happen on the Mailman side.

There are two approaches that come to mind.  The first is
list-per-category, which would most efficiently be implemented in the
MTA, but could be implemented in Mailman, either with existing spam-
filtering or with a bit of code in a custom Rule.  This would make
sense if categories change slowly and have substantial traffic,
because creating a new list requires admin intervention at a high
level (moderators can't do it, list owners can't do it).

The second would be to use a feature called topics.  Changing topics
also requires admin intervention, but list owners can do it.  Also, in
the case of creation of a new category, individual users can access it
immediately by using the archives (which don't respect topics IIRC,
never used them myself) or by subscribing to the "no topic" topic
(which normally defaults off, again IIRC -- if not, that can be
changed by the list owner IIRC, if not, a trivial patch).

 > If we wanted an equivalent of python-list, we could just forgo the
 > filtering and pass on posts from all Discourse categories. But for
 > python-dev, the volume is too high, and existing python-dev subscribers
 > probably don't want a category like "Help".

That seem accurate to me.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XWZXKW2JQBWD2BGNIGQ2KGN4CBUEY52C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Stephen J. Turnbull]

Ethan Furman writes:

 > It seems to me the best possible outcome of Discourse vs email is
 > somebody / some company donating the time and/or funding to improve
 > Discourse's and Mailman's abilities to interoperate with each
 > other.

There are fundamental differences between email's aysnchronous
message streams and Discourse's enforced single message stream.  These
can't be perfectly reconciled, despite how fast email can be nowadays.

Since Mailman (and its users!) expects messages to arrive
asynchronously and handles that using threading information, as far as
I can see the Mailman side is handled as well as it can be now that
Discourse provides threading information, and you just subscribe
Mailman to Discourse.  And obviously we can just sign up Discourse to
Mailman.  The latter direction may be harder, depending on whether
Discourse can make sense of batches of messages being composed
independently of its message flow.  The fact that Discourse didn't
provide threading information to email users in the past suggest that
it has an alternative mechanism for organizing mail flows, and message
IDs and Reference headers from email may not be so easily integrated.

I know nothing about Discourse internals, but I suspect that's going
to be the difficult part if there is one.  With a little luck that
will be no problem. ;-)

Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3KS5YF7YQZ2M75KYGI34TMI7LAEE2ACM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Stephen J. Turnbull]

Barry Warsaw writes:
 > I absolutely love not having to slog through hundreds of emails
 > before my first shots of caffeine, and I can now pull from
 > Discourse or GH when it’s convenient for me.  It’s also much easier
 > to disengage for a few days and catch up later.

I absolutely cannot imagine slogging through hundreds of posts in the
Discourse interface.  Couldn't this be, as Baptiste suggests, a
symptom of people disengaging and there just being less traffic?  Or
is it somehow being channeled better so that you're only seeing what
interests you now?

In particular I have to suspect that a boatload of those were
python-committers mails that are now basically obsolete (can't say, I
never have sought enough responsibility that I needed to subscribe to
that firehose).  But that would help with python-dev/ideas too.

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FXEMP65SFVKPVYDOSQ4COTS3V6MX7MPO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Stephen J. Turnbull]

Baptiste Carvello writes:
 > Le 05/12/2022 à 14:50, Stephen J. Turnbull a écrit :
 > >
 > >  I'd be sad, but I get the feeling that the only people left
 > > reading it are "here for the community", not to develop code, …

 > I think this is indeed true, but that's nothing to be sad about:

I'm sad because of the prospect of shutting down the list, because

 > "being here for the community" is not wrong or shameful.

Far from it!  It's why I'm here.

 > Now maybe this is a place where the mailman devs could help and make a
 > real difference: what if this list would become, not archive-only, but a
 > *read-only mirror* of those parts of Discourse that are relevant for
 > core development? That would mean setting up a pipeline starting with
 > Discourse's so-called "mailing-list mode", going through the kind of
 > filter stack that some core developers have been setting up for their
 > personal use, and feeding into this mailing list. The last part can only
 > be done with the powers of the mailman admins.

The only thing in what you've described that requires admin powers is
shutting off the default ability to post, and then enabling Discourse
to post.  None of this *requires* the help of Mailman devs.

 > Turning this list into a relevant mirror of Discourse is the nicest
 > course of action for the hundreds of silent readers python-dev has
 > gathered over the years.

This does seem like an approach that gives 95% of everybody at least
95% of what they want.  (In the other 5% of everybody there are the
core devs who strongly prefer email, a constituency important beyond
their numbers, but to do their work they need to communicate with
other core devs and it seems likely 90% of them will be on Discourse,
so)

Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GQRZ4G7AUXL3FSM33JYQSLPB7DBZ77L5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Stephen J. Turnbull]

Barney Gale writes:

 > I did; I think it was a mistake to start discourse without a plan for
 > shutting down this mailing list.

"Start"?  When it was started it was an experiment.  Nobody had a
strong take on whether Discourse would really take off or not, or even
whether there might be a dual-channel mode (admittedly that was
relatively unlikely IMO then).  Planning to shut down the mailing list
wasn't a good idea.

Pretty quickly a lot of conversations moved to Discourse (surprisingly
to me).  But there was still a fair amount of resistance, and a number
of people requested at minimum better threading for the Discourse mail
interface, which took a while but eventually was accomplished.  IMO
its only been in the last 4-6 months that shutting down Python-Dev
became a realistic option, as traffic disappeared and the biggest
common complaint about Discourse was mostly resolved[1].

AFAICS the biggest issue with keeping Python-Dev is that it allows the
hope that dev conversations will return to email, and that just seems
unlikely to me.  A few people will try to use it, and they'll be
directed to Discourse after short conversations.  The only real cost I
see is to the admins, and that's almost zero for the site admin.  I
can't speak to the cost to moderators.  If they're sick of it, I'd say
we can make the list read-only (ie, archive-only) pretty much any
time.  I'd be sad, but I get the feeling that the only people left
reading it are "here for the community", not to develop code, which is
happening over on Discourse.

I'm sure it would be easy[2] to modify the list of moderation options so
that moderators can with discard spam, or send a canned "go post on
Discourse, here's an introduction to Python Discourse" message to
RealPeople[tm].


Footnotes: 
[1]  That's maybe a little unfair.  As a Mailman dev and mailing list
fan, I've thought a lot about this, and I believe there is a fundamental
difference between the completely asynchronous mail protocol and the
much more synchronous messaging protocol imposed by most forum
software, specifically Discourse.

[2]  Mailman devs would help, obviously we love Python and would be
happy to contribute back.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/GPZK7G62R4BEYTIQVG24IJ6XWPPTTOCN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How about using modern C++ in development of CPython ?

[Stephen J. Turnbull]

Denis Kotov writes:

 > For example, PyObject is much better to implement using C++ class,
 > it will bring RAII that will reduce number of issues not free
 > memory in CPython

Well, yes, that's the C++ Kool-Aid we're all supposed to drink.  But
it has its costs, too.  How does it affect performance?  How does it
interact with slots, __new__, metaclasses, and other features of the
Python class hierarchy, especially when coded as C?  What about
translating all of the accelerated modules written in C using the
existing stable ABI?  Have you looked at how this would affect NumPy,
Pandas, and cffi?  That's just a bunch of random related software,
there are plenty of others (not to mention non-public software that
neither of us has access to that may be affected).

Really, you need to bring new information specific to Python rather
than this generic "C++ is great" advocacy.

 > See:
 > https://youtube.com/clip/UgkxyNe_dsZKinT_RT3UGb-BaP0SnvKteo2o

No thanks, if it's not text I'm not going to look at it.  I don't have
time to watch videos with no explanation, and best guess is 90% of it
I already know, just as I don't think you've yet written anything I
didn't already know.

 > Without RAII - introduced the most dangerous errors !!

List the CVEs.  I'll happily go read those!

Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/67LM5JNOLSI4NASTXRTF4JXT6JMN2UFO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Stephen J. Turnbull]

Terry Reedy writes:
 > On 7/21/2022 8:46 PM, Christopher Barker wrote:

 > > Does anyone else find it very odd to call a communication system “discord”?

 > For games, most of which involve combat, it seems appropriate.  For 
 > CPython development, 'harmony' might be better.

Already taken by the GNU Mailman community:
https://www.mailmanhost.com

:-)

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FV7A2CMATJUEYSDLBJZN4AIHNKI5NTID/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Stephen J. Turnbull]

Cameron Simpson writes:
 > On 21Jul2022 17:46, Christopher Barker  wrote:
 > >OT:
 > >Does anyone else find it very odd to call a communication system 
 > >“discord”?
 > 
 > I think it is a refreshing level of honesty about what live chat is 
 > like. As in "discordant".

I would refine "live chat" to "full-duplex multicast media"
(especially with rampant pseudonymity).  Email included. ;-)

-- 
Ask me about RFCs 5321 and 5322!

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DIXTC74HU5B3IDUHACEYJTFDVENG3WQL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Stephen J. Turnbull]

Cameron Simpson writes:

 > Discourse does not do `In-Reply-To:` very well at all. Here's some 
 > headers from the _second_ post in the "Core dev sprint this year" 
 > thread:
 > 
 > Message-ID: 
 > 
 > In-Reply-To: 
 > References: 

I'm tempted to write something uncivil, but instead I'm gonna go hug a
puppy and weep.

 > So at present Discourse's email implementation is buggy. I need to 
 > submit a bug report.

Thank you!

You may find it useful to cite RFC 5322, section 3.6.4, and emphasize
"unique" while mentioning the algorithm for populating References and
In-Reply-To presented there.

 > _However_, someone participating in "email mode" will of course send a 
 > message with its own distinct message-id from their source system, and 
 > that does not survive the email->discourse->email-out process. [...]
 > I don't expect that to change. 

That's just plain obnoxious.  Anybody who's in the CCs who
participates in "email mode" will get (practically speaking)
unfilterable duplicates, and (if there is offline discussion) a bogus
new thread.

I wonder if this goes all the way through to the backend database (ie,
 the only id a message gets are its thread id, a timestamp, and some
way to ensure a total order in the case of equal timestamps), and the
only place in Discourse where the unique Message-ID appears is in the
outgoing message.  In that case getting any sanity in Discourse email
could be very expensive for Discourse.

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FPSDSMP3NEV7K6ATTTS4ZQXDRZACF2OE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Stephen J. Turnbull]

Eric Snow writes:

 > I consider the ability to search message archives to be essential to
 > effective contribution[.]

+1

 > There are relevant three aspects to archival and search that are worth
 > asking about here:
 > 
 > 1. search functionality on the [archive] web site
 > 2. ability to search using other tools (e.g. my favorite: Google
 > search with "site:...")
 > 3. single archive vs. split archive

I can't speak to 1 and 2, and I can't speak to cost of resource usage
for 3, but it would be possible to have a Mailman list that has no
subscribers, prohibits subscription, and allows only a small number of
authorized posters, one of which would be the Discourse mail feed.  As
long as Discourse provides the In-Reply-To header field, the current
threading algorithm would work reasonably well.  I guess we would also
want to disable replies in HyperKitty (maybe that's already a
consequence of "no subscribers"?)  I don't know how hard that would
be.

Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WJGDTT4XKN25HO6JNI3GRPVKBNVAHPSD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Presenting PEP 695: Type Parameter Syntax

[Stephen J. Turnbull]

Paul Ganssle writes:

 > If you didn't already know what the square brackets did, how would
 > you try and find out?

First I'd look it up in Python Essential Reference (Hi, @dabeaz! it
won't be there, though ;-).  Then I'd go to the Language Reference for
"def" and "class".  And if that failed, then I'd go buy Barry Warsaw
lunch.

OK, not everybody has a personal relationship with senior core devs,
but is asking people to read the Language Reference really so bad?

 > An additional benefit is that I find some of these examples to be a bit 
 > visually cluttered with all the syntax:
 > 
 > def  func1[T](a:  T)  ->  T:  ...   # OK
 > class ClassA[S, T](Protocol): ... # OK

Looks like the boomer version (square*) of C++ template variables.  Of
course, people learn Python to escape from C++, so maybe that's not
persuasive.

* telling you how old I am without telling you how old I am

 > Which would look less cluttered with a prefix clause:
 > 
 > @with type T def  func1(a:  T)  ->  T:  ...   # OK
 > @with type S @with type T class ClassA(Protocol): ... # OK

For me, that's absolutely awful from a readability standpoint.  Put
the "def" or "class" 10-20 characters in from the margin?

I guess "stacked" it's no less readable than any decorator, but I also
don't like overloading the well-defined decorator notation with magic.

@with type T
def  func1(a:  T)  ->  T:  ...   # OK

@with type S
@with type T
class ClassA(Protocol): ... # OK

A thought: would it be possible to actually make it a with statement?

with Typevar() as T:
def func1(a: T) -> T

Of course there might have to be magic in Typevar, but it would be far
more palatable to me than giving unary @ two kinds of magic.

IMO YMMV of course.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UTVCFIZ4CM3362JANAOBPEGJUTAWKSCI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] The cursed fourth Python 3.11 beta (3.11.0b4) is available

[Stephen J. Turnbull]

Samuel Colvin writes:

 > Overall, I agree we should be using ISO8601 for exactly this reason (at
 > least for dates, for datetimes ISO8601 gets pretty wacky
 > )

I have never had a use for anything but -mm-ddThh:mm:ss (and very
occasionally -mm-ddZhh:mm:ss for international coordination).
What's wacky about that?  It's not terribly human-readable, but for
humans you can substitute a space for T (Z) and append a timezone or
offset if you want to disambiguate.

Sure, there is lots of optional syntax in ISO 8601, but when does one
need the wacky stuff in a release announcement?

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IJXHA6YZVHKVTYTI2SO3OG7HUYVGASIP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [RELEASE] The cursed fourth Python 3.11 beta (3.11.0b4) is available

[Stephen J. Turnbull]

Alan G. Isaac writes:

 > 4. It implements ISO 8601 (which exists for a reason):
 > https://en.wikipedia.org/wiki/ISO_8601#Calendar_dates

Yes!!!  "Standardization is my Valentine!" :-D

-- 
RIP WotR Bombshell
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/O7EKVHRG3GGAHYGQEPCUMPPYU5S67FGO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 689 – Unstable C API tier (was: Semi-stable C API tier)

[Stephen J. Turnbull]

Sasha Kacanski writes:

 > Why you don't simplify with api A,B,C and  forth and then follows
 > explanation ofr what is stable, unstable, semi... So forth

This is exactly what they're hammering out.  It's not easy for several
reasons, chief of which is that in each case the boundary is a matter
of opinion as to the balance among what is most convenient for the
developers of Python itself, the developers of separately distributed
C/C++ modules, and for existing modules that were developed before the
divisions were set and would need to either be changed or to risk
API incompatibility with future versions of Python.  The nomenclature
also matters, as individual programmers have various ideas about the
meaning of terms like "stable", and we want as much agreement as
possible that the "stable API" is "stable enough", and so on.

If you have specific ideas about which APIs belong where, feel free to
bring them forward.  But this is not a process that should be rushed
nor would anyone benefit from pushing it forward more quickly.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3TDSVISHIV7PZPRDAI5ZRHNZYARH6J3O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How about using modern C++ in development of CPython ?

[Stephen J. Turnbull]

Denis Kotov writes:

 > Yes, C++ ABI is specific to each compiler, but it is not a problem,
 > because you will anyway recompile CPython for each compiler !!

Right, but the point is that we want few C++ compilers people really
use to get upset by Python code.  Since most changes are backward
compatible (or new compilers may have a backward compatibility option)
specifying an older standard accomplishes that goal.

 > Usually people say that C++ not fit in CPython not knowing C++,

That's not the issue.  There are plenty of people who know C++ who say
the benefits of C++ are not worth the bugs, the effort, and the plain
old churn that a rewrite in C++ (even if incremental) would require.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XLVVIUVBYLXFQYPRMHY5H3ZRGDCYB45W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How about using modern C++ in development of CPython ?

[Stephen J. Turnbull]

Denis Kotov writes:

 > From huge codebase experience with C++, it does not cause
 > significantly better (1) Readabillity or (2) Maintainability on its
 > own compared to C

But that's not what we're talking about.  "Port CPython to C++" is a
perennial suggestion that gets rejected fairly quickly, as the C++
stdlib equivalent structures and functions in CPython are efficient
and well-tested.  I don't know much about Rust but I know that some
core modules have already been ported to Rust.  Since core devs, with
a specific reason (security, it's crypto stuff) to move away from C
are involved in that effort I would guess that movint to Rust is far
more likely than to C++.

The point of C++ standard support level is linking CPython to external
codebases using C++, and at least for the standard CPython currently
supports, the C++ ABI is specific to each compiler and version (for
some compilers), right?

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EZ7B7SL233QTMN6GEEA4SJDHIBGFIEIC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 689 – Semi-stable C API tier

[Stephen J. Turnbull]

MRAB writes:
 > On 2022-04-29 18:02, Guido van Rossum wrote:
 > > On Fri, Apr 29, 2022 at 10:15 AM Petr Viktorin  > > wrote:
 > > 
 > > On 29. 04. 22 16:32, Victor Stinner wrote:
 > >  > Ok, let me start with the serious business: API name.
 > >  >
 > >  > I'm not comfortable with "semi-stable". Python already has a 
 > > "limited
 > >  > API" and a "stable ABI". Just by its name, it's unclear what
 > >  > "semi-stable" means.
 > >  >
 > >  > Honestly, I would be more comfortable with the name: "unstable API".
 > >  > It would be clear that the API *can* change often. People who want 
 > > to
 > >  > know exactly the backward compatibility warranties can dig into the
 > >  > API documentation to learn more about it.
 > >  >
 > >  > "Unstable API" is also the name the Guido proposed for
 > > PyCode_New() last year:
 > >  >
 > >  > * Proposal: declare "unstable APIs"
 > >  >
 > > 
 > > https://mail.python.org/archives/list/python-dev@python.org/thread/JM6SQ2YNMDAKXYD5O54QWMVR2X7QOXVL/
 > > 
 > > 
 > >  > * Making code object APIs unstable
 > >  >
 > > 
 > > https://mail.python.org/archives/list/python-dev@python.org/thread/ZWTBR5ESYR26BUIVMXOKPFRLGGYDJSFC/
 > > 
 > > 
 > >  >
 > >  > Victor
 > > 
 > > 
 > > Nick Coghlan argued against that term:
 > > 
 > >  > "unstable" is the wrong term. We already have an unstable API
 > > tier: the
 > >  > internal API, which can change even in maintenance releases. The
 > > value of
 > >  > the new tier is that it is "semi stable": stable in maintenance
 > > releases,
 > >  > unstable in feature releases.
 > > 
 > > —
 > > 
 > > https://mail.python.org/archives/list/python-dev@python.org/message/CTKKTHUV5R2A2RRN5DM32UQFNC42DDGJ/
 > > 
 > > 
 > > 
 > > 
 > > But I also like “unstable” better than “semi-stable”. Splitting the
 > > internals into “private”/“internal” and “unstable” seems reasonable.
 > > 
 > > 
 > > I think picking "semi-stable" would be giving in to the OCD nerd in all 
 > > of us. :-) While perhaps technically less precise, "unstable" is the 
 > > catchy name with the right association. (And yes, we should keep it 
 > > stable within bugfix releases, but the name doesn't need to reflect that 
 > > detail.) The "internal API" isn't an API at all (except for CPython core 
 > > developers and contributors). The "unstable API" would definitely be an 
 > > *API* for users outside the core.
 > > 
 > > So let's please go with "unstable".
 > > 
 > I was going to suggest "metastable". Too late? :-)
   A
Bikeshedding to a new level! --+
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CGNNVU7CUB4U6TK33FSYVIGP7OPPG4XJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Using the Python C API in C++

[Stephen J. Turnbull]

h.vetin...@gmx.com writes:

 > > > While I don't know who proposed C++11 or where, I'd therefore like
 > > > to propose to move to _at least_ C++14.
 > > 
 > > What benefits does this have for Python development?
 > 
 > Likewise I can ask what benefits choosing C++11 would have?

Not for me to answer, I'm not a proponent of the change.  I'm sure if
you read past discussions here and on Discourse you'll find answers
from the people who studied the problem carefully.  I thought you
might have something to add to the conversation, but I guess not?

Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2YRVSA4D3DZNPQJBX35P3KW6W7DJGDK4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Using the Python C API in C++

[Stephen J. Turnbull]

h.vetin...@gmx.com writes:

 > While I don't know who proposed C++11 or where, I'd therefore like
 > to propose to move to _at least_ C++14.

What benefits does this have for Python development?

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HBPHSH5MNHPWQKF6PC5N7VK7X2SWLKI6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proto-PEP part 1: Forward declaration of classes

[Stephen J. Turnbull]

Larry Hastings writes:
 > On 4/22/22 19:36, Terry Reedy wrote:

 > > How about a 'regular' class statement with a special marker of some 
 > > sort.  Example: 'body=None'.
 > 
 > It's plausible.  I take it "body=None" would mean the declaration would 
 > not be permitted to have a colon and a class body.  So now we have two 
 > forms of the "class" statement, and which syntax you're using is 
 > controlled by a named parameter argument.
 > 
 > I think this "body=None" argument changing the syntax of the "class" 
 > statement is clumsy.

How about another predefined keyword in class definitions?

class ForwardDeclared(*bases, metaclass=Meta, declaration=True):
pass

AIUI, in your scheme you can't have a body in a forward declaration,
so in this one you could error on a non-pass body, or just ignore it.

I don't see how you can avoid the 'continue class' statement, if you
want the actual argument to be an arbitrary expression that evaluates
to an incomplete class.  Then the symmetry of the 'forward class'
statement is appealing.  If you restrict it to be a name, though, you
could use

class SomeModule.ForwardDeclared(declaration=False):
# body goes here

I think.

What's the use case for arbitrary expressions vs. a (possibly
qualified) name?  A class factory that produces forward declarations?
Do you have a use case in mind?

I dunno, but all this seems really complicated, unless you go the
proxy object route (which is basically what we have now, except that
str is extremely limited as a proxy, you could call it a PINO :-).
Sure, there are risks if the temporary thing produced by forward
class' escapes, but if both the "thing" and the proxy are limited
enough, there will be little incentive to do that.  Consenting adults.
Just add the FAFO warning label.  Add features when they're called for.

A separate question:
There are going to be metaclasses that define __new__ whose instances
cannot be used in forward declarations because the class object can't
be created until the class body is seen, and therefore cannot be split
into __new_forward__ and __new_continue__, I suppose.  Is that true?

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/SQB63XJWE67NVOT4XT6I3RSU4HS73AGL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: About PEPs being discussed on Discourse

[Stephen J. Turnbull]

Brett Cannon writes:
 > On Thu, Apr 7, 2022 at 7:33 PM Stephen J. Turnbull <
 > stephenjturnb...@gmail.com> wrote:

 > > The specific mention of "community moderation" and "thread management"
 > > makes me suspect that part of that effect is due to increased cost of
 > > participation for casual observers.
 > 
 > As one of the discuss.python.org admins and a former ML admin (sans
 > python-committers), I can tell that "increased cost of
 > participation for casual observers" is not at all the motivation
 > behind Greg's comment

I worded that post very carefully, and deny any statement about
channel admins' motivation was intended or present in it.

My point is entirely that the Law of Unintended Effects is valid, and
may be operating here.

Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/G4Y2OZCSRXOC3BAKZZ3IYPODVWSJ5CXD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: About PEPs being discussed on Discourse

[Stephen J. Turnbull]

Gregory P. Smith writes:

 > We feel it too. We've been finding Discourse more useful from a community
 > moderation and thread management point of view as well as offering markdown
 > text and code rendering. Ideal for PEP discussions.

The specific mention of "community moderation" and "thread management"
makes me suspect that part of that effect is due to increased cost of
participation for casual observers.  That's not necessarily a bad
thing (except for us dilettantes :-), but please make sure that
there's some convenient way for affected non-core communities (PyPy,
SciPy, Django, random PyPI package owners, and Victor ;-) to stay
abreast of proposed changes that (a) may affect them or (b) they may
have relevant expertise in the matter they could contribute.

Suggestion for PEP monitoring:

AIUI the PEP process at a high level view is fairly well monitored by
a certain set of GitHub commits: the proto-PEP "PEP-" commit, the
commit that assigns it a PEP number, and commits that change status.
How about a GitHub bot that does nothing but post PEP commit logs to a
dedicated Discourse channel?  It should be possible to remove typo
fixes and the like by posting any that change title, number, or
status, and from the rest exclude any commits that change less than a
dozen lines or something like that.  Or perhaps PEP committers could
be asked to include some kind of tag like "#trivial" to distinguish
them.

Steve


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ICUEAAGSR4EMUTZ7WKX2MAYLLOGIRKBF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

[Stephen J. Turnbull]

Barry Warsaw writes:

 > While I don’t underestimate the work and complexity, we can do
 > both.  I.e. separate the stdlib development cycle from the
 > interpreter (for all but a handful of required packages perhaps).
 > We could still distribute “sumo” releases which include all the
 > batteries, but develop and maintain them outside the cpython repo,
 > and even release them separately on PyPI.  It’s *possible* but I
 > don’t know if it’s *practical*. 

After a couple decades maintaining XEmacs, I'd have to say that one of
the things that made our sumos (you heard that word here first,
folks!) practical was that about 80% of the code was developed in GNU
Emacs.  That is, developed in concert with core Emacs.  This meant
that dependencies (think "hybrid of hydra, kitsune-yokai, and
ouroboros" :-) evolve together, as they do in Python.  This is
probably more important in Emacs because of the big-ball-of-string
nature of big Lisp systems (at least with a relatively undisciplined
dev process), but I'd still say there would be *substantial*
coordination costs to be paid if you split the repos.

Also, the only feature in Emacs Lisp that really changed the way
people code since 1990 (and likely earlier) is lexical scope.
Everything else is merely a new callable for practical purposes, and
almost all of it can be implemented in Lisp either as a function or a
macro (although usually at great expense in performance).  But in
Python, every new release makes the Mailman crew want to stop
supporting all previous releases of Python because there's some
feature that can't be emulated that we really love: genexps or async
or walrus operator or   It was certainly quite costly in XEmacs
trying to most packages usable in 21.4, mostly in frustration about
not being able to use 21.5 features. ;-)  But Python has like 4 or 5
generations of stdlib in some form of development or maintenance at
any given time.  It's really not attractive to think either about
creating a separate Sumo Dev Core to maintain several generations of
stdlib corresponding to in-maintenance versions of Python, or about a
lowest-common-denominator stdlib.

Until XEmacs split off the stdlib into packages, Emacs didn't have
anything like a package repository, certainly nothing like PyPI.  I
don't have experience with the Emacs package repos ELPA and MELPA for,
uh, hysterical raisins, so season the next comment to taste.  My
feeling is that both splitting out the stdlib and increasing the rate
at which new packages are added are excessively expensive non-
solutions to the problem that Paul has described, that finding the
right package on PyPI is pretty hard, especially for people new to a
technology.  The extra effort that would be needed to achieve either,
as well as the increased on-going maintenance burden on the core team,
would not really resolve the problem, given that there are now whole
large ecosystems like Django and SciPy outside of Python core
development.

Although it's a different kind of effort from package incorporation
and maintenance, to the extent that effort is fungible, I think it
would be better devoted to creating an annotated catalog of PyPI.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZKODGJ3I6XQNX7ISE4EVCI5RVRCTTOA4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

[Stephen J. Turnbull]

Steven D'Aprano writes:

 > Or maybe, as a developer (not an end-user of an app), you could be more 
 > proactive in reporting those warnings to the third party, and 
 > encouraging them to fix them. Maybe even submitting a patch?

As Chris B points out, it's quite possible that (generic) you have
already reported, and maybe even submitted that patch, but you still
have to wait for the release.  Thing about submitting such patches --
I can't speak for Python programs, but in XEmacs I probably refused
more warning-suppression patches than I accepted, because there was a
deeper problem that needed to be fixed and the annoying warning was
merely a side effect.  And for any project, even if you submit a
patch, there's no guarantee that the next version (or three) will
contain it, which means vendoring the source.  Urk!

 > Of course I understand that folks are busy maintaining their own
 > project, and have neither the time nor the inclination to take over
 > the maintenance of every one of their dependencies. But we
 > shouldn't just dismiss warnings in those dependencies as "warnings
 > I don't care about" and ignore them as Not My Problem.

Sure, but it's still worth providing various kinds of automation.  For
example, it would be nice if downstream (us) could fire and forget
reports of DeprecationWarnings, knowing that bug reporting systems
would automatically identify and merge them.  And for
DeprecationWarnings, rather than patching, it would be usually be nice
to suppress the warning, I think.

Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7MY34PHQVOWGRCHUJ7MSMTPSP544MTV6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: About vulnerabilities in Cpython native code

[Stephen J. Turnbull]

Chris Angelico writes:

 > Not completely, just very minorly. I'm distinguishing between attacks
 > that can be triggered remotely, and those which require the attacker
 > to run specific Python code. For example, using ctypes

OK.  AFAICT that was a red herring introduced to the thread solely to
support the claim "Python isn't memory-safe [anyway]" so it's not
reasonable to claim a Python bug is a vulnerability.  The original
post didn't depend on ctypes or anything like that; it claimed there
*might* be vulnerabilities in CPython's C code.  If so, my claim is
that they would indeed be security-relevant, regardless of what users
with access to Python source might or might not be doing.

Steve


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ESNESNCOM72YSPOPWECSCVKFOFYJ7USP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: About vulnerabilities in Cpython native code

[Stephen J. Turnbull]

Chris Angelico writes:

 > Python source code is not user input though. So there has to be a way
 > for someone to attack a Python-based service, like attacking a web app
 > by sending HTTP requests to it.

Not sure what your point is.  Of course there has to be a vector.  But
as a Mailman developer, I can assure you that there are Python
programs facing the web that accept HTTP requests and SMTP messages,
and process the content, which could be anything an attacker wants it
to be.

I can't recall any CVEs that we could trace to Python (rather than our
code :-/), but Mailman can be and has been attacked.  I can imagine
that if there was an RCE vulnerability in Python or a C module we use,
Mailman would be a top candidate for a workable exploit because of the
amount of processing of user-supplied text we must do.  (Don't worry
about me, I sleep well anyway.  Python is pretty bullet-proof IMO ;-)

Did I completely misunderstand you, or the previous posters?

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZMUQOAVBGYYNFDGQ3JIIRKXEAYXR6XAH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: About vulnerabilities in Cpython native code

[Stephen J. Turnbull]

Patrick Reader writes:

 > And Python is not like JavaScript (in the browser), where code is 
 > supposed to be run in a total sandbox. Python is not supposed to be a 
 > completely memory-safe language. You can always access memory manually 
 > using `ctypes`, or, ultimately, `/proc/self/mem`.

True enough, but

 > For this reason, a buffer overflow in CPython is a bug because it can 
 > cause a crash, not because it can cause a security vulnerability.

A crash *is* a (potential) security vulnerability.  If it can be
reliably triggered by user input, it's a denial of service.

Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/6DLOXRJO6ZEIB7XDHYHBLHFYHG3MQIVS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The current state of typing PEPs

[Stephen J. Turnbull]

Steven D'Aprano writes:

 > I don't think that's what PEP 563 says. Annotations are not
 > *restricted* to only be strings, it is merely that when the
 > function or class object is built, the annotations are left as
 > strings.

You're right, I was imprecise.  I meant as PEP 563 is implemented now,
I doubt it can handle non-strings nicely.

 > So we can post-process annotations and destringify them:

True, but you face the dread "double-decode problem": if the
annotation happens to destringify to a string, then the "post-
processor" may try to destringify again.  I guess we can mark each
annotation as already destringified or not.  As long as this is done
by some sort of API, you're probably OK (but it makes me nervous since
__annotations__ is completely exposed to the program, as in your
example).

 > There may be scoping issues to be sorted out, but I don't think they are 
 > insurmountable.

But isn't there still the issue of forward reference, which motivates
these PEPs in the first place?

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LX7EOMA7RPVJUTS5ADMLBIK2CZN2TMLQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: The current state of typing PEPs

[Stephen J. Turnbull]

Executive summary:

The typing-suspicious crowd has a valid complaint about PEPs 563 and
649, but it's not that they weren't warned.

Christopher Barker writes:

 > Annotations can be, and are, used for other things than "typing". I
 > just noticed that PEP 563 apparently deprecated those other uses
 > (well, sort of: "uses for annotations incompatible with the
 > aforementioned PEPs should be considered deprecated")

Not a PEP proponent (or even a typing user), but I thought this had
been made clear long ago.  My understanding is that optional,
incremental type hints are and have always been considered the primary
use case for annotations by the BDFL and AFAICT the SC following the
BDFL.  If compatibility with typing is an issue, then the burden of
implementing that is on the other application.  Typing *might* do
something to help, but it's not obligated to do so.

 > One example is a use case of mine -- I have built a hierarchical
 > object system, built on dataclasses, in which the annotation
 > absolutely has to be an actual type(class) object. PEP 563 will
 > very much break this use case. [...]

 > I'm not entirely sure if PEP 649 would work for my use case --
 > likely it would, at least with modest modifications, rather than a
 > new API.

If PEP 649 works for you, I expect you could work with PEP 563 by
moving Larry's data descriptor concept out of the compiler and into
your library code.

You could also appeal to the "might do something" caveat above.  Yury
suggested providing both the immediately evaluated object (if there
were no forward references, I guess) and the string representation,
which would be backward compatible with your use case.  The idea was
rejected on the basis that it doesn't help with the primary use in
typing, and doesn't remove the need for a __future__ import during the
transition period.  You could ask that that decision be revisited,
since it would ensure that uses of __annotations__ like yours continue
to work.

 > But I suspect I'm not alone in not really noticing that statement,

I'm not surprised people haven't noticed that statement.  I am
surprised that a lot of folks haven't noticed that this comes up
occasionally and the answer every time is "we're not going to go out
of our way to break other use cases, but typing *is* the primary use
case and will take precedence if the question comes up".

I will grant that restricting the type of compiled annotations from
typing.Any to "string serializing an object's AST" could reasonably be
said to be "going out of your way to break other use cases".  You have
a valid beef here, although it's not obvious to me how it should be
resolved.

So I'm not saying that you don't have an interest in the future
semantics of this dunder.  I am +1 on Python providing relief for your
use case.

 > But the fact is that I, among others, have been a bit uncomfortable
 > about the focus on typing in Python for years.

You mean y'all are uncomfortable with the popularity of typing.  You
wouldn't care if it wasn't used outside of hugely complex proprietary
codebases you'll never see.

Thing is, reasoning about programs is What We Do as programmers, and
efforts to make it easier to do that for complex programs, and to
provide software to help with that task, are here to stay and they
will be used in mixed company.  Even in Python.  (And that's why, as
someone who doesn't use typing, I support typing.  Anything that helps
*other people* to write better code, I can get behind.  My code, I'm
going to write as incompetently as ever.[1] ;-)

 > But when issues are raised, we have been repeatedly told that
 > typing is, and always will remain, optional.

This has always been in the context of *your* source code.  For
example, nobody ever claimed you could keep it out of anybody else's
source code (although that's clearly what a lot of those "raising
issues" want!)  Still, features like stub files were provided so
typists could work and play nicely with non-typists if they wanted to
(and many typists want that, themselves).

But dunders are the property of the language (or sometimes the
implementation), and they always have been.  If you use them in a way
that's not documented to work, you're at risk even if it happens to
work now.  PEP 3107 didn't document that anything would work. ;-)


Footnotes: 
[1]  Barry, do not tell Abhilash I wrote that.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/2O3JHKJ2CM7OFNGT664WXLN2DKU3YGIS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

[Stephen J. Turnbull]

Executive summary:

I guess the bottom line is that I'm sympathetic to both the NFC and
NFKC positions.

I think that wetware is such that people will go to the trouble of
picking out a letter-like symbol from a palette rarely, and in my
environment that's not going to happen at all because I use Japanese
phonetic input to get most symbols ("sekibun" = integral, "siguma" =
sigma), and I don't use calligraphic R for the real line, I use
\newcommand{\R}{{\cal R}}, except on a physical whiteboard, where I
use blackboard bold (go figure that one out!)  So to my mind the
letter-like block in Unicode is a failed experiemnt.

Jim J. Jewett writes:

 > When I was a math student, these were clearly different symbols,
 > with much less relation to each other than a mere case difference.

Arguable.  The letter-like symbols block has script (cursive),
blackboard bold, and Fraktur versions of R.  I've seen all of them as
well as plain Roman, bold, italic and bold italic facts used to denote
the real line, and I've personally used most of them for that purpose
depending on availability of fonts and input methods and medium (ie,
computer text vs. hand-written).  I've also seen several of them used
for reaction functions or spaces thereof in game theory (although
blackboard bold and Fraktur seem to be used uniquely for the real
line).  Clearly the common denominator is the uppercase latin letter
"R", and the glyph being recognizably "R" is necessary and sufficient
to each of those purposes.  The story for uppercase sigma as sum is
somewhat similar: sum is by far not the only use of that letter,
although I don't know of any other operator symbol for sum over a set
or series (outside of programming languages, which I think we can
discount).

I agree that we should consider math to be a separate language, but it
doesn't have a consistent script independent of the origins of the
symbols.  Even today none of my engineering and economics students can
type any symbols except those in the JIS repertoire, which they type
by original name ("siguma", "ramuda", "arefu", "yajirushi" == arrow,
etc, "sekibun" == integration does bring up the integral sign in at
least some modern input methods, but it doesn't have a script name,
while "kasann" == addition does not bring up sigma, although "siguma"
does, and "essu" brings up sigma -- but only in "ASCII emoji" strings,
go figure).  I have seen students use fullwidth R for the real line,
though, but distinguishing that is a deprecated compatibility feature
of Unicode (and of Japanese practice -- even in very formal university
documents such as grade reports for a final doctoral examination I've
seen numbers and names containing mixed half-width and full-width
ASCII).

So I think "letter-like" was a reasonable idea (I'm pretty sure this
block goes back to the '90s but I'm too lazy to check), but it hasn't
turned out well, and I doubt it ever will.

 > So by the Unicode consortium's goals, they are independent
 > characters that should each be defined.  I admit that isn't ideal
 > for most use cases outside of math,

I don't think it even makes sense *inside* of math for the letter-like
symbols.  The nature of math means that any "R" will be grabbed for
something whose name starts with "r" as soon as that's convenient.
Something like the integral sign (which is a stretched "S" for "sum"),
OK -- although category theory uses that for "ends" which still don't
look anything like integrals even if you turn them inside out, rotate
90 degrees, and paint them blue.

 > > It's also a UX problem.  At slightly higher layer in the stack, I'm
 > > used to using Japanese input methods to input sigma and pi which
 > > produce characters in the Greek block, and at least the upper case
 > > forms that denote sum and product have separate characters in the math
 > > operators block.
 > 
 > I think that is mostly a backwards compatibility problem; XeTeX
 > itself had to worry about compatibility with TeX (which preceded
 > Unicode) and with the fonts actually available and then with
 > earlier versions of XeTeX.

IMO, the analogy fails because the backward compatibility issue for
Unicode is in the wetware, not in the software.

Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YTIIFIF75RMWP5J3GCSXWVXSUP5SX7AA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

[Stephen J. Turnbull]

Abdur-Rahmaan Janhangeer writes:

 > As a programmer, i don't want a language which bans unicode stuffs.

But that's what Unicode says should be done (see below).

 > If there's something that should be fixed, it's the unicode standard,

Unicode is not going to get "fixed".  Most features are important for
some natural language or other.  One could argue that (for example)
math symbols that are adopted directly from some character repertoire
should not have been -- I did so elsewhere, although not terribly
seriously.

 > maybe defining a sane mode where weird unicode stuffs are not
 > allowed.

Unicode denies responsibility for that by permitting arbitrary
subsetting.  It does have a couple of (very broad) subsets predefined,
ie, the normalization formats.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/63FDIQQNJKCH7C3NMEN3ECRHTA7JHJ2W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

[Stephen J. Turnbull]

Christopher Barker writes:

 > Would a proposal to switch the normalization to NFC only have any hope of
 > being accepted?

Hope, yes.  Counting you, it's been proposed twice. :-)  I don't know
whether it would get through.  We know this won't affect the stdlib,
since that's restricted to ASCII.  I suppose we could trawl PyPI and
GitHub for "compatibles" (the Unicode term for "K" normalizations).

 > For example, in writing math we often use different scripts to mean
 > different things (e.g. TeX's Blackboard Bold).  So if I were to use
 > some of the Unicode Mathematical Alphanumeric Symbols, I wouldn't
 > want them to get normalized.

Independent of the question of the normalization of Python
identifiers, I think using those characters this way is a bad idea.
In fact, I think adding these symbols to Unicode was a bad idea; they
should be handled at a higher level in the linguistic stack (by
semantic markup).

You're confusing two things here.  In Unicode, a script is a
collection of characters used for a specific language, typically a set
of Unicode blocks of characters (more or less; there are a lot of Han
ideographs that are recognizable as such to Japanese but are not part
of the repertoire of the Japanese script).  That is, these characters
are *different* from others that look like them.

Blackboard Bold is more what we would usually call a "font": the
(math) italic "x" and the (math) bold italic "x" are the same "x", but
one denotes a scalar and the other a vector in many math books.  A
roman "R" probably denotes the statistical application, an italic "R"
the reaction function in game theory model, and a Blackboard Bold "R"
the set of real numbers.  But these are all the same character.

It's a bad idea to rely on different (Unicode) scripts that use the
same glyphs for different characters to look different from each
other, unless you "own" the fonts to be used.  As far as I know
there's no way for a Python program to specify the font to be used to
display itself though. :-)

It's also a UX problem.  At slightly higher layer in the stack, I'm
used to using Japanese input methods to input sigma and pi which
produce characters in the Greek block, and at least the upper case
forms that denote sum and product have separate characters in the math
operators block.  I understand why people who literally write
mathematics in Greek might want those not normalized, but I sure am
going to keep using "Greek sigma", not "math sigma"!  The probability
that I'm going to have a Greek uppercase sigma in my papers is nil,
the probability of a summation symbol near unity.  But the summation
symbol is not easily available, I have to scroll through all the
preceding Unicode blocks to find Mathematical Operators.  So I am
perfectly happy with uppercase Greek sigma for that role (as is
XeTeX!!)

And the thing is, of course those Greek letters really are Greek
letters: they were chosen because pi is the homophone of p which is
the first letter of "product", and sigma is the homophone of s which
is the first letter of "sum".  Å for Ångström is similar, it's the
initial letter of a Swedish name.

Sure, we could fix the input methods (and search methods!! -- people
are going to input the character they know that corresponds to the
glyph *they* see, not the bit pattern the *CPU* sees).  But that's as
bad as trying to fix mail clients.  Not worth the effort because I'm
pretty sure you're gonna fail -- it's one of those "you'll have to pry
this crappy software that annoys admins around the world from my cold
dead fingers" issues, which is why their devs refuse to fix them.

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5GHPVNJLLOKBYPE7FSU5766XYP6IJPEK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Do we need to remove everything that's deprecated?

[Stephen J. Turnbull]

Christopher Barker writes:
 > On Sun, Nov 14, 2021 at 8:19 AM Stephen J. Turnbull <
 > stephenjturnb...@gmail.com> wrote:
 > 
 > >  > But do
 > >  > we need to support running the same code on 3.5 to 3.10?
 > >
 > > Need?  No.  Want to not raise a big middle finger to our users?
 > 
 > Note that I said 3.5, not 3.6 -- 3.5 is no longer supported. If we feel the
 > need to be backward compatible with unsupported versions that we can't ever
 > remove anything.

I'm not saying *Python* can't remove anything.  I'm saying downstream,
*GNU Mailman* has users it *may* want to support.

Unlike Petr, I'm not <0 on removals.  But they are costly, keeping up
with deprecations is costly.  In theory, I agree with you that we
should consider maintenance as an almost-fixed cost that a few
deprecations aren't going to increase significantly.  In practice, I'm
not practiced enough to say.

I do see a strong case for pruning stuff that we already found worth
deprecation as well.  In this thread, I'm most interested in exploring
tooling to make it easier for those who express reservations about
removals.

Steve


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/5YTXKZQT4IQSZDLFGT4TRFHIOYHCYITU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Do we need to remove everything that's deprecated?

[Stephen J. Turnbull]

Christopher Barker writes:
 > On Sat, Nov 13, 2021 at 12:01 AM Stephen J. Turnbull
 > 
 > > What I think would make a difference is a six-like tool for making
 > > "easy changes" like substituting aliases and maybe marking other stuff
 > > that requires human brains to make the right changes.
 > 
 > 
 > I think a “2to3” like or “futurize” like tool is a better idea, but
 > yes.

That's what I meant, thanks for the correction.

 > The real challenge with the 2-3 transition was that many of us
 > needed to keep the same code base running on both 2 and 3. But do
 > we need to support running the same code on 3.5 to 3.10?

Need?  No.  Want to not raise a big middle finger to our users?  Yes.
Speaking for GNU Mailman (and I think I can do that in this case
without getting lynched by the rest of our crew).

I wouldn't mind if the tool gently suggests, ''' hey, folks, you can't
really support both 3.5 AND 3.10 without a lot of "if hasattr(foo,
'frob')", so maybe you can drop support for 3.5? ''', though.

 > I’m confused — did you mean “sometimes cause dangerous behavior”? That’s
 > pretty rare isn’t it?

FVO of "often" == "yeah, I've heard enough stories that I worry about
it", I mean "often".

We're talking about risk assessments, and I work with Internet-facing
code, where there are no risks, just certain disasters at an uncertain
but near-future date. ;-)

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XKDXS3AGTBWRK2MFTM6OOP7WE6UM4PMF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Do we need to remove everything that's deprecated?

[Stephen J. Turnbull]

Victor Stinner writes:

 > In Python, usually, there is a better alternative.

As in life.

 > Do you have to repeat "You should check for DeprecationWarning in
 > your code" in every "What's New in Python X.Y?" document?

That probably doesn't hurt, but I doubt it does much good for anybody
except the bewildered first-day college intern who wonders why nobody
in the devops team follows best practices.  They'll learn to ignore
those lines pretty quick, too, I'm sure. ;-)

What I think would make a difference is a six-like tool for making
"easy changes" like substituting aliases and maybe marking other stuff
that requires human brains to make the right changes.

I'm not volunteering to do this, I don't even know that it's actually
feasible.  But I think that unless we're willing to bite that bullet,
it's going to be difficult to make much progress over the current
situation.  Deprecated code does normally more or less work, and often
it never gets close to dangerous behavior.  On the flip side, it often
can cause dangerous behavior, and you won't know if it does until you
do a thorough audit of your use case, which isn't going to happen
because it would take as much effort as replacing the deprecated
code.

I think we all see both sides, even if our own individual experience
leads us to want to change the current balance.  Unfortunately, as we
see here, some folks want more removals, some peole want less (or
none).


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JVR33XD7EIUIIMKOHIGFZQIXSWBZKS6D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Ignore my previous post Re: containment and the empty container

[Stephen J. Turnbull]

Aargh.

The whole point of Cameron's post was about implementing "in", and all
of it makes sense now.  Sorry.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VG6IR6DZNAMVM6VEZT3AU4MK355SOCSP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: containment and the empty container

[Stephen J. Turnbull]

Cameron Simpson writes:
 > On 08Nov2021 23:32, MRAB  wrote:

 > >A flag could be a member, but could a set of flags?
 > 
 > Probably one flavour should raise a TypeError then with this comparison.  
 > I wouldn't want "member flag present in SomeFlag.something" and 
 > "set-of-members present in SomeFlag.something" to both be valid,

If the latter is valid, so is the former, since "member flag" is
representable as "singleton containing member flag".  (I think this
representation of sets of flags is the primary use case for IntFlag,
as opposed to Flag or IntEnum.)  If I really needed to distinguish, I
wouldn't use a Enum type that can represent multiple members in one
item, I'd use Python sets of Flags, .

 > I would rather punt the "set-of-members present" off to "<"/"<=" if
 > we want to say either (which of course we should be able to say).

 <  == True since IntFlag is derived from int, but
that's not what we want.  You'd have to define __lt__ for every such
flag type.  For convenience, we would want a new Enum type in the
stdlib.

 > Of course, I think resently we don't distinguish a flag combination
 > name (".nothing", ".red_and_blue"==0b11) from single flags
 > overtly.

I think we really don't want to do that in the stdlib.  Such flags
would often support operations like intersection and set difference
that could easily result in singletons, which then might be checked
against an "allow set".  If you care about the distinction between
singleton-representing-element and other sets of flags, elements of
the flag enum and sets of those elements need to be different types.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/U3MK446WGHLNFET55S523NI2JKVMRRTW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: containment and the empty container

[Stephen J. Turnbull]

Tim Peters writes:
 > [Ethan Furman ]

 > > .. on the other hand, it seems that collections of related flags
 > > are often treated as in set theory, where the empty set is a
 > > member of any non-empty set.
 > 
 > Not how any set theory I've ever seen works: a set S contains the
 > empty set if and only if some member of S _is_ the empty set.  Which
 > is also how Python's frozenset.__contains__ works (a plain Python set
 > can never contain the empty set, because only a frozenset can contain
 > a set (empty or not)).

Maybe Ethan's thinking of one of the standard set-theoretic
constructions of natural numbers? Ie,

0 = {}, 1 = {0} = {{}}, 2 = {0, 1} = {{}, {{}}}, etc.

Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XDCKP55FVS6CLVUYJMQF5BF5HA4TZOK4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: pre-PEP: Unicode Security Considerations for Python

[Stephen J. Turnbull]

Chris Angelico writes:

 > Ah, okay, so much for that, then. What about the weaker sense:
 > Characters below 128 are always and only represented by those byte
 > values? So if you find byte value 39, it might not actually be an
 > apostrophe, but if you're looking for an apostrophe, you know for sure
 > that it'll be represented by byte value 39?

1.  The apostrophe that Python considers a string delimiter is always
represented by byte value 39 in the compiler input.  So the only
time that wouldn't be true is if escape sequences are allowed to
represent characters.  I believe unicode_escape is the only codec
that does.

2.  There's always eval which will accept a string containing escape
sequences.

 > Yes. I'm sure someone will come along and say "but I have to have an
 > all-ASCII source file, directly runnable, with non-ASCII variable
 > names", because XKCD 1172, but I don't have enough sympathy for that
 > obscure situation to want the mess that unicode_escape can give.

It's not an obscure situation to me.  As I wrote earlier, been there,
done that, made my own T-shirt.  I don't *think* it matters today, but
the number of DOS machines and Windows 98 machines left in Japan is
not zero.  Probably they can't run Python 3, but that's not something
I can testify to.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RNCM3QNGBRRM5GW6SL3Q6FP6R55F5CHU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: pre-PEP: Unicode Security Considerations for Python

[Stephen J. Turnbull]

Chris Angelico writes:

 > But I was surprised to find that Python would let you use
 > unicode_escape for source code.

I'm not surprised.  Today it's probably not necessary, but I've
exchanged a lot of code (not Python, though) with folks whose editors
were limited to 8 bit codes or even just ASCII.  It wasn't frequent
that I needed to discuss non-ASCII code with them (that they needed to
run) but it would have been painful to do without some form of codec
that encoded Japanese using only ASCII bytes.

 > Maybe the phrase "a small handful" was a bit too hopeful, but would it
 > be possible to mandate (after, obviously, a deprecation period) that
 > source encodings be ASCII-compatible?

Not sure what you mean there.  In the usual sense of ASCII-compatible
(the ASCII bytes always mean the corresponding character in the ASCII
encoding), I think there are at least two ASCII-incompatible encodings
that would cause a lot of pain if they were prohibited, specifically
Shift JIS and Big5.  (In certain contexts in those encodings an ASCII
byte frequently is a trailing byte in a multibyte character.)  I'm sure
there is a ton of legacy Python code in those encodings in East Asia,
some of which is still maintained in the original encoding.  And of
course UTF-16 is incompatible in that sense, although I don't know if
anybody actually saves Python code in UTF-16.

It might make sense to prohibit unicode_escape nowadays -- I think
almost all systems now can handle Unicode properly, but I don't think
we can go farther than that.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ESIU62AXASWUDX7MSPMTFIDONIAI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: pre-PEP: Unicode Security Considerations for Python

[Stephen J. Turnbull]

Chris Angelico writes:

 > Huh. Is that level of generality actually still needed? Can Python
 > deprecate all but a small handful of encodings?

I think that's pointless.  With few exceptions (GB18030, Big5 has a
couple of code point pairs that encode the same very rare characters,
ISO 2022 extensions) you're not going to run into the confuseables
problem, and AFAIK the only generic BIDI solution is Unicode (the ISO
8859 encodings of Hebrew and Arabic do not have direction markers).

What exactly are you thinking?

The only thing I'd like to see is to rearrange the codec aliases so
that the "common names" would denote the maximal repertoires in each
family (gb denotes gb18030, sjis denotes shift_jisx0213, etc) as in
the WhatWG recommendations for web browsers.  But that's probably too
backward incompatible to fly.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/W4RJJVAJN7FB24R52YSCU2Y3QZQE3BEL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

[Stephen J. Turnbull]

Jim J. Jewett writes:

 > At the time, we considered it, and we also considered a narrower
 > restriction on using multiple scripts in the same identifier, or at
 > least the same identifier portion (so it was OK if separated by
 > _).

This would ban "παν語", aka "pango".  That's arguably a good idea
(IMO, 0.9 wink), but might make some GTK/GNOME folks sad.

 > Simplicity won, in part because of existing practice in EMACS
 > scripting, particularly with some Asian languages.

Interesting.  I maintained a couple of Emacs libraries (dictionaries
and input methods) for Japanese in XEmacs, and while hyphen-separated
mixtures of ASCII and Japanese are common, I don't recall ever seeing
an identifier with ASCII and Japanese glommed together without a
separator.  It was almost always of the form "English verb - Japanese
lexical component".  Or do you consider that "relatively complicated"?

 > It might be time for the documentation to mention a specific
 > linter/configuration that does this.  It also might be reasonable
 > to do by default in IDLE or even the interactive shell.

It would have to be easy to turn off, perhaps even provide
instructions in the messages.  I would guess that for code that uses
it at all, it would be common.  So the warnings would likely make
those tools somewhere between really annoying and unusable.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FPO3EJISKDZUVMC3RMJJQZIKGCOG35CX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

[Stephen J. Turnbull]

Serhiy Storchaka writes:

 > All control characters except CR, LF, TAB and FF are banned outside
 > comments and string literals. I think it is worth to ban them in
 > comments and string literals too.

+1

 > > For homoglyphs/confusables, should there be a SyntaxWarning when an
 > > identifier looks like ASCII but isn't?
 > 
 > It would virtually ban Cyrillic.

+1 (for the comment and for the implied -1 on SyntaxWarning, let's
keep the Cyrillic repertoire in Python!)

 > It is a work for linters,

+1

Aside from the reasons Serhiy presents, I'd rather not tie
this kind of rather ambiguous improvement in Unicode handling to the
release cycle.

It might be worth having a pep module/script in Python (perhaps
more likely, PyPI but maintained by whoever does the work to make
these improvements + Petr or somebody Petr trusts to do it), that
lints scripts specifically for confusables and other issues.

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/Z62GMKAJLHZJD3YSEOJKKBWUZSBYEIVA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: pre-PEP: Unicode Security Considerations for Python

[Stephen J. Turnbull]

Serhiy Storchaka writes:
 > This is excellent!
 > 
 > 01.11.21 14:17, Petr Viktorin пише:
 > >> CPython treats the control character NUL (``\0``) as end of input,
 > >> but many editors simply skip it, possibly showing code that Python
 > >> will not
 > >> run as a regular part of a file.
 > 
 > It is an implementation detail and we will get rid of it.

You can't, probably not for a decade, because people will be running
versions of Python released before you change it.  I hope this PEP
will address Python as it is as well as as it will be.

 > It only happens when you read the Python script from a file.

Which is one of the likely vectors for malware.  It might be worth
teaching virus checkers about this, for example.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OUFJ47LYOHQ245BIKWVPCH4OCDB4CM7N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] raising a io exception when fileno is requested on a tarfile FileInFile

[Stephen J. Turnbull]

makap...@gmail.com writes:

 > When you call extractfile() on a TarFile, the result is a buffered
 > version of a _FileInFile pseudo-file.  When fileno() is called on
 > this resulting file, fileno() it not exist (understandably) and an
 > AttributeError is raised.  I would like to suggest raising an
 > io.UnsupportedOperation instead, so that file would act more like
 > other file-like objects.

I have no opinion on the suggestion itself, but it's well-formulated
and plausible.

That said, it's a clear backward incompatibility because code
currently expecting AttributeError exceptions won't catch this (unless
io.UnsupportedOperation is derived from AttributeError), so it will
have to wait until the next feature release for sure, and might need a
deprecation cycle.  I suggest that you file an issue on the GitHub
tracker so it won't get lost, and post it to this thread.

Steve


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XQBM7MMDZ5Z6KIEY4JIYSCEPUWVBC5FT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

[Stephen J. Turnbull]

Marc Mueller writes:

 > True, but from my experience 'None' is just by far the most common
 > default. Why not improve how we handle it?

The question is whether this is an improvement in the long run.  When
some falsies are expected, in-range values, "if arg is None: ..." or
"x = default if arg is None else arg" is sufficiently precise and
concise.  I don't see "arg ?? default" as an improvement worthy of
syntax.

One the minus side, as David Mertz testifies, there is a maze of
missing value use cases, all alike (or is that a missing maze of
values, all alike?)  These operators would further encourage
conflating them all into None.  At least in theory, that's not an
improvement in handling None, that's a loss of precision in handling
an important subset of Nones.

I just don't see much value in ??.  I don't have an opinion on the
?. and ?[] versions.  I can see that they could make chained
operations much more concise than nested if ... else expressions, and
at least somewhat more precise (at least if you want to avoid deep
nesting of try ... except KeyError statements, which I suppose most
everybody would like to avoid).

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/CO7RY5NNCPMYGFH2OYNHU5JWEIP7NGIX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Worried about Python release schedule and lack of stable C-API

[Stephen J. Turnbull]

jack.jan...@cwi.nl writes:

 > I’m getting increasingly worried about the future of Python,

You mean about the fact that Python has a plethora (rapidly growing!) 
of powerful, efficient extension packages and you want to use them
all (perhaps recursively)? :-)  I really don't think this bodes ill
for the future of Python.

Perhaps it bodes poorly for your development practices (and I'll try
to tease out some ideas where we can improve the infrastructure for
you), but there are plenty of applications where this plethora works
really well, too.

 > and those worries have been exacerbated by the new yearly release
 > rhythm, and the lack of a stable C-API that is full enough to
 > entice extension writers to use it.

I don't think "full API" is the problem (cf. Phil Thompson's post[1],
where the stable API is good enough for PyQt).  I think the problem is
more likely that in initial development, they simply targeted the .h
files in front of them.[2]  Since then they haven't needed to update,
and *neither has anyone else with resources or pull with with that
package's devs*.  Suggestion: Perhaps the documentation can be
improved to make the stable API easier to conform to from the get-go.
(I think the stable API is already distinguished in the .h files.)

If "full API" *is* the problem, I doubt it's a solvable problem (except
by extension users lobbying extension developers to use the stable
API), because the stable API is a deliberate compromise between
efficient communication between CPython and extensions, and
flexibility for CPython to improve its internal implementation.  If
extension writers *deliberately* eschew the stable API, presumably
they need to access private APIs and if those change, too bad.

 > And I also fully understand that some other developer who creates a
 > new package that is essential to my application only targets the
 > current Python release,

This is where developers in your position can have the most impact, I
think.  When there's a new gotta-have extension, tell the extension's
developers you need support for the stable API or ABI, or you can't
use their package.

 > And that is assuming you have the time and are smart enough to back
 > port the new package to the old Python release, or the old package
 > to the new Python release (and for the latter there’s probably a
 > good reason why the developers haven’t done so already).

Most frequently, as you pointed out, the reason is that they're busy
with other priorities, and it's just not their itch to scratch.

 > I think we really need to come up with some scheme whereby
 > extension packages become more long-lived than a single Python
 > release...

I would guess that a lot of extension packages are quite long-lived.
First, as Phil Thompson points out for PyQt[1], the content of the
wheel may very well work fine, but they have to actually make the
wheels with the appropriate name (or maybe other metadata?), or they
won't install in the new Python version's site-packages.  I think this
is something that Python (distutils-sig) could do something about,
either by adding a way to make multi-version wheels, or providing a
utility to retarget an existing wheel (maybe mv(1) is enough?!)

Second, I'm sure there are plenty of extensions that can be ported to
either new CPython versions or (preferably) to the stable API or ABI
with minimal effort.  Perhaps there could be a SIG or a channel in the
tracker where people could request these ports.  I'm suggesting this
because of the "better things to do problem".  Obviously, if the
extension itself is unmaintained, its maintainer will do nothing.
Even if it is maintained, it seems that its dev community does not
prioritize these ports.  But new developers looking for something to
do might see it in "core" channels.  Probably there are plenty of
people around who can help them build wheels, and I believe a
significant fraction of extensions without current version wheels will
require little or no C changes.  (OK, this doesn't involve a merge
request to CPython, so it doesn't immediately set them on the path to
core dev status, but we can award gold stars.)


Footnotes: 
[1]  


[2]  Maybe that's just me?  OK, I'm busted!

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/BKAZWGLTLOZ6BJDC3KAYBWTITFO4BQN4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: f-strings in the grammar

[Stephen J. Turnbull]

Guido van Rossum writes:

 > I don't know about the line breaks, but in recent weeks I've found myself
 > more than once having to remind myself that inside interpolations, you must
 > use the other type of quote.

My earlier remarks were specifically directed to line breaks.

I see the point, but I think the question should be readability, as
David points out.  I don't think there's a problem with the opening
quote in your example.  Even in an ordinary string literal it's
obvious to me that the embedded quotation marks are not intended to
terminate the string:

s = "Here is a singleton " and here is an initial for "something."

But how about that last quotation mark?  I tried to construct a
similarly visually ambiguous f-string where braces "hide" the embedded
quotation marks, and couldn't do it without a trailing quote followed
immediately by an embedded literal line break.

So I'm cautiously sympathetic to this extension, as long as embedded
line breaks are not permitted in singly-quoted f-strings.

However, I myself will almost certainly automatically "correct" such
quotation marks if they are allowed.  So this is unlikely to be a plus
or a minus for me.

Steve




___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZILJFTV6UXO63F76PSY6VCPNGTLMYIMR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: f-strings in the grammar

[Stephen J. Turnbull]

Eric V. Smith writes:

 > >> But this does not:
 > >>
 > >> f'{1 +
 > >> 2}'
 > >
 > > The later is an error with or without the 'f' prefix and I think that 
 > > this should continue to be the case.
 > >
 > The thought is that anything that's within braces {} and is a valid 
 > expression should be allowed.

-0  FWIW, some thoughts specific to me, I don't know how
representative they might be of others.

I guess you could argue that the braces are a kind of expression-level
parenthesis, but I don't "see" them that way.  I see *one* string with
eval'able format expressions embedded in it, so that single-quoted
strings can't have embedded newlines.  I also don't see the braces as
expression-level syntax (after all, they already have two different
meanings at expression level), I see them as part of f-string syntax.
So even with triple-quoted strings, my eyes "want" to see parentheses
or line continuation (which already work).

I'm sure I could get used to the syntax.  But ...

Is this syntax useful?  Or is it just a variant of purity trying to
escape Pandora's virtualbox?  I mean, am I going to see it often
enough to get used to it?  Or am I going to WTF at it for the rest of
my life?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RPFHA55JDGX522UL2KXIRZKDPIOVDP66/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 467 feedback from the Steering Council

[Stephen J. Turnbull]

Ethan Furman writes:

 > `int.from_bytes` methods, and is an appropriate name for the target
 > domain (where bytes are treated as characters).

The relevant domains treat bytes as bytes.  It's frequently useful
(and dare I say "Pythonic"?) for *programmers* to take advantage of
the mnemonic of treating 95 of the bytes as the ASCII encoding of
characters.  It follows that it's good sense for protocol designers to
restrict themselves to that alphabet for their magic numbers.  But
standards themselves make clear that these protocols handle *octets*
(historically, "byte" was too ambiguous for network protocols!), not
characters or ints that happen to fit into 8 bits.  The "control
characters" aren't really characters even when they're syntactically
significant, some of them are not significant unless combined in a
particular order (CRLF), and of course the bytes 0x80-0xFF are never
treated as characters.

As far as I can see, the "programmers' mnemonic" interpretation gets
us everything we really want in this area.  We should avoid the idea
that "bytes are treated as characters" because they aren't, and
because that way lies the madness that incited the upheaval of Python
3 in the first place.

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DCSW7WLND6SZ6CGV4BZXP6QEOS2MZ7FA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

[Stephen J. Turnbull]

Marc-Andre Lemburg writes:
 > On 26.08.2021 06:07, Christopher Barker wrote:

 > > But now a question -- the current text reads:
 > > 
 > > "Code in the core Python distribution should always use UTF-8"

 > > "The following policy is prescribed for the standard library
 > > ... In addition, string literals and comments must also be in
 > > ASCII."

Alex Martelli had a long, well-reasoned post about why Python's
"official" language (specifically, identifiers and comments) should be
English despite the strong preference for inclusion of our community.
As long as that remains true, I think we should stick to ASCII as a
lowest common denominator, with an exception for proper names and
testing.

 > With UTF-8 as standard source code encoding, this is no longer
 > necessary.
 > 
 > So the second quote can be changed to "In the standard library, non-default
 > source code encodings should be used only for test purposes ...".

+1

 > I think the above should be limited to Python code. In C or other
 > source files you may well still need a source code encoding.

True, but PEP 8 only does apply to Python.  PEP 7 is the style guide
for C.

 > No need for the stdlib, since UTF-8 is widely accepted by now
 > and why should people with non-ASCII names not be able to write
 > their true name ?

+1

While I proposed above that the stated policy should be "ASCII except
for proper names", I also think "although practicality beats purity".
I think such exceptions will be rare enough that "although
practicality" can be left implicit.

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/W7JHKRKDFZ5VOYUKJTPGVVGXSERUHQVS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

[Stephen J. Turnbull]

Christopher Barker writes:

 > PR here:

Thanks for your prompt efforts!  The notes toward a "near future"
agenda are above and beyond.

 > Interesting some of the cruft in there e.g.  still referring to "new style
 > classes" :-)

I think that should also come out "now", but that's a +1 to the idea,
not a suggestion for you to do it.  Maybe I will if nobody gets to it
before the weekend. :-)

Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XZMZV6EUT3MTPPW62CS3WAPNRHGCTWHQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?

[Stephen J. Turnbull]

Terry Reedy writes:

 > We could add (perhaps at the end of the first paragraph) something like 
 > "(Since the 2.x stdlib is frozen, all 2.x-specific guidelines were 
 > removed in Sept 2021.)"  Anyone interested could then check git log for 
 > the last commit before then.

How about including the most recent 'main' SHA1 (where a 6-character
prefix should do, and "the" refers to Chris's clone, we don't need to
be hugely fussy about the exact previous commit when it eventually
gets merged), or even tag it?

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/TWNYNKGCCMGNK4CXZGVZBCGCPQL7HMYF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Dropping out of this list

[Stephen J. Turnbull]

In re: Requests for Censorship :-(

Luciano Ramalho writes:

 > Instead of going silently, I wanted to call on the adult supervision
 > to do something about the adult.

I'm sympathetic, because I value your participation in this list.  But
I'm also sympathetic to the moderators, because usually the kind of
behavior being exhibited is a one-off: it's *temporary* loss of
control, often only one or two posts.

To all:

If you are considering leaving the list because of one or two
individuals, please consider a *local* "author or recipient" filter,
instead of asking for a list-post ban, or a hold for moderation (which
is a lot of emotional work for the moderators).

If you are considering leaving because of the thread, many MUAs have
an "ignore thread" function.  If not, filtering on subject, which
Gmail can do (I believe that if you select a whole conversation it
will either filter the thread or filter the subject -- I always
configure by hand because "AI" stands for "Abominable Idiosyncracy").

If you are considering *replying* to such an individual, in the case
of a technical contribution, *remove* the CC to the individual
address.  This not only allows others to recognize an interesting
discussion and participate if they choose, but also helps to
rehabilitate the bad relationships as we recognize contributions.

If you *must* reply to insults, etc (really this only should apply to
moderators who may need to show publicly that they're "doing something",
but we're all human :-), include the individual address.  This policy
will make such local filters more effective, and it's something we can
all do *together* to reduce the stress of these occasional conflicts.

Regards,
Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/YLV7UY2C7EFFPOIPCZ3Q6EXYB77JCET2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 467 feedback from the Steering Council

[Stephen J. Turnbull]

Antoine Pitrou writes:

 > In what context is `bchr()` useful?

As a builtin, not my problem, I'm not the proponent.  As a facility
with *some* spelling, it's convenient in contexts where chr() is, but
much less so (eg, coding ROT13 ;-).  I know I've used this translation
in mail hacking, but I don't recall whether the code was Python or
Lisp.

Regards,
Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VBZBMCPQ6IR3SZIEALQQFXGLUMXY7RUT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 467 feedback from the Steering Council

[Stephen J. Turnbull]

Christopher Barker writes:

 > A byte is not a character

While I am -0.5 on bchr for many of the reasons already cited in the
thread (and would be -1 if the methods names proposed for the feature
were a bit more aesthetic), I don't think this argument is valid.
Bytes that could otherwise be arbitrary (aka "magic numbers") are
*often* chosen because they correspond to the ASCII repertoire.  And
strings is still a useful utility for C programmers, even if not so
much for others.

It's true that bytes are still bytes, characters are still characters,
and it's a very good thing from my point of view that Python 3 gave us
a consistent separation -- the only thing I ever explicitly use bytes
for is passwords for zipfiles, and the implicit handling of bytes
ontherwise just works for me :-).  But it turns out it was a mistake
to make it so hard for consenting adults to treat bytes as characters
in certain contexts (for example, PEP 461 -- note: I opposed that PEP
and I was wrong -- should have been part of Python 3.0).

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ZASN3G7VZBZSAYY6CH5GUDDENOZ6NJKR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: name for new Enum decorator

[Stephen J. Turnbull]

Irit Katriel via Python-Dev writes:

 > Andrei is suggesting to look at each enum value as the set of "bits set to
 > 1" in this value, and then apply a set-thoery term to the problem.
 > [...]  Anyway, I don't know whether this kind of terminology is
 > widely accessible.

I think the everyday meaning of "cover" is close enough to the set
theory meaning that only set theorists can be confused.  (Not a joke,
because I'm not sure exactly what Ethan intends.)  I'm not sure
"exact_cover" or "complete_cover" or similar are good names, but
they're as good as any I've seen so far.

 > Maybe you could use something like @composite. As in, every non-canonical
 > value in the enum is the composition of canonical values.

-1 on "composite".  "Compose" has other, more important meanings, and
isn't very suggestive of this kind of factorization, to me at least.

Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OZOEOD3OT76OSWJ5ZZ4Y4X4JSYWCG4ZS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

[Stephen J. Turnbull]

Christopher Barker writes:

 > I find this whole conversation confusing -- does anyone really think a
 > substantial performance boost to cPython is not a "good thing"?

 > [PyPy, Numba, Cython] are why Python is very useful today -- but
 > none of them make the case that making cPython run faster isn't a
 > worthy goal.

I don't understand why you think anybody, except maybe some crank who
caused the editors of Science or whatever it was to seriously
embarrass themselves, opposes the goal of making cPython run faster.

All I want is some sanity when advocating changes to Python.  For
performance work, tell us how much faster cPython is going to be,
explain where you got your numbers, and let us decide how we'll use
the cycles saved.  There's been a lot of nonsense peddled in support
of this proposal by the proponent and thirds parties, when all anybody
needs is

Mark says he can make cPython noticably faster
 and
   we believe him!

More important, Microsoft does.

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/ESKRW4A2IMPTKPHF52W4R2NUD7BGYLLF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

[Stephen J. Turnbull]

Oscar Benjamin writes:

 > The break even point where both implementations take equal time is
 > around about 5% density. What that means is that for a 1000 x 1000
 > matrix with 10% of elements nonzero it is faster to ask flint to
 > construct an enormous dense matrix and perform a huge number of
 > arithmetic operations (mostly involving zeros) than it is to use a
 > pure Python implementation that has more favourable asymptotic
 > complexity and theoretically computes the result with 100x fewer
 > arithmetic "operations". In this situation there is a sliding scale
 > where the faster the Python interpreter gets the less often you
 > benefit from calling the C routine in the first place.

Sure, but what's also happening here is that you're optimizing
programmer cost by not writing the sparse algorithm in C, C++, or
Rust.  So I haven't done the math, but I guess to double the
percentage of nonzero matrix elements that constitutes the breakeven
point you need to double the speed of the Python runtime, and I don't
think that's going to happen any time soon.  As far as I can see, any
reasonably anticipatable speedup is quite marginal for you (a 10%
speedup in arithmetic is, I hope, a dream, but that would get you from
5% to 5.5% -- is that really a big deal?)

 > This happens because it works out faster from the perspective of
 > pure Python code that is encumbered by interpreter overhead and has
 > a limited range of C routines to choose from. If the interpreter
 > overhead is less then the options to choose from are improved.

Absolutely.  But the real problem you face is that nobody is writing
routines for sparse matrices in languages that compile to machine code
(or worse, not wrapping already available C libraries).  

 > In the case of SymPy/flint if the maximum speed gain of flint was only
 > 10x then I might not bother using it at all to avoid the complexity of
 > having multiple implementations to choose from and external
 > dependencies etc.

Sure, but my guesstimate is that that would require a 90% speedup in
Python arithmetic.  Really, is that going to happen?

I feel your pain (even though for me it's quite theoretical, my own
data is dense, even impenetrable).  But I just don't see even
potential 10% or 20% speedups in Python overcoming the generic need
for programmers to either (1) accept the practical limits to the size
of data they can work with in Python or (2) bite the bullet and write
C (or ctypes) that can do the calculations 100x as fast as a
well-tuned Python program.

I'm all for Mark's work, and I'm glad somebody's willing to pay him
some approximation to what he's worth, even though I probably won't
benefit myself (nor my students).  But I really don't see the
economics of individual programmers changing very much -- 90% of us
will just use the tried-and-true packages (some of which are
accelerated like NumPy and Pandas), 9% will think for ten minutes and
choose (1) or (2) above, and 1% will do the careful breakeven analysis
you do, and write (and deal with the annoyances of) hybrid code.

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/UWLGL6HGTM6LIUOS2HFZX23GFJDXQPG7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

[Stephen J. Turnbull]

Steve Holden writes:
 > On Thu, May 13, 2021 at 11:07 PM Steven D'Aprano 
 > wrote:
 > 
 > > Steve
 > > (one of the other ones)
 > >
 > 
 > We are all other Steves!

+1

There were five Steves (and one Stephanie) in my 6th grade class (of
27).  "Steve, move that " became an idiom 

-- Other Steve since 1994

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FS6XIKMOD2JIUQINJ6UB7ZRJFCMMR4DN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

[Stephen J. Turnbull]

Abdur-Rahmaan Janhangeer writes:

 > That's why i guess what i am proposing might seem simple

I'm saying that we already have the simple version, spelled

git clone; git checkout main~5000

then

git log -U0 main~5000..main | grep -v '^[-+ ]'

which provides very nice hints for the diligent student, including
description, file, and even line numbers.[1]  Variations on that theme
will provide less detailed hints or you can cheat just a little by
replacing the "| grep" with "; sleep 2; clear".  The possibilities are
endless!

The curated version you propose is, in my "I do that for $DAYJOB"
opinion, very hard to do better than that.

Steve

Footnotes: 
[1]  git is, in my opinion, the 42 of software development.  It is the
answer to life, the universe, and EVERYTHING. :-)

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PFBJQ7I7SDIA225RLAVD6JZ35MNCNP3U/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 659: Specializing Adaptive Interpreter

[Stephen J. Turnbull]

Mark Shannon writes:
 > On 13/05/2021 5:32 am, Terry Reedy wrote:

 > > The claim that starts the Motivation section, "Python is widely 
 > > acknowledged as slow.", has multiple problems.

 > How would you rephrase it, bearing in mind that needs to be short?

We can make CPython run significantly faster, at a reasonable cost
in developer time, without otherwise changing the sematics of the
language.

If you have good justification for saying "as fast as the best JS/Lua
implementations" or whatever, feel free to substitute that for
"significantly faster".

And now this:

 > It is a legitimate concern that CPython is bad for the environment,

It is not.

I do this for a living (5 hours in a research hackathon just this
afternoon on a closely related topic[1]), and I assure you that such
"concern" is legitimate only as a matter of purely speculative
metaphysics.  We don't have the data to analyze the possibilities, and
we don't even have the models if we did have the data.

The implied model that gets you from your tautology to "concern" is
just plain wrong -- work to be done is not independent of the cost of
doing it[2], not to mention several other relevant variables, and cannot
be made so in a useful model.

 > and hopefully make it less of a concern.

It is only a concern in the Tucker Carlson "just asking questions"
mode of "concern".  Really -- it's *that* bad.

 > We want people to be able to write code in Python and have it
 > perform at the level they would get from a good Javascript or lua
 > implementation.

So say that.  Nothing to be ashamed of there!

The work you propose to do is valuable for a lot of valid reasons, the
most important of which is "because we can and there's no immediate
downside".[3]  Stick to those.


Footnotes: 
[1] Yoshida, M., Turnbull, S.J. Voluntary provision of environmental
offsets under monopolistic competition. Int Tax Public Finance
(2021). https://doi.org/10.1007/s10797-020-09630-5.
Paywalled, available from the author, rather specialized, though.  Two
works-in-progress are much more closely related, but I have a paranoid
coauthor so can't say more at this time. :-)

[2]  As Steven d'Aprano points out colorfully, using Parkinson's Law.

[3]  Look up Braess's Paradox for a classic and mathematically simple
example of how reducing cost "with no immediate downside" can increase
expense "once everything works itself out."

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/XK2R7ZUPWTXG4ZDTTE2KB52TFYE6KXEH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Speeding up CPython

[Stephen J. Turnbull]

Abdur-Rahmaan Janhangeer writes:

 > No i mean fake path in the sense of a fork
 > of CPython with issues for learning purposes

*Creating* plausible issues is hard work, I assure you as a university
professor.  Coming up with "exercises" that are not makework requires
expertise in both the domain and in educational psychology.  (Some
people are "just good at it", of course, but it's quite clear from
popular textbooks that most are not.)  I think that would be a very
unproductive use of developer time, especially since "git clone; git
checkout some-tag-in-2017" is pretty much what you're asking for
otherwise.

 > Then people work on solving the issues on their
 > own without PRing.

The problem is not a lack of issues to practice on.  It's that (1) the
PR process itself is a barrier, or at least an annoyance, and (2) many
new contributors need mentoring.  (Or think they do.  Some just need
encouragment, others need help on technique, but both groups are more
or less blocked without the mentoring.)

And, of course, real contribution involves a lot of unfun work.
Writing tests, writing documentation, explaining to other developers
who start out -1 because they don't get it, overcoming your own mental
blocks to changing your submission because *you* don't get it, and on
and on.  A lot of newcomers think "I'm not good at that, if I have to
do it I can't contribute" (and a few selfishly think they can just do
the fun parts and achieve fame and fortune), but you know, "if not
you, then who?  If you don't do it for Python, where are you going to
be able to contribute?"

To be honest, although I'm not a specialist in organizational behavior
and am operating with a small sample, I can say that from the point of
view of identifying tasks, finding solutions, and implementing them,
Python is the most effective non-hierarchical organization I've ever
seen.  I can't say I've seen more than one or two hierarchical
organizations that are significantly better at implementing solutions
and don't burn up their workers in the process -- and the ones I'm
thinking of are way smaller than Python.  (Yes, I know that there are
people who have gotten burned up in Python, too.  We can do better on
that, but Python does not deliberately sacrifice people to the
organization.)

ISTM that Terry is right.  What we need to do better is encourage
people to just start contributing, and help them to get over the
initial humps: git, the PR process, requests from the QA police for
docs and tests and NEWS entries, etc.  Terry's approach seems good to
me on the face of it, and it's "battle-tested".  Terry uses it and has
had some successes.  Maybe that process can be tweaked, but it's a
good recipe.

I suspect that the main reason it doesn't work for Terry outside of
IDLE is that IDLE is where Terry has expertise and motivation to do
emotional work: handholding at the beginning, deeper involvement in
mentoring as necessary.  *And that's as it should be.*  It's up to the
rest of us to do that work on areas *we* care about.

I have to point out that there's a whole crew over on corementorship
doing this work, and at least one Very Senior Developer with their own
private mentoring program.[1]  IMO, that is a big part of why Python
is as successful as it is.  If more senior developers would take on
these tasks it would have a big effect downstream.  But emotional work
is hard, and it comes in big chunks.  In many situations you have to
follow through, on the mentee's schedule, or the mentee will "slip the
hook and swim away."  So it's a big ask.  I'm willing to make that ask
in the abstract, but there's not even one senior developer I'm able to
point to and say "definitely that person would do more for Python by
mentoring than by hacking".  It's a very hard problem.

Footnotes: 
[1]  Why "private"?  Well, why should the junior developers have all
the fun?  The VSDs want to hack too!  So those programs are small and
not terribly well-publicized (and they often have strong "inclusion"
focuses as well as specific focus on areas of improvement).

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VZVIARBQRT3UGOY5RLJB35MUXWGLDYD5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: OTish: Define Protocols near consumers [was: Keeping Python a Duck Typed Language.]

[Stephen J. Turnbull]

Paul Moore writes:

 > What you're missing, I think, is that we're talking about
 > typing.Protocol - see here:
 > https://docs.python.org/3/library/typing.html#typing.Protocol

I understand that we're talking about typing.  What I don't understand
is how any general facility provided in a standard library can be
"defined close to the consumer".  By definition, these facilities are
far from the provider, since they're abstract (whether they're defined
ABCs, "small" protocols, or duck typing).

The point of my example is that indeed, my tiny "SJIS protocol"
*arose* near the original consumer, but it was refined and is now
*defined* "far" from any consumer.  (The fact that it's self-
providing is an accident of the fact that it's a concrete protocol.)
I think that this is a useful process for software development (ie,
design APIs from the point of view of the consumers and then make sure
the backends provide them) but I don't see how this applies to
structuring the Python stdlib or typing.*.

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WT5JCNKYWTXWDR3CA3UYJ4XY5AVJWJU3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Keeping Python a Duck Typed Language.

[Stephen J. Turnbull]

Chris Angelico writes:
 > On Sat, Apr 24, 2021 at 10:14 AM Nick Coghlan  wrote:

 > > Duck typing usually falls squarely into the EAFP category.
 > 
 > Isn't it orthogonal?

Not really.  If you ask 'thing' to 'thing[0]', you don't find out
whether it is a list or a dict (or any number of other things, for
that matter).  EAFP can only verify the presence of the facilities you
actually use, not what thing is, so it *implies* duck-typing.

Nick's statement is not even close to a logical implication, as you
point out, but I think it's the state of the art.  The question I have
is whether that's something essential about duck-typing, or if perhaps
as Gregory points out it's that we don't have TOOWDTI for LYBL duck-
typing.

It's interesting in this regard that so much effort goes into strict
typing and pattern matching which (so far) are LYBL concepts, while
EAFP + duck-typing is "No Reason," "Just Do It" and nobody seems to
have a big problem with that once they get used to it. :-)

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3GQ5LJ43HFQAWNQG65UF7RMNK6T7XAGJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] OTish: Define Protocols near consumers [was: Keeping Python a Duck Typed Language.]

[Stephen J. Turnbull]

Luciano Ramalho writes:

 > A HUGE insight I learned studying Go is that Protocols should be
 > defined near the code that CONSUMES it, and not near the code that
 > PROVIDES it. That's exactly the opposite of how we use ABCs, or
 > Java folks use interfaces (most of the time).

I don't see how that works for "public" protocols or ABCs in a
standard library (maybe I drank too much C in my tea?)  Yes, I write
wrapper classes or factory functions that deal with the niggling
details, even if they're only called once.  And of course that's near
where they're used.  For example, Python's "default" 'shift_jis' codec
uses an ancient version of the coded character set which errors on
about half the Shift JIS files I get nowadays, so I wrote:

def open_sjis(f, **kwargs):
return open(f, encoding='shift_jisx0213', **kwargs)

because I never remember the exact name, and Ireally don't care about
the Shift JIS version, only that it's Japanese and not UTF-8.  When
called, the wrapper function expresses what's going on more clearly
than the builtin call would.  But that seems more like good
programming workflow, not a protocol.

Continuing the example, 'open_sjis' ended up in a small personal "tool
box".  Then it quickly became not a function at all when I realized
that I wasn't going to ever add more "fixed" arguments, and I needed
the string in many other places:

SJIS = 'shift_jisx0213'

*Now* that is a personal protocol, serving the same function of
telling me "this code deals with a legacy Japanese encoding" and
implementing it behind the scenes.  But I don't see how that can be
"defined close to its consumers", which are all over the place,
including interactive sessions.

What am I missing, and how might that be applied to Python?

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WKMYVOGVELPBYXRUG2HSO5XTM53XCDJO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: How about using modern C++ in development of CPython ?

[Stephen J. Turnbull]

Denis,

There's a standard way of interesting the Python community in new
syntax (and C++, while not Python, is new syntax in spades to this
community ;-).

You take a hunk of the standard library (in this case it would have to
be an accelerator written in C since you want to compare C++ vs. C) or
interpreter code, and translate it to the new syntax.

Now, *INCREF and friends are frequently cited as annoyances or even
warts, so your suggestion of std::shared _ptr<> seemed plausible to
me.  But Antoine peeked at it and points out it's not that easy, for
performance reasons you can't use it "as is".  It's true that you
could reimplement it, but then it's not std::shared_ptr<> any more and
the only benefit left is that it looks familiar to C++ programmers
(and may mislead *them* into thinking about it as if it were exactly
std::shared_ptr<>).

And that's why you need to do more work than arguing that in principle
C++ is just a better language than C.  We've been hearing that for 4
decades now (at least we greybeards have), and we've discovered that
for many existing applications, C++ may be better but the cost of
converting large swaths of C code to equivalent C++ that passes all
tests is too big.  Python may very well be one of them.

So if you're not going to do the work to demonstrate big wins from
using C++ instead of C in actual Python implementation code, I think
you're wasting your posts.

Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/WBA5PT6DIMRC6IPMAPAO5VALDVIGRPXX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Typing syntax and ecosystem, take 2

[Stephen J. Turnbull]

Hugh Fisher writes:

 > There are a lot of programmers like me. Those languages I listed
 > are widely used, and therefore we assume that if a Python language
 > construct looks like something we've used before, it will work in
 > the same way.

That's not very persuasive.  When in London, England, you speak
English, but you probably shouldn't assume that the words others use
mean the same thing that they do in London, Ohio.

Anyway, in which of those languages is "def foo(x:float = 1) -> int"
legal syntax?  What do you mean it "looks like" something you've used
before?  It looks to me like what you mean is "To me, declared types
(no matter what they look like) aren't hints, types should be
enforced."  I agree, that's what you learn if your experience is
restricted to common explicitly typed languages, but reality is more
flexible than that.  That's why I read manuals before using a new
language or a feature newly added to a familiar language. :-)

 > > Python's different approach is a compromise.  And as usual Guido's
 > > time machine (or somebody borrowed it) is in evidence: if that example
 > > bothers you, request that people around you who type things like that
 > > use stub files instead so you don't have to deal with it.
 > 
 > And that would be the TypeScript style approach, "typed Python" is a
 > language that gets translated into non-type hinted dynamic Python.

I can't agree.  To me it's the same Python with typed objects and
untyped identifiers it's always been, and that's a feature.  The
question is whether you see the hints in the implementation source, or
in an auxiliary file.  "Typed Python" as currently implemented is not
a different language.  It's the same language with extensive use of a
previously little-used feature (function annotations).

 > No-one who works in JavaScript needs to deal with TypeScript
 > language features unless they want to. This is not true of the
 > current typing in Python.

You *need* to deal with typing only to the extent of ignoring it.  OK,
one of the real selling points of Python is that its syntax is fairly
economical, and type hints do have a cost in that sense.  But the
answer to that is "just don't", and go ahead and ask colleagues you
share code with to "just don't" too.

 > >  > From an environmental point of view we're also doing the read
 > >  > source, lexical scan, syntax parse twice rather than once.
 > >
 > > This is not true.  Most programs, *especially* programs that are
 > > complex enough to want type-checking, are run far more often than they
 > > are type-checked.
 > 
 > Among the software devs I work with, testing and checking is something
 > you do *every* time you make a change. If I'm adding type checks to my
 > program, that's because I want them to be checked.

And that's the last time anybody ever runs that program?  That's
certainly not true of any of the programs I would consider using type
hinting for!  Even the test suite will typically run mypy once, and
the program itself many times since that's the easiest way to
guarantee de novo initialization of the program's state for each test.

 > Historical example would be lint for C programs. Running lint
 > wasn't required before compiling your C code, but it was so useful
 > that a number of projects made it compulsory, and the functionality
 > of lint was eventually incorporated into the C compiler itself.

I think the analogy is valid, but it doesn't support your position.
See Brett's reply for why, I'm just +1-ing here.

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/NCCQJXFHYPBKTUNXKHIWCE35N7UTWNVV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Typing syntax and ecosystem, take 2

[Stephen J. Turnbull]

Hugh Fisher writes:

 > In any Python 3.6 or later, type
 > 
 > >>> x : float = 1
 > >>> isinstance(x, float)
 > >>> type(x)
[snip]
 > As someone who has programmed in FORTRAN, Pascal, C/C++,
 > Java, and Go this is not at all what I consider reasonable.

>From the point of view of typing, you've programmed in one other
language. ;-)  (Maybe Go makes two, I haven't used it.)  They all
demand that variables be declared with types, and then proceed to fill
them with bit patterns that can't be introspected (unless you build it
in to class definitions yourself).

Python's different approach is a compromise.  And as usual Guido's
time machine (or somebody borrowed it) is in evidence: if that example
bothers you, request that people around you who type things like that
use stub files instead so you don't have to deal with it.

If, on the other hand, you want explicitly typed variables (and not
just "if we must have types, I want them integrated", I think you'll
have a serious fight on your hands.  It's often quite useful to me,
for one, that names are not typed while objects are.

 > Having a type checker run before the Python interpreter in our
 > current day continuous build/integration environment adds a
 > second step and therefore the chance for it to be forgotten, for
 > version mismatches, for warning/error reports to be misdirected.

This is a good point, but having an explicitly typed language would
mean I can't really use Python at work (that is, I can't recommend it
to my business and economics students, who don't program, really, they
record scripts).

 > From an environmental point of view we're also doing the read
 > source, lexical scan, syntax parse twice rather than once.

This is not true.  Most programs, *especially* programs that are
complex enough to want type-checking, are run far more often than they
are type-checked.

 > If typing is the future of Python, and the number of PEPs being
 > worked on suggests that it is, then type checking should be
 > integrated into CPython itself.

I don't see it as *the* future of Python.

And I don't really see why it should be integrated into CPython.  To
me it seems to be a language facility, not an implementation facility.
Integrating it with CPython would likely result in disintegrating it
from PyPy and other implementations.  I don't think that is desirable
at all -- the version skew you mentioned would likely occur here.

I like to think of it as "Python typing has some warts, but that's
because it will turn out to be a prince(ss) when you kiss it."  

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/IFS5X4WQDKQANCQH6DULA2HPA6B6K7GH/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Stephen J. Turnbull]

Paul Moore writes:

 > I'm OK with these terms (although I don't actually think you *will*
 > get sufficient consensus on them to make them unambiguous)



 > once the implementation is merged into the CPython source, I think
 > it should simply be referred to as "the implementation" and
 > qualifiers should be unnecessary (and should be considered
 > misleading).

Sounds good to me.

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OAUHG4RSYKJBCWRBDYQ25GOCHRGATKUS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Stephen J. Turnbull]

Greg Ewing writes:
 > On 7/04/21 5:22 am, Brandt Bucher wrote:
 > > we might consider updating those templates if the term "Reference
 > > Implementation" implies a higher standard than "we've put in the
 > > work to make this happen, and you can try it out here"
 > 
 > Maybe "prototype implementation" would be better? I think I've used
 > that term in PEPs before.

That seems to me to correspond well to Brandt's standard as expressed
above.

To me, "prototype implementation" is somewhere between "proof of
concept" and "reference implementation", and I welcome the additional
precision.  The big question is can such terms be used accurately (ie,
do various people assign similar meanings to them)?

I would define them functionally as

proof of concept
demonstrates some of the features, especially those that were
considered "difficult to implement"

prototype implementation
implements the whole spec, so can be used be developers to
prototype applications,

reference implementation
intended to be a complete and accurate implementation of the
specification

By "complete and accurate" I mean that it can be used experimentally
to understand what the spec means without much worry that the
proponent will brush off questions with "oh, that's just not
implemented yet, read the spec if you want to know how it will work
when we're done."  Furthermore, any divergence between spec and
implementation is a bug that is actually a broken promise.  (The
promise implied by "reference".)  Finally, as development continues
there is a promise that the spec and implementation will be kept in
sync (of course changes might be provisional, but even then the sync
should be maintained).

I don't think the Platonic ideal interpretation of "reference
implementation" is very useful.  Software evolves.  It evolves very
quickly during initial development, but it's useful to "ask the
implementation" about the spec even then.  That's implied by
methodologies like test-driven development.  There are other workflows
where that's not true.  My claim is that "reference implementation"
can be useful to distinguish development processes where you expect
the implementation to reliably reflect the spec, even in corner cases,
from those where you shouldn't.  And even as the software evolves.

Note that if we use this definition, then the "Reference
Implementation" requirement of the PEP process becomes quite a high
bar.  I think we all agree on that.  So I advocate, as Brandt
suggested, that we revise the PEP template.  In particular I think it
should use Greg's term "prototype implementation".  Optionally, we
could make "reference implementation" available to proponents who wish
to make that claim about their implementation.

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EB5SAMRY2ZHB6C3XK25GLBJKNJ2WDYUX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Stephen J. Turnbull]

Paul Moore writes:

 > It *is* merged and publicly released - it's in the latest 3.10
 > alpha.

Merged, yes, but in my terminology alphas, betas, and rcs aren't
"public releases", they're merely "accessible to the public".  (I'm
happy to adopt your terminology when you're in the conversation, I'm
just explaining what I meant in my previous post.)

 > The fact that the implementation kept getting referred to as the
 > "reference implementation" confused me into thinking it hadn't been
 > released yet, and that simply isn't true. Calling it "the
 > implementation" avoids that confusion, IMO.

The only thing I understand in that paragraph is "that [it hadn't been
released yet] simply isn't true", which is true enough on your
definition of "released".  But why does "reference implementation"
connote "unreleased"?  That seems to be quite different from Mark's
usage.

I don't have an objection to your usage, I'd just like us all to
converge on a set of terms so that Brandt has a compact way of saying
"as far as I know, for the specification under discussion this
implementation is completely accurate and folks are welcome to refer
to the PEP, to the code, or to divergences as seems appropriate to
them".  I'm not sure if that's exactly what Brandt meant by "reference
implementation", but that's how I understood it.

Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/JLDWPW52OXGR27W4GFGU4GVDOXA6PXGD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: NOTE: Python 3.9.3 contains an unintentional ABI incompatibility leading to crashes on 32-bit systems

[Stephen J. Turnbull]

Matthias Klose writes:

 > No, you can't see that with CPython's CI alone.  The Debian and
 > Ubuntu build machines trigger CI tests per architecture for around
 > 3000 packages depending on python3.9, using the just built
 > python3.9, and without rebuilding these packages.  That's where I
 > see the 32bit failures.

Thank you, that's what I wanted to know.

 > How would delaying the release schedule have helped with the issue
 > that we just saw?

I mean to have a period between the announcement of the release date,
and the actual release.

So it works the same way an rc would, except not rolling the tarball
etc.  For almost zero maintainer effort, tag it "rc", give you a few
days to run your tests on builds from git.  If you (and others) don't
report a problem, he tags "final" and then produces tarballs,
installers, etc to the extent those things are done at this point in
the version's lifecycle.

Distros could either drop the "rc" in hopes that this commit will
indeed be final (and reroll their release if bugs are found), or they
could use the sha1 as identifier for the specific commit instead of
stuff like "rc" in versioning the package.  (I'm brainstorming, this
is *not* a thought-out recommendation!)

See also Terry Reedy's post for a different explanation of what I
believe is the same idea.

Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RHBTR6ICP5LKRXAAX4I4I6UBSMZXB3O3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: NOTE: Python 3.9.3 contains an unintentional ABI incompatibility leading to crashes on 32-bit systems

[Stephen J. Turnbull]

Matthias Klose writes:

 > Looking at the failing CI tests triggered by these builds, yes I
 > see that 32bit archs have the ABI change.

I'm not sure precisely what you mean by that, but if you mean that CI
has caught the bug, then

 > So maybe it's worth to re-introduce these RC builds,

seems to be just makework.  It makes more sense to delay the schedule
somewhat, but only so that the release engineer, or one among the many
eyes, catch the CI's warning.

Steve


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/A642IMRBVHBNMWMTE4VOZLSOCQGAZIBC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Stephen J. Turnbull]

Mark Shannon writes:

 > Calling something a "reference" implementation suggests that it is 
 > something that people can refer to, that is near perfectly correct and 
 > fills in the gaps in the specification.

Shoe fits, doesn't it?  Both Guido and Brandt to my recall have
specifically considered the possibility that the implementation is the
better design, and therefore that the PEP should be changed.

 > That is a high standard, and one that is very difficult to attain.

That depends on context, doesn't it?  In the case of a public release,
yes, it's a very high standard.  In the context of a feature in
development, it *cannot* be that high, because even when the spec and
the implementation are in *perfect* agreement, both may be changed in
the light of experience or a change in requirements.

Furthermore, in this instance, the implementation achieves *your*
standard (Brandt, again):

 > > both authors have agreed that it needs to be fixed in the PEP,
 > > not the implementation

You added:

 > It is why I use the term "implementation", and not "reference 
 > implementation" in my PEPs.

A reasonable usage.

I think my more flexible, context-dependent definition is more useful.
Unmodified, the word "implementation" covers everything from
unrunnable pseudo-code to the high standard of a public release that
is officially denoted "reference implementation".

On the other hand, when Brandt says that a merge request is a
"reference implementation", I interpret that to be a claim that, to
his knowledge the MR is a perfect implementation of the specification,
and an invitation to criticize the specification by referring to that
implementation.  That's a strong claim, even in my interpretation.
However, I think that if the developer dares to make it, it's very
useful to reviewers.

As it was in this case.

Final note: once this is merged and publicly released, it will lose
its status as reference implementation in the above, strong sense.
Any deviations from documented spec (the Language Reference) will be
presumed to have to be fixed in the implementation (with due
consideration for backward compatibility).  "Although practicality
beats purity," of course, but treating the Language Reference as
authoritative is strongly preferred to keeping the implementation and
modifying the Reference (at least as I understand it).

Regards,
Steve

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/AOM3ZPO4U263T2ZYGDOLFWIDOO2QSKZB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Request for comments on final version of PEP 653 (Precise Semantics for Pattern Matching)

[Stephen J. Turnbull]

Antoine Pitrou writes:

 > On Sun, 04 Apr 2021 00:34:18 -
 > "Brandt Bucher"  wrote:

 > > Can you please stop putting scare quotes

 > I'm not a native English speaker, but I don't understand how
 > putting quotes around a reasonably polite expression devalues
 > anyone's work.

"Scare quotes" refers to an idiom English writers use to deprecate
something.

In what I wrote just above, the quotation marks indicate a focus on
the *string* "scare quotes".  In this case, the fact that they are the
exact words of Brandt, and also that I'm defining those words, not
using their meaning.

In Mark's phrase '"reference" implementation', neither of those usages
apply.  It's possible that they are the deprecated "random quote
emphasis" usage.  Random quote emphasis is implausible here, however.
I can see no reason why Mark would emphasize the modifier "reference"
in this context.

One of the most important remaining usages, and one that I find
plausible in context, is scare quotes.  These are quotation marks used
to focus on the phrase in quotes, and indicate that it is somehow
suspicious: inaccurate, imprecise, false, even the opposite of its
dictionary meaning.

In other words, if you don't have a reason to emphasize focus on the
words themselves rather than their meaning, by adding (scare) quotes
most likely you are turning a "reasonably polite expression" into an
insult.

 > I'm probably missing something...

Probably so did a lot of native speakers; there are English dialects
where scare quotes are rare and random quote emphasis is common.

However, I assure you, many native speakers (along with a fair number
of non-natives) did not.

I neither know nor care what Mark's *intent* is.  I'm explaining what
(some) idiomatic speakers of English will read into what he writes,
because it is a *common* idiom (common enough to have a name, and be
mentioned in standard manuals of English style).

Regards,
Steve


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KZ3U2JXRHYRXRUDAGNRKPBI6UHUKAJ7X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

[Stephen J. Turnbull]

Paul Moore writes:

 > The one thing that *is* substantially worse for Python, is the
 > circumlocutions needed in the documentation to say how to run Python.
 > But that's 100% down to us not being willing to say "just type the
 > command python". And the reason for *that* is mostly historical,
 > related to the Python 3 transition

I don't think that's entirely true, and the roots are much earlier
than Python 3.  We had the same problem with Linux distributions
(especially Red Hat) and version 1 vs. version 2.  This was crucial
for those of us handling multibyte languages: getting Unicode Inside,
even in the non-str form of Python 2, really changed things.  But
Python 2.0 was a .0 release.  For a lot of developers dealing with
unibyte languages, 1.5.2 was the workhorse until about Python 2.2.

 > and what happened on Linux over the python/python2/python3
 > commands, and to a lesser extent the introduction of the launcher
 > on Windows

I don't know about Windows.  It might have been possible to arrange
that just "python" was the right way to do things, and have "-2" and
"-3" flags for specifying compatibility.  But it just wasn't possible
on *nix systems because /usr/bin/python was typically used for system
software.  They shouldn't have done that (they should have kept in it
in an OS-specific place and used full shebangs), but that's not how it
went 

I think those are important things to keep in mind when comparing with
a very young language like Julia (Julia didn't make *any* backward
compatibility promises until 1.0 in August 2018).  A lot of Python's
problems occur *because* of its multi-use potential and *because* of
its wide adoption in practice.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/S7H6W75N62YGW5L2WYQH53BTFDJJWRZK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

[Stephen J. Turnbull]

Jim J. Jewett writes:

 > > which file am I actually running?
 > > which interpreter am I actually running?
 > > how do I tell the computer to use a different interpreter?
 > 
 > If you need to care about any of these, then the environment is
 > fighting you -- and the application probably stinks.  Programmers
 > have to deal with it because of bootstrapping, but there is no
 > reason that we should assume all python users need that flexibility
 > or want that responsibility.

Be careful!  I agree about need for flexibility and desire for
responsibility, but in fact these problems present themselves
frequently when helping people with their work.  "Which file am I
actually [edit]ing?" is one that comes up in just about every meeting:
documents are undated (or dated with the deadline date), people are
looking at different versions, and not infrequently the presenter
themself has a Documents/Downloads confusion and gets it wrong.  Then
"where is the one I want to be editing?" requires an oracle. :-)
"Which program am I running?" doesn't come up that often, but it does
come up when helping people with "doing something", especially trying
to find menu items across major versions.  Interestingly enough, "how
do I tell the computer to use a different interpreter?"  doesn't come
up for me outside of Python (and even there rarely) -- everybody who
consults me knows how to use "Open With".

So I agree with the basic principle that programs should Just Work by
default, but it's not always possible.  Eg, there's good reason why
Downloads and Documents both exist.  So it helps to have users know
something about implementations and sysadminning stuff, especially
when remote troubleshooting.

The question for Python is given the history and the plethora of ways
to invoke Python and find packages and programs, can we do better with
a minimum of backward incompatibility?  Humans are generally better at
learning this stuff than bags of bits on spinning platters are!
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/OAYWDLL26YTSIFTKGL6LWP7TU4PXUH6K/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

[Stephen J. Turnbull]

Executive summary: This thread is about a "seven blind men and an
elephant" problem.

Jim J. Jewett writes:

 > I think his point is that most of his students (economics or
 > business, rather than comp sci) will never need to use Perl or C or
 > Java.  Python is friendly enough to be useful, but this is still a
 > major pain point.

Not sure if "his" refers to me, but I don't know what they're going to
need to use.  C/C++, maybe not, but there are a lot of Perl and
especially Java shops in Tokyo still.  The largest group of my
students end up as what the Japanese call "SE" ("systems engineers"),
by which they mean a sales/requirements gathering/training/customer
relations role.  Many of the rest end up in tech-adjacent roles.  I
think all of them would benefit from a little command-line experience,
and a better understanding of how a group of programs cooperates to
become a system.  As their teacher, I certainly would!

 > The problem is made worse because it often hits at the beginning
 > instead of 7 lessons in, when they would have some reason to think
 > it is worth struggling through and will eventually work.

I think we're on the same page, but "7 lessons in" is still early in
my experience teaching Python.  Languages where you have to explicitly
invoke a compiler and then run the executable, maybe you run into the
problem "at the beginning" (shades of Chapter 1 of _The C Programming
Language_!), but not with Python.  Where my students run into problems
is when they *know* it was all worth it, because *now* they're ready
to use Python to do whatever it is they style "real work" -- and need
to install, maybe configure, and learn to use something that isn't an
included battery.  Even in a well-curated framework like Anaconda,
"you can make a bottle adult-proof, but not child-proof".

So *my* point (I don't speak for anyone else) is pessimistic.  I don't
think there's a one-size-fits-all solution to child-proofness.  What
we need is children with better vocabularies.

>From my point of view, what I want is to talk to students (and
colleagues!) about problems that I can often solve or install a
workaround in a few minutes.  But when simple questions like "what
distribution did you install?" gets the answer "I just downloaded the
package.  What's a distribution?", and the followup is, "well, where
did you get it?", "I clicked on the top link in Google", which leads
to "well, is it this one?" and "I can't tell...", it's very
frustrating for all concerned -- and we haven't even started on the
new package that isn't working.

When to them, it's pure fsckin' magic, and to me, it's muscle memory,
problem-solving across the gap is hard.  For my purpose, cross-
platform distributions like Anaconda seem to be the best solution
available now and for the near future.  But for many developers, they
have enough problems without dealing with the idea that some other
application has different version or configuration requirements for
some components.

I just don't see a world where any of the points of view are without
merit.  People with more space than apps can put them *all* in venvs,
people with relatively simple "external" requirements can just use a
single installation, and people with the necessary skills can mostly
use the single installation and put a few "problem children" into
venvs of their own.  Each of those groups will want Python itself to
take a different approach to the "problem".

So the question in the subject is valid and should be raised once in a
while, but the answer is always going to disappoint a majority. :-)

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/COTOLXA4I76KMBPFQ2J5RQWNKKYCPRGE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

[Stephen J. Turnbull]

Steven D'Aprano writes:
 > On Fri, Feb 26, 2021 at 11:41:56AM +0900, Stephen J. Turnbull wrote:

 > > That's what I would mean by basic sys-admin skills.  And *surprise!*
 > > my students don't have them, and don't need them ... until they start
 > > using Python.
 > 
 > Is it *only* Python though? Wouldn't that be necessary if they were 
 > learning Perl, Java, C, Ruby etc?

I'm sure it is.  But as I say *my* students are pretty naive, so they
only use languages supported by me (Python and R, but almost
exclusively Python) in Jupyter and installed via Conda.  Not a lot of
folks around here can speak all of those, Japanese, and English, and
read minds in Chinese.[1]  Otherwise they use site-licensed commercial
software (mostly SPSS, Mathematica, and office software).

Footnotes: 
[1]  This is the easiest part of all.  It's not hard to guess what the
students are whispering in Chinese when you've just prohibited use of
Chinese in the seminar room. :-)
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/KHXH5D6LBSADHZ2NMIWWNUK2CE6IZ42Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

[Stephen J. Turnbull]

Mike Miller writes:

 > "sys-admin" is a bit of an overstatement in my phrasing.  The core
 > is that you need to understand how a PATH works and be able to run
 > pip and cd into folders and perhaps run rm/del, etc.  Basic
 > command-line skills?

That's what I would mean by basic sys-admin skills.  And *surprise!*
my students don't have them, and don't need them ... until they start
using Python.  They don't even understand installing packages in
conda.

If I had my druthers, we wouldn't have classes in Excel and
Powerpoint, and we wouldn't have classes in SPSS and SAS, and we
wouldn't even have classes in Python -- we'd have classes in envars,
registry, and shell scripts/bat files.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RJAZJLN6W76QONKD3K2UG6BPTOXPWE4D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Security releases of CPython

[Stephen J. Turnbull]

Mike Miller writes:

 > Sounds like automating until it is "just a push of a button,"
 > should be a goal. According to Victor there has been progress, but
 > always room for more.

When XEmacs was releasing betas regularly, everything from tagging the
local authoritative repo to pushing to the public repo to making
tarballs to signing and authenticating them to Mad-Libbing the form
for announcement was invocation of a single script.  "Somehow" the
typical release was a me-day's work and three calendar days (and unlike
GNU Emacs with its "kitchen sink" standard library or Python with its
batteries from CR-25s to Prius power replacements, XEmacs was just the
Lisp interpreter and basic editor functions).

What takes the time?

1. A courtesy pre-announcement to core devs that the release was
   coming (yes, it's on the schedule, no, they don't check their
   calendars).
2. Triaging incomplete tasks other folks labeled as "important" or above.
3. Writing news (somebody always forgets, and typically the choice was
   write it myself or delay the release).
4. Triaging last-minute "urgent" commits.  (They rarely were.)
5. Triaging and where possible fixing test failures.
6. Rolling back premature commits.
7. Scheduling future work that didn't *need* to be in a beta release
   (we had a couple of developers who were trying but couldn't write
   documentation grammatically to save their commits; it just didn't
   make sense to force them to do work I could do in 1/10 the effort).
8. Coordination with the dev who built Windows installers.  (A few
   Windows users could get pretty cranky if they didn't get an
   installer within a couple hours after the Unix-oriented tarball
   releases.)

The Python process is more disciplined, and has a lot of automation to
help with the QA stuff.  But there's always last-minute "people work",
which is what Brooks would call an "essential difficulty."  It's
pretty irreducible.  I would imagine the same is true for Python RMs.

 > I would argue that security releases are of higher importance than
 > most, 

*Some* of them are, but this just isn't true most of the time.  Take
the very recent CVE-2021-3177, rated 9.8 ("critical", 9.8 out of 10, I
believe) because it *might* lead to remote code execution (RCE) under
(implausible, AFAICS) conditions in current Python.  There is no RCE
exploit for arbitrary Python webapps: there are a bunch of other
conditions that must be satisfied.  It might be possible to create a
denial of service for some webapps, but that still depends on only
somewhat more plausible conditions.

Then, why 9.8?  Well, "remote code execution".  The critical rating is
a *threat* assessment, based on *everything* going right for the
attacker, not a *risk* assessment, based on likelihood and degree of
damage.  Most reported vulnerabilities have no known exploit and
potential RCE is not the common case: risk is quite small.

Such vulnerabilities must be fixed: as time goes on, risk increases.
Not just more time = more time for the black hats, but the hazard rate
increases too.  The particular currently implausible kill chain may be
generalized or others may arise in future versions of Python, or more
webapps may incorporate the risky behavior, etc.  But there's no
reason to believe it will be a known exploit soon, and anybody with a
million dollars at risk can (and should) keep a couple of hours of
junior developer time on call to assess risk and apply the patch if
needed.  Not to mention that in 2025 there will still be a bunch of
vulnerable 3.8 and 3.9 installations online, which are still whatever
the patchlevel was when they were originally installed.

I believe that had they let this one wait until the scheduled release,
the odds are 1000:1 that *no harm whatsoever* would have been done in
that window.  Nevertheless, the relevant release managers (3.8, 3.9,
and Windows) chose to make a quick release.  I think "customer
relations" (which are important, I'm not deprecating them!)  had as
much to do with the decision as the assessment of risk to Python
users.  I am not going to second-guess the actual decision, but I do
think that this is very much a case by case issue not very different
from any "urgent" defect, and in many cases "wait for scheduled
release" is going to be a no-brainer, and in others that will be the
outcome chosen.

Some of the time, there will be an emergency release.  That has been
demonstrated to be possible and realistic, even in a case like this
where the need is not open-and-shut.  I don't see a need for anything
except more love for the release managers.  Of course IWBNI we had the
resources to pay release managers.  But we're doing OK.

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 

[Python-Dev] Re: Python standardization

[Stephen J. Turnbull]

Paul Sokolovsky writes:
 > Hello,
 > 
 > On Sat, 13 Feb 2021 23:10:59 +0900
 > "Stephen J. Turnbull"  wrote:
 > 
 > > Chris Angelico writes:
 > > 
 > >  > Can you explain what would be improved by having a formalized
 > >  > standard?  
 > > 
 > > The Language Reference together with the Library Reference *already*
 > > constitute a formalized standard.  They are at least as precise as
 > > most W3C or IETF standards.
 > 
 > You must be kidding, right? Library Reference is full of
 > underspecification and gaps.

No, I'm not kidding.  Did you read what I wrote?  I did not write that
the Python References are perfect and suitable for automatic
validation.  I wrote that they are of similar quality to most
standards published by the IETF or W3C.

They are, in my experience.  (And at least the IETF email working
groups have a much easier task, since it's mostly restricted to syntax
of wire protocols -- most semantics are left up to the receiving
agents.)  For example, the first attempt at a careful description of
how the many agents in the email system interact is RFC 5598 (from
2009), while the current controlling RFC for message format is RFC
5322 (from 2008), and the actual standard is STD 11 = RFC 822 (from
1982!).  You think you have problems defining free variables in a code
block, the IETF email working groups literally operated for decades
without trying to define some important terms!

If you want more precise definitions and complete specifications in
the Language Reference and Library Reference, put them there yourself,
and encourage others to do the same.  We'll all thank you.  And you
can be thankful that you only have to get them past the Steering
Council, not the member nations (!) of ISO/IEC Joint Technical
Committee 1 / Subcommittee 22 / Working Group 21. :-)

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LPTIXDDMFK6T7SZVLBQ4IPILLMOKY45X/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python standardization

[Stephen J. Turnbull]

Chris Angelico writes:

 > Can you explain what would be improved by having a formalized
 > standard?

The Language Reference together with the Library Reference *already*
constitute a formalized standard.  They are at least as precise as
most W3C or IETF standards.

What you and Dan seem to be referring to is a standard sanctioned by a
major, preferably international, umbrella standards organization.  But
in fact a standard is just a sufficiently precise specification that
allows multiple independent implementations to achieve the same
results, and is accepted by more than one implementer.

 > So far this thread has just been vague ideas that a bureaucratic
 > procedure will somehow help things, without showing a problem.

Python *has* a bureaucratic procedure, it's called "the PEP process".
It's true that the standard library accretes a lot of small changes
without PEPs, but usually any conformant implementation can compile
(or whatever) them without change because they're implemented in
(*gasp*!) Standard Python of the same version.  And they must be
documented (ie, made part of the Reference), or the merge request will
not be accepted.  We now even have a full-on bureacracy (the Steering
Council, sorry folks, but that's what you are).

The main difference between the Python PEP process and the
standardization processes of international bodies such as ECMA, ISO,
W3C, and IETF is the Code of Conduct leading to much more civil
discussions, and the lack of interest[1] of corporations in getting
their patented tech sanctioned in it[2].

There's also the procedural facts that (1) Python really produces only
one standard (no need for an umbrella organization to police the
working committees), and (2) there is no formal voting procedure to
permit log-rolling by such special interests.  But I see no need for
one, given the trust the community had in Guido (sorry for the name
check, Guido, but it's true you know) and now in the Steering
Council.[3]  The voting procedures in other bodies are required
because many of the participants mistrust each other.  However, a
standard should be judged by its content, not the formality (or lack
of it) of the standardization process.

Dan Stromberg points to potential issues with a reference
implementation.  But by definition, a *reference* implementation
implements a standard.  This is only a problem if the standard is
sufficiently sloppy that the only way to determine conformance of an
alternative implementation is by comparing behavior to the reference
implementation.  But that's not a problem with reference
implementations, that's a problem with the particular standard.  It's
true that frequently it's (much) more convenient to ask your friendly
neighborhood Python interpreter what some expression does than to try
to figure it out from the reference (David Beazley has made a PyCon
speaking career out of such oddities!), but that's a *benefit* of the
reference implementation, not a problem.

There's another kind of standard, where the "reference" implementation
*is* the standard.[4]  If the docs differ from the implementation, you
change the docs.  That's *not true* (in principle) for Python, except
that fairly often where the docs are ambiguous and it matters, the
standard will be amended in the next version to conform to CPython's
behavior.  However, where the behavior of CPython contradicts the
references, that's considered to be a bug to be fixed.  Amending the
docs in those cases does happen, but it's controversial and needs to
be supported by showing that the implementation behavior is depended
on by applications in the wild.

Also note the characterization of CPython in
https://en.wikipedia.org/wiki/Reference_implementation.  (I didn't
check to see if a Pythonista were the most recent editor tho. ;-)

Steve

Footnotes: 
[1]  Or perhaps their recognition that it's a no-go and not worth
their effort.

[2]  Even there, occasionally powerful core developers have been able
to push through features they wanted for $DAYJOB (async and type
hints, I'm looking at you).  Those would have been major firefights in
the absence of trust.

[3]  Case in point: The pattern-matching PEPs are controversial, but
note that *nobody* has questioned the legitimacy of the SC, only its
judgment, when questioning the approval of that series of PEPs.  And
the general reaction has been "great, now we can move on with it!", as
far as I can tell.

[4]  I'm pretty sure there's a different term for such implementations
but for the life of me I can't remember it.  Or it's possible that
"reference implementation" was the right term for "the implementation
is the standard", and the meaning has changed since nobody does that
any more (or at least nobody with a shred of pride is willing to admit
it).  Anyway, now the accepted meaning of reference implementation is
that it is an implementation that satisfies all requirements of the
(separate) standard.
___

[Python-Dev] Enum bug?

[Stephen J. Turnbull]

Paul Bryan via Python-Dev writes:

 > Should this be considered a bug in the Enum implementation?

Probably not.  The underlying implementation of Enums is integers, and
False and True *are* the integers 0 and 1 for most purposes.  And it
propagates further.  Same example:

>>> class Foo(enum.Enum):
...  A=True
...  B=1
...  C=0
...  D=False
... 
>>> Foo.B

>>> 

This amusing artifact was discussed in another thread recently.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/PI3E3R5YWM4HGFLUQGNS327QD3AQXY4Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] minor PR 22981 waiting review ~20 days: https://github.com/python/cpython/pull/22981

[Stephen J. Turnbull]

Alfred Perlstein writes:

 > PR 22981 is a minor update to doctest to allow it to safely consume 
 > modules which contain objects that cause inspect.unwrap to throw.
 > 
 > I believe the review comments in the PR have been addressed at this 
 > point for ~20 days.  The patch is relatively small, reviews are done, 
 > but it is unmerged.
 > 
 > Is there a way to "bump" the request for review?

The most direct way is post an update requesting review to the issue,
which will notify those subscribed to it.

Your message to python-dev is the slightly louder way to do that.  (In
the sense that will be seen by more committers, but of course a random
core person is definitely less likely to do anything than someone
who's posted to the issue.)

Those are the "traditional" ways.  There are usually quite a few
people about in the discourse server.  I'm not sure whether asking for
a committer's attention there is appropriate (I'm an email-based
person, not really familiar with the discourse usage).  Check the
archives and see if people do that, I guess.

You seem to be very familiar with review processes, so it probably
doesn't apply to you, but for completeness I'll mention the
core-mentorship mailing list, where you can get advice from someone on
how the process works and what committers are looking for in a PR.
Typically they will also commit one or more of the mentee's PRs in the
process.  This isn't an appropriate venue if you just want to make
sure that your contribution's status is noticed, though.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/RX3VCE2RDM65TGZ7DUAOBKPJNKTVYUMQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

[Stephen J. Turnbull]

Paul Sokolovsky writes:

 > Sorry, but there may be a suggestion of tactics of sneaking somebody's
 > "pet feature" past the attention of core developers by employing
 > sycophant techniques.

I've had enough of your random aspersions.  They make it impossible
for me to continue reading your posts.  I'll join David with a
"moderate" -100 on your proposals, and bid you "good day".
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/3BAYVC53Z7ZS2UQ4NLAJGIBFJ62DI3NK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

[Stephen J. Turnbull]

Paul Sokolovsky writes:

 > Also to clarify, [cowboy attitude] referred to difference in
 > approaches in response to particular issue(s) raised. One thing is
 > to say "it's hard to implement it better with the limited VM
 > infrastructure and resources we have" (that of course leads to
 > further questions/discussion), it's different thing to say to the
 > same matter "issue exists, but it's not really an issue".

Of course those are *different*.  Where I differ with you is on
whether "I understand the case are describing and that you want to do
something about it, but we don't consider that a problem" is "cowboy
attitude".

My experience is that the development community will care when it
perceives that a change serves the greater community (eg, f-strings
and data classes, which are universally loved), or when a sufficiently
large coalition of committers can be convinced.  That's what you need
to do, and accusing the core developers of cowboy attitude is not a
good start IMO.

 > Maybe one of these years would be good time, after so many
 > usability changes, to also tighten up theoretical side with
 > block-level scoping.

Maybe it is.  I certainly hope not, because I like Python as it is,
where I rarely have to deal with declarations separate from
instantiation, and code is highly dynamic without a compiler
complaining, perhaps even going on strike, any time I want to do
something whose semantics I know to be sound even though the compiler
can't prove that from the syntax.

Yes, I know you claim that your proposed syntax won't be in my face,
and quite possibly you're right with respect to the obstreperous
compiler.  But I also know that you make claims that are provably
false, such as not making me use the syntax.  True, short of XKCD 538
you can't make me write it, but if it exists somebody will make me
read it.

 > The simplest answer is that they don't (interact with existing
 > overdynamic features).

You say "overdynamic", I say "works for me".

 > They are new enough, opt-in concepts, and so can start from blank
 > page.

You're BS-ing here -- you back off in the next sentence (quoted
below).  And from the community's point of view, no syntax is truly
opt-in because we often work with Other People's Code.  We need to
read it, and often in open source we are modifying code whose style is
"owned" by someone else -- if I were to work on code you maintain, I'm
pretty sure you wouldn't hesitate to query "shouldn't this variable be
block local" or even refuse to accept code that didn't have the block
locals you think it should have.

A lot of effort and persuasion (and more or less silent acceptance of
the slings and arrows from outraged dynamicists) went into the
introduction of type hints.  I think this will require more of the
same (although maybe not: type hints are intentionally pervasive for
those who use them, these declarations will presumably be occasional).

 > Alternatively, if debuggers, etc. are tied to locals() (vs more
 > low-level code object introspection), could add
 > implementation-defined support for them in locals() for simple
 > implementations like CPython (block-local names will be mangled).

Sure, but we don't have an implementation of that support yet, do we?
And adding the syntax will impose burdens on other implementations
that claim to support the full language, as well as quite possibly
inducing implementation differences here, unless you specify the
debugger support etc.  My point is that these are the kinds of
complications that frequently delay acceptance of features for a
release or two.

 > > I suspect that when I'm reading other people's code I'd almost
 > > certainly read a let/const var = init_val as suite- local in such
 > > contexts, while in my own code I'd probably want to use it as
 > > statement-local a lot.
 > 
 > It's unclear how block-level scoping can be useful for single-statement
 > scopes (beyond special cases like comprehensions), because well, that
 > single statement will be assignment to such a variable (but nothing
 > will read it). I even suspect we might imagine different things when
 > talk about this, perhaps examples would help.

By "if statement" I mean

if foo():
pass
elif bar():
pass
else:
pass

That is a single conditional *statement* with three suites that each
might constitute an individual block or together constitute a single
block (encompassing the if and elif condition expressions as well).  I
believe that's how the Python Language Reference uses "statement".

 > 1. We have adhoc block-scope-alikes already.

Yes, there's the problematic deletion of exception-capture variables,
but I don't think the plural is justified.  Comprehensions are
*expressions*, not suites.  Python is a *high level* language: the
fact that

[x for x in y]

effectively expands to

list((x for x in y)) ,

implicitly defining a generator function and iterating that, doesn't
bother me at all.  It's an expression, 

[Python-Dev] Re: Pattern Matching controversy: Don't read PEP 635, read DLS'20 paper instead

[Stephen J. Turnbull]

Paul Sokolovsky writes:

 > Well, I'd call that "cowboy attitude in programming language
 > design" ;-).

That was uncalled for, especially since you're selling an idea without
an implementation yourself.

 > We'd certainly make it blend well with the rest of Python.

But how long will that take?  People have wanted f-strings since
forever (1.5 is as far back as I go, PEP 215 was July 2000).  We got
them in 3.6 (December 2016), the delay basically due to "blending"
issues.  And that was for a quite self-contained feature.

This one strikes me as likely to be messy.  How does we get
consistency if we don't change for?  How do block locals interact with
global, nonlocal, and locals()?  Do we need a block_locals()?

Currently all suites in a multiarmed statement (if, for, while, try)
are in the same scope.  I suspect that when I'm reading other people's
code I'd almost certainly read a let/const var = init_val as suite-
local in such contexts, while in my own code I'd probably want to use
it as statement-local a lot.  Of course that latter is easy to handle
by creating a new suite with something like "if 1" (as you suggest
elsewhere), but creating unconditional 1-statement suites just to
declare block-locals seems excessively inelegant. :-/  But requiring a
"block" statement to create a slope in common cases like a one-armed
if or for is equally inelegant (and surely more common).

 > The problem is that intuitively (just like with "for"),
 > "case a, b if a != b:" opens a new namespace for "a" and "b".

I don't find a new namespace in either of those contexts intuitive at
all.  Nor do I find it unintuitive at all.  A language will define
rules for scoping, I'll learn them.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/DTNTZ5NKV7RELXOK3DUZ7KLSNI52344O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Ideas for improving the contribution experience

[Stephen J. Turnbull]

 > My suggestion: create the developers by creating group(s) of
 > mentors

Do you know about

https://mail.python.org/mailman3/lists/core-mentorship.python.org/

and if you do, why isn't that what you suggest?
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/EC4OGSZGEX3C46LCDMBIHBGTYQJBZK7Y/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[Stephen J. Turnbull]

Glenn Linderman writes:

 > Mathematics never came up with separate symbols for equality and
 > assignment.

Mathematics doesn't need them, until we come to an age where we do
mathematics on algorithms.  It's perfectly possible to do algebra
interpreting "let x = 3" as an equation of the form "f(x) = g(x)"
rather than an assignment.

 > In your example "solve c = f(x) for x", that is not an assignment 
 > operator, but an equality comparison operator in an equation.

But "=" is sugar, not syntax, in the "let" form, and although it is
syntax in the "solve" form, in both cases it is the keyword "let" or
"solve" that denotes assignment.  So "solve c = f(x) for x" *can* be
interpreted as an assignment to x.

 > But note that your example is wordier than "let c = f(x)" which
 > would be an assignment operation. And note that it _needs to be
 > wordier_ to convey the proper mathematical semantics.

Wordiness in defense of readability is no sin, at least not in Python.
:-)  In exactly the same way as you describe for the "solve" example,
a destructuring pattern match is necessarily wordier than simple
assignments to the component variables would be.  So I don't see an
issue here.

 > Just because something is syntactically unambiguous, doesn't mean it 
 > makes a good user interface.

I didn't (and don't) argue it does.  I argue it works for me, and if
it works for Guido too, I refuse to feel bad about that. ;-)  If it
doesn't work for a large majority of people who would use pattern
matching in Python, who would want to destructure "Point(x=a,y=b)",
it's bad UI.  I don't know that's true yet, so I want to oppose false
statements like "there's no analogy to this" (which is not quite what
Jim said).

Tastes differ, those differences are valid, and to some extent the
majority rules here (although I've seen in the past that some folks
are much better judges of *future* majorities than others! ;-)

Steve
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/VSH35V3QZZPIPDCMY76NWKV35JSITUUQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 642 v2: Explicit constraint patterns *without* question marks in the syntax

[Stephen J. Turnbull]

Jim J. Jewett writes:

 > What advantage can there be in re-using syntax to mean something
 > opposite to what it normally does?

In math, it allows us to write "solve c = f(x) for x".  That doesn't
mean "bind c to the value f(x)", it means exactly the opposite.  No
problem here, I suppose.  So

match p:
case Point(x=a, y=b):

is a way of saying "solve p = Point(x=a, y=b) for a and b".

I understand your distaste for this syntax, but I see no problem
in principle.  It's a problem of programmer habits and the evident
inconsistency with forms like "case Point(x=1, y=2)".  This is
especially true when a or b is already bound.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/4G5D3DAI7B77LF3GD2YIOQZUBKYFUD7P/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Please do not remove random bits of information from the tutorial

[Stephen J. Turnbull]

Ned Batchelder writes:

 > I feel like we are missing a key element of Riccardo's point:
 > "without editorial guidance."   Changes are being made without
 > first having an agreement about what the tutorial should be.

That's really unfortunate.  But there also ought to be an editorial
activity, such as a "tutorial-SIG" within the docs working group (ie,
informality within informality -- IMO the most formal this should get
is a mailing list/discuss channel, and maybe a tracker tag) to have
some visibility into whether changes serve those purposes.

 > Personally, I would rather the tutorial did not try to cover 
 > everything.  If something is only useful to 10% of the readers, I'd 
 > prefer to cover it elsewhere.

I'd raise that 10%, maybe as high as 50%.  Or maybe that's the wrong
dimension to measure, and we should aim for a tutorial that covers
enough for 50% of the readers to write a program that gives them more
utility than just amusement and a feeling of accomplishment.

 > Adding tutorial-style content throughout the rest of the reference
 > documentation seems a fine solution to me.

That's fine if the user knows what to look for, but is it really
discoverable?  In general, I would think that tutorial material should
be most easily discoverable on its own, and that the tutorial should
link to the reference material, and the reference should link, rather
than include, that tutorial.  And should "tutorial" material in a
reference really go beyond short examples of typical use cases?

Maybe these purposes would be be better served by domain-specifici
HOWTOs.  Eg, HOWTO write a mail filter using the mailbox and email
modules.  HOWTO write a web spider using requests and aiohttp.

 > As a compromise, we could include full text for the 80% features in the 
 > tutorial, and in each section, include links to "other topics" or 
 > "advanced features" in other sections.  This would leave the 
 > front-to-back readers of the tutorial with a good 80% overview of the 
 > language, but also let readers find the tangents that are of interest to 
 > them.

I don't know if I agree with this specific outline, but I'm definitely
in agreement with the principle that we should be guided by improving
discoverability.
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/4UXUNCC7YE645XG4VEJHPM25IRZXRMFA/
Code of Conduct: http://python.org/psf/codeofconduct/