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

[Steven D'Aprano]

On Fri, Feb 26, 2021 at 11:41:56AM +0900, Stephen J. Turnbull wrote:
> 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.

Is it *only* Python though? Wouldn't that be necessary if they were 
learning Perl, Java, C, Ruby 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/OUU2BI6WYFFLJDAS3OCHJSFOATLNVADS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Irit Katriel via Python-Dev]

FTR: nobody on this long thread so far has suggested that there are no
valid use cases for `except Exception`.

Thank you for turning to what happens with 'except ValueError' when an
ExceptionGroup[ValueError] is raised, this is important.

I'm not sure it's safe to assume that it is necessarily a programming
error, and that the interpreter can essentially break the program in this
case.
Is this not allowed?

try:
try:
obj.func()# function that raises ExceptionGroups
except AttributeError:
logger.info("obj doesn't have a func")
except *(AttributeError, SyntaxError):
logger.info("func had some problems")



On Fri, Feb 26, 2021 at 5:40 AM Nathaniel Smith  wrote:

> On Thu, Feb 25, 2021 at 2:13 PM Guido van Rossum  wrote:
> >
> > So is "fail-fast if you forget to handle an ExceptionGroup" really a
> feature? (Do we call this out in the PEP?)
> >
> > We may believe that "except Exception" is an abuse, but it is too common
> to dismiss out of hand. I think if some app has e.g. a main loop where they
> repeatedly do something that may fail in many ways (e.g. handle a web
> request), catch all errors and then just log the error and continue from
> the top, it's a better experience if it logs "ExceptionGroup: 
> []" than if it crashes.
>
> Yeah, 'except Exception' happens a lot in the wild, and what to do
> about that has been a major sticking point in the ExceptionGroup
> debates all along. I wouldn't say that 'except Exception' is an abuse
> even -- what do you want gunicorn to do if your buggy flask app raises
> some random exception? Crash your entire web server, or log it and
> attempt to keep going? (This is almost your example, but adding in the
> part where gunicorn is reliable and well-respected, and that its whole
> job is to invoke arbitrarily flaky code written by random users.)
> Yury/I/others did discuss the idea of a
> BaseExceptionGroup/ExceptionGroup split a lot, and I think the general
> feeling is that it could potentially work, but feels like a
> complicated and awkward hack, so no-one was super excited about it.
> For a while we also had a compromise design where only
> BaseExceptionGroup was built-in, but we left it non-final specifically
> so asyncio could define an ExceptionsOnlyExceptionGroup.
>
> Another somewhat-related awkward part of the API is how ExceptionGroup
> and plain-old 'except' should interact *in general*. The intuition is
> that if you have 'except ValueError' and you get an
> 'ExceptionGroup(ValueError)', then the user's code has some kind of
> problem and we should probably do something? to let them know? One
> idea I had was that we should raise a RuntimeError if this happens,
> sort of similar to PEP 479. But I could never quite figure out how
> this would help (gunicorn crashing with a RuntimeError isn't obviously
> better than gunicorn crashing with an ExceptionGroup).
>
> == NEW IDEA THAT MAYBE SOLVES BOTH PROBLEMS ==
>
> Proposal:
>
> - any time an unwinding ExceptionGroup encounters a traditional
> try/except, then it gets replaced with a RuntimeError whose __cause__
> is set to the original ExceptionGroup and whose first traceback entry
> points to the offending try/except block
>
> - CUTE BIT I ONLY JUST THOUGHT OF: this substitution happens right
> *before* we start evaluating 'except' clauses for this try/except
>
> So for example:
>
> If an ExceptionGroup hits an 'except Exception': The ExceptionGroup is
> replaced by a RuntimeError. RuntimeError is an Exception, so the
> 'except Exception' clause catches it. And presumably logs it or
> something. This way your log contains both a notification that you
> might want to switch to except* (from the RuntimeError), *along with*
> the full original exception details (from the __cause__ attribute). If
> it was an ExceptionGroup(KeyboardInterrupt), then it still gets caught
> and that's not so great, but at least you get the RuntimeError to
> point out that something has gone wrong and tell you where?
>
> If an ExceptionGroup(ValueError) hits an 'except ValueError': it
> doesn't get caught, *but* a RuntimeError keeps propagating out to tell
> you you have a problem. And when that RuntimeError eventually hits the
> top of your program or ends up in your webserver logs or whatever,
> then the RuntimeError's traceback will point you to the 'except
> ValueError' that needs to be fixed.
>
> If you write 'except ExceptionGroup': this clause is a no-op that will
> never execute, because it's impossible to still have an ExceptionGroup
> when we start matching 'except' clauses. (We could additionally emit a
> diagnostic if we want.)
>
> If you write bare 'except:', or 'except BaseException': the clause
> always executes (as before), but they get the RuntimeError instead of
> the ExceptionGroup. If you really *wanted* the ExceptionGroup, you can
> retrieve it from the __cause__ attribute. (The only case I can think
> of where this would be useful is if you're writing code that has to
> strad

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

[Oscar Benjamin]

On Fri, 26 Feb 2021 at 09:07, Steven D'Aprano  wrote:
>
> On Fri, Feb 26, 2021 at 11:41:56AM +0900, Stephen J. Turnbull wrote:
> > 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.
>
> Is it *only* Python though? Wouldn't that be necessary if they were
> learning Perl, Java, C, Ruby etc?

It is possible to teach students to do most things in Python without
using the command line. For example you can tell them all to install
anaconda and then use spyder as their editor. Or you can get them to
install and use vscode or pycharm or some other IDE with built in
virtualenv and git integration etc.

Where Python is awkward is at the point where you actually *want* to
teach students to use the command line. The problem is that Python is
not set up for command line use out of the box in a consistent way
across different platforms.

It would be nice to say: now open a terminal, type "python", and hit
the enter key and you'll see the Python prompt >>> but it's just not
that simple so the instructions end up being like:
"""
It might be possible to run python from the terminal by typing
"python". However that might not work or it might run the wrong
version/installation of Python. It might be that you haven't added
Python to your PATH environment variable or maybe you have depending
on which boxes you ticked when installing. Possibly you need to change
your PATH environment variable or possibly you should run Python as
"python3" or "py" instead but I have no way of saying without knowing
what OS you are on, where you installed Python from, what options you
selected in the installer, whether you have any other Python
installations etc. If you are on Windows and you get "permission
denied" then that's possibly because the MS-provided python.exe stub
is on your PATH so you first need to disable that in "app execution
aliases". Possibly you can't run Python from the normal terminal but
you can open a special terminal for Python that does have the PATH set
up such as the Anaconda Prompt.

Okay next lesson is how to use "pip" which is really easy: just type
"pip install X" but maybe you should actually type "pip3" or "python
-m pip" or "python3 -m pip" or "py -m pip" or actually you if you
installed Anaconda you might need to use "conda install X".
"""
When someone learns to use the command line for the first time it's
really quite helpful if you can tell them exactly what commands to
type. Knowing how to configure PATH and understanding what it does and
understanding about OS differences etc is potentially useful in the
long run but is a major distraction at the beginning.

There have been efforts to improve the situation but in some ways they
make it worse. For example the py launcher supposedly fixes some of
these problems on Windows but the fact that there is no analogue of it
on any non-Windows platform means that any instructions involving it
immediately need to split according to OS. Likewise the new python.exe
stub that ships with Windows is supposed to fix the Python PATH
problem but it actually *prevents* python from working in the terminal
if you have installed Python some other way (even if you have added it
to PATH):
https://stackoverflow.com/questions/56974927/permission-denied-trying-to-run-python-on-windows-10

The problems aren't only on Windows because you also have "python" vs
"python3" on OSX, Linux etc. On OSX you can also have conflicts
between the system Python and any user installed Python. On OSX some
installers set up the PATH for you by automagically editing
.bash_profile which can be helpful but can also be confusing. After
some time people don't actually know how to run the different versions
of Python that they installed through homebrew, from python.org or
from Anaconda etc and their .bash_profile is a mess. The question of
exactly what you should type to run python, pip, etc applies on Linux
although I find it less problematic just because Linux users typically
know how to use the terminal already.

For me as a user of Python I don't usually notice these problems
because I use some sort of virtual environment for everything so I can
always type "python" or "pip" and there are no conflicts between
different installations. When a student can't even get "python" to
work in the terminal though it's too much to ask them to start setting
up virtual environments.

--
Oscar
___
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-Dev] Re: Have virtual environments led to neglect of the actual environment?

[Paul Moore]

On Fri, 26 Feb 2021 at 13:31, Oscar Benjamin  wrote:
> Where Python is awkward is at the point where you actually *want* to
> teach students to use the command line. The problem is that Python is
> not set up for command line use out of the box in a consistent way
> across different platforms.

My experience with Java is that it's at least as bad. (I'd say
"worse", but that might just be because I'm more familiar with Python
than with Java). For C, do I type cc, cl, gcc, clang, ...? Do I need
to start a "Visual Studio command prompt"? What if I prefer using
powershell? For Ruby and Perl, I have to install them, and assuming
that's easy, I've no idea what to do then.

I'm not sure what the point is here though. If people without command
line skills want to use the command line, they'll struggle? Well, yes,
that seems likely.

And I have no idea how this relates to virtual environments vs the
system Python.
Paul

So yes, Python's experience sucks, but so do most languages.
___
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/OL73XHKBP7Q3P2EZRHXMVXM4N6YAIDLE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Nathaniel Smith]

On Fri, Feb 26, 2021 at 5:05 AM Irit Katriel  wrote:
> I'm not sure it's safe to assume that it is necessarily a programming error, 
> and that the interpreter can essentially break the program in this case.
> Is this not allowed?
>
> try:
> try:
> obj.func()# function that raises ExceptionGroups
> except AttributeError:
> logger.info("obj doesn't have a func")
> except *(AttributeError, SyntaxError):
> logger.info("func had some problems")

I'd be fine with disallowing that. The intuition is that things will
be simplest if ExceptionGroup is kept as transparent and meaningless
as possible, i.e. ExceptionGroup(ValueError) and ValueError mean
exactly the same thing -- "some code inside this block raised
ValueError" -- and ideally should be processed in exactly the same
way. (Of course we can't quite achieve that due to backcompat issues,
but the closer we can get, the better, I think?)

If you need to distinguish between the AttributeError from
'obj.__getattr__("func")' vs the AttributeError from the call to
func(), then there's already an obvious way to do that, that works for
all functions, not just ones that happen to raise ExceptionGroups:

try:
f = obj.func
except AttributeError:
...
try:
f()
except ...:# or except *...:
...

-n

-- 
Nathaniel J. Smith -- https://vorpus.org
___
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/VSIGKUNU2GNLMKKH4GLMRSICTQYVLVCZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Emily Bowman]

A side benefit is that if an Exception somehow propagates up where only
ExceptionGroup is defined, except *() could just work anyway, though it
might take a little magic to make sure they act the same. Like Guido said,
I don't think it can be retrofitted into existing *-less APIs, and it'll
either need a new API and deprecation, or dumping the old for the new
hotness if that's the maintenance strategy, but as long as docs call out
that this is now returning collective exceptions, I don't see a problem.

I don't think it's been mentioned, but it's a nice synergy with pattern
matching, even if it's wholly unrelated, and having both in one release
will actually make sense.

-Em


On Fri, Feb 26, 2021 at 6:45 AM Nathaniel Smith  wrote:

> On Fri, Feb 26, 2021 at 5:05 AM Irit Katriel 
> wrote:
> > I'm not sure it's safe to assume that it is necessarily a programming
> error, and that the interpreter can essentially break the program in this
> case.
> > Is this not allowed?
> >
> > try:
> > try:
> > obj.func()# function that raises ExceptionGroups
> > except AttributeError:
> > logger.info("obj doesn't have a func")
> > except *(AttributeError, SyntaxError):
> > logger.info("func had some problems")
>
> I'd be fine with disallowing that. The intuition is that things will
> be simplest if ExceptionGroup is kept as transparent and meaningless
> as possible, i.e. ExceptionGroup(ValueError) and ValueError mean
> exactly the same thing -- "some code inside this block raised
> ValueError" -- and ideally should be processed in exactly the same
> way. (Of course we can't quite achieve that due to backcompat issues,
> but the closer we can get, the better, I think?)
>
> If you need to distinguish between the AttributeError from
> 'obj.__getattr__("func")' vs the AttributeError from the call to
> func(), then there's already an obvious way to do that, that works for
> all functions, not just ones that happen to raise ExceptionGroups:
>
> try:
> f = obj.func
> except AttributeError:
> ...
> try:
> f()
> except ...:# or except *...:
> ...
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
>
___
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/W3GMOA7RVADLBL7L3VB2R3SZULS7QZ7W/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Irit Katriel via Python-Dev]

On Fri, Feb 26, 2021 at 2:42 PM Nathaniel Smith  wrote:

> On Fri, Feb 26, 2021 at 5:05 AM Irit Katriel 
> wrote:
> > I'm not sure it's safe to assume that it is necessarily a programming
> error, and that the interpreter can essentially break the program in this
> case.
> > Is this not allowed?
> >
> > try:
> > try:
> > obj.func()# function that raises ExceptionGroups
> > except AttributeError:
> > logger.info("obj doesn't have a func")
> > except *(AttributeError, SyntaxError):
> > logger.info("func had some problems")
>
> I'd be fine with disallowing that. The intuition is that things will
> be simplest if ExceptionGroup is kept as transparent and meaningless
> as possible, i.e. ExceptionGroup(ValueError) and ValueError mean
> exactly the same thing -- "some code inside this block raised
> ValueError" -- and ideally should be processed in exactly the same
> way.


But they don't mean the same thing if this prints hello:

try:
raise ValueError()
except ValueError:
   print('hello')

and this raises a RuntimeError:

try:
raise ExceptionGroup("", [ValueError()])
except ValueError:
   print('hello')

What am I missing?
___
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/ZQYMOWWCFBP3TBBNZGD5X45CWJNC4HFF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 637 - Support for indexing with keyword arguments: request for feedback for SC submission

[Stefano Borini]

If interested, you can try it out from my github branch:

https://github.com/stefanoborini/cpython/tree/PEP-637-implementation-attempt-2

I am going to sync it against python master in a few minutes (it's
been a while, there probably will be conflicts).

Please break it.

On Thu, 25 Feb 2021 at 16:41, Thor Whalen  wrote:
>
> Finally! One of my top python wishes!
>
> Where can I vote?
>
> How can I get my hands on a back port?
>
> How can I help getting this sooner?
> ___
> 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/2QPAZ26E77MV2AZLDF3Z6DNHWZHQUPH5/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Kind regards,

Stefano Borini
___
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/EEMTQCKZ7E62EYNV5S7CTLCJXBHFPBCM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2021-02-19 - 2021-02-26)
Python tracker at https://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open7430 ( +2)
  closed 47636 (+58)
  total  55066 (+60)

Open issues with patches: 2946 


Issues opened (40)
==

#23882: unittest discovery doesn't detect namespace packages when give
https://bugs.python.org/issue23882  reopened by terry.reedy

#26600: Thread safety issue with MagickMock __str__: sometimes returns
https://bugs.python.org/issue26600  reopened by iritkatriel

#43271: AMD64 Windows10 3.x crash with Windows fatal exception: stack 
https://bugs.python.org/issue43271  opened by vstinner

#43273: Mock `_mock_wraps` is undocumented and inconsistently named
https://bugs.python.org/issue43273  opened by Woodz

#43279: Update code taken from Keccak Code Package
https://bugs.python.org/issue43279  opened by illia-v

#43281: Walrus comprehension rebind checking behavior
https://bugs.python.org/issue43281  opened by gousaiyang

#43282: Add split install targets to install tests separately from lib
https://bugs.python.org/issue43282  opened by eschwartz

#43284: Wrong windows build in 20H2
https://bugs.python.org/issue43284  opened by bugale bugale

#43285: ftplib use host from PASV response
https://bugs.python.org/issue43285  opened by ricexdream

#43286: Clarify that Popen.returncode does not get auto-set when the p
https://bugs.python.org/issue43286  opened by Antony.Lee

#43287: Use PEP 590 vectorcall to speed up calls to filter()
https://bugs.python.org/issue43287  opened by corona10

#43288: test_importlib failure due to missing skip() method
https://bugs.python.org/issue43288  opened by nascheme

#43289: step bug in turtle's for loop
https://bugs.python.org/issue43289  opened by Yehuda

#43292: xml.ElementTree iterparse filehandle left open
https://bugs.python.org/issue43292  opened by vkisforever

#43295: datetime.strptime emits IndexError on parsing 'z' as %z
https://bugs.python.org/issue43295  opened by itchyny

#43296: [sqlite3] Fix sqlite3_value_blob() usage
https://bugs.python.org/issue43296  opened by erlendaasland

#43298: Windows build cannot detect missing Windows SDK
https://bugs.python.org/issue43298  opened by mytechnotalent

#43299: pyclbr.readmodule_ex traversing "import __main__": dies with V
https://bugs.python.org/issue43299  opened by kxrob

#43300: "bisect" module should support reverse-sorted sequences
https://bugs.python.org/issue43300  opened by mCoding

#43305: A typo in /Modules/_io/bufferedio.c
https://bugs.python.org/issue43305  opened by malin

#43306: Error in multiprocessing.Pool's initializer doesn't stop execu
https://bugs.python.org/issue43306  opened by nemeskeyd

#43307: Sync site.py and sysconfig.py with PyPy
https://bugs.python.org/issue43307  opened by mattip

#43308: subprocess.Popen leaks file descriptors opened for DEVNULL or 
https://bugs.python.org/issue43308  opened by cptpcrd

#43311: bpo-43311: PyInterpreterState_New use thread-specific data tst
https://bugs.python.org/issue43311  opened by JunyiXie

#43312: Interface to select preferred "user" or "home" sysconfig schem
https://bugs.python.org/issue43312  opened by uranusjr

#43313: feature: support pymalloc for subinterpreters. each subinterpr
https://bugs.python.org/issue43313  opened by JunyiXie

#43315: Decimal.__str__ has no way to force exact decimal representati
https://bugs.python.org/issue43315  opened by sim1234

#43318: pdb can't output the prompt message when successfully clear br
https://bugs.python.org/issue43318  opened by hjzin

#43319: A possible misleading expression in the Virtual Environment Tu
https://bugs.python.org/issue43319  opened by cmhzc

#43320: test test_webbrowser "can't locate runnable browser" with enab
https://bugs.python.org/issue43320  opened by swamper123

#43321: PyArg_ParseTuple() false-returns SUCCESS though SystemError an
https://bugs.python.org/issue43321  opened by kxrob

#43322: Inconsistent '#include' notation in extensions tutorial doc
https://bugs.python.org/issue43322  opened by mhughes

#43323: UnicodeEncodeError: surrogates not allowed when parsing invali
https://bugs.python.org/issue43323  opened by andersk

#43324: asyncio
https://bugs.python.org/issue43324  opened by AliyevH

#43325: Documentation should warn that 'is' is not a safe comparison o
https://bugs.python.org/issue43325  opened by anthony-flury

#43326: About Zipfile
https://bugs.python.org/issue43326  opened by Fcscanf

#43327: The docs falsely state that PyImport_ImportFrozenModuleObject(
https://bugs.python.org/issue43327  opened by ZackerySpytz

#43328: make test errors
https://bugs.python.org/issue43328  opened by asholomitskiy84

#43329: Multiprocessing Manager Client Not Reconnecting
https://bugs.python.org/issue43329  opened by boom0192

#43330: xmlrpc.Server URI query and fragment are discarded from HTTP q
https://bugs.python.org/issue43330

[Python-Dev] Which thing is "Development Mode"

[Coyot Linden]

As of 3.7, there is now a python feature called Development Mode:

https://docs.python.org/3/library/devmode.html#devmode

Which has a confusingly similar and nearly identical name to a setuptools 
feature:

https://packaging.python.org/guides/distributing-packages-using-setuptools/#working-in-development-mode

It seems like a bit of bikeshedding could create a name for one of them that 
disambiguates them.

Best,

coyot
___
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/42NQQHQEQ4FTRP5CKI5XSKD3GA6L5IIT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Moving threadstate to thread-local storage.

[Victor Stinner]

Sure. The plan is to use __thread when possible ;-)

Victor

On Thu, Feb 25, 2021 at 4:58 AM 谢俊逸 via Python-Dev
 wrote:
>
> On MacOS & iOS, __thread variable is 35% faster than using 
> pthread_getspecific.
>
> getSpecific cost: 0.000649
> getTLS cost: 0.000423
>
>
> - (void)test { double t1 = CFAbsoluteTimeGetCurrent(); for (int i = 0; i < 
> 10; i++) { [self getSpecific]; } double t2 = CFAbsoluteTimeGetCurrent(); 
> printf("getSpecific cost: %f\n", t2 - t1); double t3 = 
> CFAbsoluteTimeGetCurrent(); for (int i = 0; i < 10; i++) { [self getTLS]; 
> } double t4 = CFAbsoluteTimeGetCurrent(); printf("getTLS cost: %f\n", t4 - 
> t3); } - (int)getSpecific { int * value = pthread_getspecific(tlsKey); return 
> *value; } - (int)getTLS { return *tlv_v5; }
> ___
> 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/KTHAKNENSBKURE7I2SRVXEPJ6NDNCACI/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/23MHKR44CZTGW7K3NCZADBRWDRA2BHIN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Which thing is "Development Mode"

[Cameron Simpson]

On 26Feb2021 18:34, Coyot Linden  wrote:
>As of 3.7, there is now a python feature called Development Mode:
>
>https://docs.python.org/3/library/devmode.html#devmode
>
>Which has a confusingly similar and nearly identical name to a setuptools 
>feature:
>
>https://packaging.python.org/guides/distributing-packages-using-setuptools/#working-in-development-mode
>
>It seems like a bit of bikeshedding could create a name for one of them 
>that disambiguates them.

I disagree.

They're both aids to development, with effects suitable to their domains 
(the interpreter itself for the former and the method of obtaining 
packages in the latter). I think the names are very apt, and similar 
because of their purpose.

Picking gratuitously different names just to have "different names" 
seems pointless and confusing to me.

This isn't some shared namespace where names need to be different to 
avoid conflicts such as package names or DNS domain names, but similar 
scenarios ("I'm doing development") applied to different aspects of a 
Python environment. Of course it is natural to use a phrase like 
"development mode" for each.

Cheers,
Cameron Simpson 
___
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/F4P6M2GUJN2QU2KZWNDXOINFY2BJHAAL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Which thing is "Development Mode"

[Victor Stinner]

I suggest to assign a color to each development mode to distinguish them.

Victor

On Fri, Feb 26, 2021 at 7:50 PM Coyot Linden  wrote:
>
> As of 3.7, there is now a python feature called Development Mode:
>
> https://docs.python.org/3/library/devmode.html#devmode
>
> Which has a confusingly similar and nearly identical name to a setuptools 
> feature:
>
> https://packaging.python.org/guides/distributing-packages-using-setuptools/#working-in-development-mode
>
> It seems like a bit of bikeshedding could create a name for one of them that 
> disambiguates them.
>
> Best,
>
> coyot
> ___
> 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/42NQQHQEQ4FTRP5CKI5XSKD3GA6L5IIT/
> Code of Conduct: http://python.org/psf/codeofconduct/



-- 
Night gathers, and now my watch begins. It shall not end until my death.
___
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/3VNZCIENVRB3OXMP3GDVSUNNJADYWBY2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Which thing is "Development Mode"

[Paul Bryan]

Perhaps refine the packaging nomenclature to be "local development
mode"?

On Fri, 2021-02-26 at 18:34 +, Coyot Linden wrote:
> As of 3.7, there is now a python feature called Development Mode:
> 
> https://docs.python.org/3/library/devmode.html#devmode
> 
> Which has a confusingly similar and nearly identical name to a
> setuptools feature:
> 
> https://packaging.python.org/guides/distributing-packages-using-setuptools/#working-in-development-mode
> 
> It seems like a bit of bikeshedding could create a name for one of
> them that disambiguates them.
> 
> Best,
> 
> coyot
> ___
> 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/42NQQHQEQ4FTRP5CKI5XSKD3GA6L5IIT/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
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/43SQIBITRKH7Q5RQEV6EGA4JDV7XQKLP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Which thing is "Development Mode"

[Steven D'Aprano]

Hi Coyot, and welcome!

Can you explain the circumstances where a developer, or an end user, 
might be confused as to which development mode is meant?

"Dev mode" is a very common term: Windows 10 has a development mode. So 
does the X-Box and the Samsung Galaxy phone. Ruby on Rails also has a 
development mode. So does the Opera web browser. I'm sure that with a 
bit of googling, we could come up with a dozen more examples.

Normally, the context is all we need to disambiguate the different dev 
modes, and if not, we can disambiguate the two by using fully qualified 
names: "Galaxy dev mode" and "X-Box dev mode".

Under what circumstances is that not sufficient for Python dev mode and 
setuptools dev mode?



-- 
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/64S35GSWCOOPFTVO4X5IGFYQ7ZGNXB2U/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Jim J. Jewett]

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.  

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.
___
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/XWBEK2Q3DBY3M7HV7BN2GJPJCMPXJPQB/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Marco Sulla]

Excuse me if I post here. Maybe is a stupid question: why, instead of
introducing except*, Python can't extend the functionality of except,
so it can do what except* would do?
___
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/34E3TMVLHRT2UQSH5RWZXOPT6AQ6DTYZ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Guido van Rossum]

On Thu, Feb 25, 2021 at 9:40 PM Nathaniel Smith  wrote:

> [...]
> Yury/I/others did discuss the idea of a
> BaseExceptionGroup/ExceptionGroup split a lot, and I think the general
> feeling is that it could potentially work, but feels like a
> complicated and awkward hack, so no-one was super excited about it.
>

Oh, I didn't realize (or recall) the idea was considered before. Given the
pseudo code I showed I don't think it's particularly complicated or
awkward, although it's of course more complicated than the design that's
currently in our PEP.


> For a while we also had a compromise design where only
> BaseExceptionGroup was built-in, but we left it non-final specifically
> so asyncio could define an ExceptionsOnlyExceptionGroup.
>

I did notice that. Given how many distinct use cases we've discovered by
now I think this is a dead end.


> Another somewhat-related awkward part of the API is how ExceptionGroup
> and plain-old 'except' should interact *in general*. The intuition is
> that if you have 'except ValueError' and you get an
> 'ExceptionGroup(ValueError)', then the user's code has some kind of
> problem and we should probably do something? to let them know? One
> idea I had was that we should raise a RuntimeError if this happens,
> sort of similar to PEP 479. But I could never quite figure out how
> this would help (gunicorn crashing with a RuntimeError isn't obviously
> better than gunicorn crashing with an ExceptionGroup).
>

I'm not sure I agree with the intuition that such user code definitely has
a problem. Irit tried to give an example using AttributeError, and while
that particular example is easily countered, I think it's not as
straightforward as you state. For example there could be a framework
exception that we know statically will not be wrapped in ExceptionGroup.
Basically, if we have some code that can either raise some exceptions of
category A wrapped in ExceptionGroup, or a bare exception of category B
(without overlap between the categories), writing code that catches
category B using `except B:` should not affect the propagation of
ExceptionGroup.

Or what about code that uses this idiom?
```
try:
. . .
except Exception:
. . .
raise
```
There should be no need to switch this to `except *` just to prevent the
ExceptionGroup from becoming a RuntimeError.


> == NEW IDEA THAT MAYBE SOLVES BOTH PROBLEMS ==
>
> Proposal:
>
> - any time an unwinding ExceptionGroup encounters a traditional
> try/except, then it gets replaced with a RuntimeError whose __cause__
> is set to the original ExceptionGroup and whose first traceback entry
> points to the offending try/except block
>
> - CUTE BIT I ONLY JUST THOUGHT OF: this substitution happens right
> *before* we start evaluating 'except' clauses for this try/except
>
> So for example:
>
> If an ExceptionGroup hits an 'except Exception': The ExceptionGroup is
> replaced by a RuntimeError. RuntimeError is an Exception, so the
> 'except Exception' clause catches it. And presumably logs it or
> something. This way your log contains both a notification that you
> might want to switch to except* (from the RuntimeError), *along with*
> the full original exception details (from the __cause__ attribute). If
> it was an ExceptionGroup(KeyboardInterrupt), then it still gets caught
> and that's not so great, but at least you get the RuntimeError to
> point out that something has gone wrong and tell you where?
>
> If an ExceptionGroup(ValueError) hits an 'except ValueError': it
> doesn't get caught, *but* a RuntimeError keeps propagating out to tell
> you you have a problem. And when that RuntimeError eventually hits the
> top of your program or ends up in your webserver logs or whatever,
> then the RuntimeError's traceback will point you to the 'except
> ValueError' that needs to be fixed.
>
> If you write 'except ExceptionGroup': this clause is a no-op that will
> never execute, because it's impossible to still have an ExceptionGroup
> when we start matching 'except' clauses. (We could additionally emit a
> diagnostic if we want.)
>
> If you write bare 'except:', or 'except BaseException': the clause
> always executes (as before), but they get the RuntimeError instead of
> the ExceptionGroup. If you really *wanted* the ExceptionGroup, you can
> retrieve it from the __cause__ attribute. (The only case I can think
> of where this would be useful is if you're writing code that has to
> straddle both old and new Python versions *and* wants to do something
> clever with ExceptionGroups. I think this would happen if you're
> implementing Trio, or implementing a higher-level backport library for
> catching ExceptionGroups, something like that. So this only applies to
> like half a dozen users total, but they are important users :-).)
>

This is all very clever, but something feels off with it. Perhaps it
improves this:
```
try:
raise ExceptionGroup(ValueError)  # Hidden in more complex code
except ValueError:
. . .
```
(Though how? T

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Jim J. Jewett]

> We keep the ability to wrap any exception, while we lose the "fail-fast if
> you forget to handle an ExceptionGroup" feature, which was intended as a
> kindness towards those who abuse "except Exception".

How is this a kindness?

Whenever I've used except Exception or stronger, it was a sanitary barrier 
around code that might well do unpredictable or even stupid things.  Adding a 
new kind of exception that I hadn't predicted -- including ExceptionGroup -- 
would certainly fit this description, and I want my driver loop to do what I 
told it.  (Probably log an unexpected exception, and continue with the next 
record.  I honestly don't even want a page, let alone a crash, because data 
from outside that barrier ... is often bad, and almost never in ways the 
on-call person can safely fix.  And if they don't have time to find it in the 
logs, then it isn't a priority that week.)

> If we adopt this solution then letting an ExceptionGroup escape from code
> that is not supposed to raise it, is not a fatal error, it's just some
> exception like any other.

Good!  If we're not coordinating so closely that I already know to handle the 
ExceptionGroup in advance, then that is exactly what should happen (and except 
Exception with a log and log analysis is the right way to deal with it).

> So there is no longer a distinction between code that raises
> ExceptionGroups and code that doesn't. Any code can propagate them, like
> any code can raise any other exception.

Good;  special cases and all.

> Does this mean that more code needs to be aware of the possibility of them
> showing up?  Is that a problem? 

Honestly, no.  You seem to be assuming a very well-controlled environment where 
any potential problems would be caught long before production.  My experience 
is that such optimism is never warranted, *particularly* at places that claim 
to have a heavy process to ensure such early (or in-time) bug-catches.

> What would we have done here if we were building Python from scratch?

Raise anything you want.  Or maybe only strings and exceptions.  Or maybe only 
stuff inheriting from a marker class named BaseException ... but we probably 
wouldn't add a parallel base marker that catch-all code *also* needs to be 
aware of.  (And since we would be starting from scratch, the catch-all wrapper 
code would certainly not have to be deployed on a conservatively managed 
server, before lightweight exploratory less-centralized client code could start 
using it.) 

-jJ
___
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/TEBYSGMMT3SJRVTPCZQFMHJQPBOV6Q74/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Guido van Rossum]

On Fri, Feb 26, 2021 at 3:18 PM Marco Sulla 
wrote:

> Excuse me if I post here. Maybe is a stupid question: why, instead of
> introducing except*, Python can't extend the functionality of except,
> so it can do what except* would do?
>

Good question. Here's an example:
```
try:
. . .
except OSError as err:
if err.errno != ENOENT:
raise
. . .
```
If this would catch ExceptionGroup(OSError), the `err` variable would be an
ExceptionGroup instance, which does not have an `errno` attribute.

(Irit: Does the PEP answer this question? I couldn't quickly find it in the
rejected ideas. I think it's a reasonable question and we should answer it,
either in the Rationale or in Rejected Ideas.)

-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/3VQEWV26SD6NH3ALOLORMZ2G3DTFOJZ4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Jim J. Jewett]

FWIW, the only situation I can think of where you would care that the enclosed 
exception instances are BaseException but not regular Exception is interactive 
debugging, and even then there are enough other ways to kill the whole process 
that I think most people would use one of them instead of wanting a different 
BaseExceptionGroup that breaks the server instead of just the servlet.

I suppose you could argue that the distinction encourages the "good practice" 
of defensively wrapping "except Exception" in an "except BaseException" that is 
itself wrapped in a bare except.  I suspect it would actually just push people 
to replace that "except Exception" with the bare except and give up on the 
logging, because that is a quicker adjustment.
___
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/IDVNUNBAMFKZVT64TFV5QYLB3BJTABBD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Jim J. Jewett]

You still need except* for the (unusual?) case where the ExceptionGroup 
contains multiple individual Exceptions, and you want them all to be processed. 
 (This possibility is the justification for the PEP, but the difficulty of 
associating an exception with the specific task that raised it suggests that 
exceptions are still intended to be rare, rather than a back-channel 
communications band.)

As written, you also need except* to unwrap, so that ExceptionGroup(ValueError) 
can be handled by "except ValueError" instead of "except RuntimeError" (or 
except ExceptionGroup) followed by cause-unwrapping.

-jJ
___
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/B6JKV2JIFA76CMDOK2IBVBA2MIQKYDVR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Greg Ewing]

While I don't particularly mind if we get ExceptionGroup, giving
it special magical semantics, and especially new syntax, seems like
bringing a massively overpowered weapon to bear on something that
will only be used rarely.

Handling multiple exceptions from an ExceptionGroup could be done
using a loop with pattern matching, so is except* really justified?

--
Greg
___
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/BRQDP4KNRYU6UCKQBHRAUAHWWCENNIVM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Jim J. Jewett]

> Thank you for turning to what happens with 'except ValueError' when an
> ExceptionGroup[ValueError] is raised, this is important.

> I'm not sure it's safe to assume that it is necessarily a > programming
>error, and that the interpreter can essentially break the program in this
> case.

I'm betting it means a ValueError was raised, but then something (probably an 
asynchronous framework) aggregated it.  I won't swear you would never want to 
distinguish the two cases, or to distinguish them both from 
ExceptionGroup[ExceptionGroup[ExceptionGroup[ValueError]]], but ... normally 
you wouldn't.

> Is this not allowed?

>try:
>try:
>obj.func()# function that raises ExceptionGroups
>except AttributeError:
>logger.info("obj doesn't have a func")
>except *(AttributeError, SyntaxError):
>logger.info("func had some problems")

Allowed, but probably in error ... no AttributeError will get through to the 
except * unless it happened inside the except AttributeError handler.  Did you 
mean:

try:
try:
obj.func# function that raises ExceptionGroups
except AttributeError:
logger.info("obj doesn't have a func")
obj.func()
except *(AttributeError, SyntaxError):
logger.info("func had some problems")

I see this as an argument that the except/except* split is tricky, but I don't 
think it says anything about whether except* clauses should be able to see into 
nested ExceptionGroups ... nor am I at all confident that I understood your 
intent. 

-jJ
___
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/XOAB7IJNXOHRL3HRVZ5VZON6MVHOPXB3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Irit Katriel via Python-Dev]

On Sat, Feb 27, 2021 at 12:47 AM Jim J. Jewett  wrote:

>
> > Is this not allowed?
>
> >try:
> >try:
> >obj.func()# function that raises ExceptionGroups
> >except AttributeError:
> >logger.info("obj doesn't have a func")
> >except *(AttributeError, SyntaxError):
> >logger.info("func had some problems")
>
> Allowed, but probably in error ... no AttributeError will get through to
> the except * unless it happened inside the except AttributeError handler.
> Did you mean:
>


If obj.func() raises an ExceptionGroup that contains AttributeError then
"except AttributeError" doesn't catch it. So it will get through.



>
> try:
> try:
> obj.func# function that raises ExceptionGroups
> except AttributeError:
> logger.info("obj doesn't have a func")
> obj.func()
> except *(AttributeError, SyntaxError):
> logger.info("func had some problems")
>
> I see this as an argument that the except/except* split is tricky, but I
> don't think it says anything about whether except* clauses should be able
> to see into nested ExceptionGroups ... nor am I at all confident that I
> understood your intent.
>
> -jJ
> ___
> 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/XOAB7IJNXOHRL3HRVZ5VZON6MVHOPXB3/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
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/SVADA4PBND7ADSGTMC37XCQVNSOQ57LM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Irit Katriel via Python-Dev]

On Fri, Feb 26, 2021 at 11:43 PM Guido van Rossum  wrote:

> On Fri, Feb 26, 2021 at 3:18 PM Marco Sulla 
> wrote:
>
>> Excuse me if I post here. Maybe is a stupid question: why, instead of
>> introducing except*, Python can't extend the functionality of except,
>> so it can do what except* would do?
>>
>
> Good question. Here's an example:
> ```
> try:
> . . .
> except OSError as err:
> if err.errno != ENOENT:
> raise
> . . .
> ```
> If this would catch ExceptionGroup(OSError), the `err` variable would be
> an ExceptionGroup instance, which does not have an `errno` attribute.
>
> (Irit: Does the PEP answer this question? I couldn't quickly find it in
> the rejected ideas. I think it's a reasonable question and we should answer
> it, either in the Rationale or in Rejected Ideas.)
>

Added here:  https://github.com/python/peps/pull/1846



>
___
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/K7VCM7OZDIGZDTIZGJZJGWJOBXB65IU4/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Oscar Benjamin]

On Fri, 26 Feb 2021 at 23:06, Jim J. Jewett  wrote:
>
> 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.

Thanks Jim, that is the situation and yes they are not CS students.

The other point though is that it doesn't need to be like this. If the
issue was just installing Python and then setting up your PATH then
that's manageable. The problem is that even after doing those things
there isn't a "one way" to invoke Python from the command line. All
possible invocations (python, python3, py, ...) will fail for some
users. That's a problem for beginners but it's also a problem in any
situation where you want to write a command line that should run on
multiple platforms (e.g. in a Makefile or some other kind of script).

I see that the official Python tutorial now suggests typing
"python3.9" [1]. Is that what is recommended now? Obviously that would
fail for someone who had installed 3.8.

It would be great if Python could converge around a single way for
users to invoke the Python that they have installed and would want to
use. Python 2.x is beginning to fade away so python vs python3 makes
less sense now but maybe standardising on py for all platforms and
installs would be better (since py also has features for selecting
different versions and is not currently used for any "system python").

[1]: 
https://docs.python.org/3/tutorial/interpreter.html#invoking-the-interpreter


Oscar
___
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/HLMHW7U2UFVQ26NNUXDJGNII6EFDR7AX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Irit Katriel via Python-Dev]

On Sat, Feb 27, 2021 at 12:35 AM Greg Ewing 
wrote:

> While I don't particularly mind if we get ExceptionGroup, giving
> it special magical semantics, and especially new syntax, seems like
> bringing a massively overpowered weapon to bear on something that
> will only be used rarely.
>
> Handling multiple exceptions from an ExceptionGroup could be done
> using a loop with pattern matching, so is except* really justified?
>
>
It is of course an option to split the PEP into two, add ExceptionGroup
first and then ask ourselves if we want except*.
We do have some experience with this from the Trio experiments with
MultiError though, so we are not starting from scratch.

Can you spell out how you see ExceptionGroup handling work with pattern
matching?
___
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/XZ5EGRGO5LMAO4DYRX2VZLFRBEVHWTIK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Jim J. Jewett]

ValueError("Partner: 3 File: 127 record: 93 is missing field: currency") tells 
the production support people who to contact and what to say.  
 
I'm not sure what additional context would be helpful, let alone how it might 
have been available "at the time", but lost now that the ValueAttribute is 
collected into an ExceptionGroup.

-jJ
___
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/GXUJTE25TWR5AKAYCTETKL4YWXQC2FR5/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 654 -- Exception Groups and except* : request for feedback for SC submission

[Jim J. Jewett]

> Why would you want a different flavor of ExceptionGroup?

The easiest example you took care of by saving the exceptions in a list instead 
of a set.  Next would be the ExceptionGroup vs BaseExceptionGroup that I 
*don't* like, but someone might.  There are also libraries that promise to 
raise only exceptions derived (possibly through multiple inheritance) from a 
particular marker exception.

But honestly, my biggest concern is that it just seems wrong for any class to 
be final, and it has sometimes been an irritant even for such obvious cases 
cases as Boolean.  So why is this so special?

-jJ
___
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/2AJJIOLL4RB2TKLYDA2Y7HGDRWEBUD5J/
Code of Conduct: http://python.org/psf/codeofconduct/

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

[Steven D'Aprano]

On Sat, Feb 27, 2021 at 01:04:08AM +, Oscar Benjamin wrote:
> On Fri, 26 Feb 2021 at 23:06, Jim J. Jewett  wrote:
> >

> > 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.
> 
> Thanks Jim, that is the situation and yes they are not CS students.

Why is that relevant?

I'm not an automotive engineer, I haven't studied for an Automotive 
Engineering Technology (AET) bachelor degree, but I still need to know 
how to change a flat tire, fill the petrol tank with fuel, keep the 
windscreen wiper water tank filled, put snow chains on if I live in a 
region with snow, etc. Or pay somebody else to do it.

Python is not Scratch. It doesn't, and shouldn't, aim to be a 
self-contained environment that isolates the user from their own 
computer.

[Aside: the Scratch interpreter will actually refuse to run if it thinks 
your code or documentation includes "bad words":

https://i.redd.it/nyqra8lmbei21.png

https://scratch.mit.edu/discuss/topic/32001/

https://scratch.mit.edu/discuss/topic/122410/

If this doesn't make you want to take off and nuke the entire planet 
from orbit, then I don't know what's wrong with you. End of rant.]

It doesn't matter whether you are using Windows, Mac OS X or Linux, 
whether your preferred UI is the command line or point-and-click, there 
are some basic fundemental skills that every amateur or professional 
programmer needs to know, such as:

- how to edit files and save them

- which file am I actually running?

- which interpreter am I actually running?

- how do I tell the computer to use a different interpreter?

These should be basic pre-requisites before learning to code, like being 
able to read and write.


[...]
> I see that the official Python tutorial now suggests typing
> "python3.9" [1]. Is that what is recommended now? Obviously that would
> fail for someone who had installed 3.8.

It isn't elitist to expect that, at the barest minimum, any student of 
programming should be able to adjust the command

python3.9 hello.py

to

python3.8 myscript.py

as required. If you can't debug 

python3.9: command not found

or

can't open file '/home/steve/hello.py': [Errno 2] No such file or directory

then you're probably going to have a miserable time dealing with *hard* 
bugs. Other more subtle errors may require a bit more knowledge, but 
that's okay. We don't need to make programming a knowledge-free 
activity.


> The other point though is that it doesn't need to be like this. If the
> issue was just installing Python and then setting up your PATH then
> that's manageable. The problem is that even after doing those things
> there isn't a "one way" to invoke Python from the command line. All
> possible invocations (python, python3, py, ...) will fail for some
> users. That's a problem for beginners but it's also a problem in any
> situation where you want to write a command line that should run on
> multiple platforms (e.g. in a Makefile or some other kind of script).

Writing code to run on any platform is a hard problem that requires 
complex solutions. If you need to write a makefile that will run on a 
million different flavours of Unix, including rare, old and weird ones, 
then you have to expect that's a hard problem and you're probably going 
to need to spend some effort getting it to work.

Not every problem is capable of being solved by a beginner with no 
knowledge, and we don't have to bust our guts to make it an easy 
problem. It's okay to delegate some problems to someone else, such as 
make experts.



> It would be great if Python could converge around a single way for
> users to invoke the Python that they have installed ...
> py also has features for selecting different versions

I don't think that "py --someoption ..." is any better than the existing 
solutions I already have for selecting different versions. Maybe on 
Windows? I don't know how it works there.


-- 
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/PPVEFLOVZERTPRHBBAL4IYJHTCZJXOGN/
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]

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/