[Python-Dev] Re: Reviving PEP 473

2021-03-15 Thread André Roberge
I am not a Python developer, but I am very interested in this topic.  While I 
would definitely make use of any additional fields for exceptions as discussed, 
it is already possible to find most, if not all of the information discussed in 
PEP 473. To give just a concrete example taken from the PEP:
```
Friendly Console version 0.3.1. [Python version: 3.8.4]

>>> a = {'foo': 1}
>>> a['fo']

Traceback (most recent call last):
  File "", line 1, in 
a['fo']
KeyError: 'fo'

Did you mean foo?
>>>
>>> foo = 1
>>> fo

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

Did you mean foo?
>>>
```
The above two examples are the actual output done by a program I work on called 
friendly (formerly known as friendly-traceback) and are essentially identical 
to what is given in PEP 473 as a desired outcome. 

Much information about IndexError, AttributeError, etc, mentioned as desirable 
in PEP 473 can already be obtained by such automated tools.  Using friendly as 
an example, a sample of what's possible can be found  at 
https://aroberge.github.io/friendly-traceback-docs/docs/html/tracebacks_en_3.8.html

Of course, having information more easily available about specific exceptions 
would be welcome and make it easier and likely more error-proof to write 
automated tools.  But since much of the information is already available (if 
one looks hard enough...), the cost of adding fields to existing exceptions 
should be carefully evaluated.

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


[Python-Dev] Re: [Python-ideas] Re: Re: Re: Amend PEP-8 to require clear, understandable comments instead of Strunk & White Standard English comments

2020-06-29 Thread André Roberge
Adding my voice to those that ask for such discussions be stopped ... and,
if at all possible, be snipped in the bud and prevented from occurring in
the future.

More below.

On Mon, Jun 29, 2020 at 12:51 PM Ricky Teachey  wrote:

> On Mon, Jun 29, 2020 at 10:51 AM Giampaolo Rodola' 
> wrote:
>
>>
>>
>>
>>
>> And what's the goal anyway? Make us all feel guilty, create yet another
>> heated discussion, widen divisions, wait for the occasional folks who dare
>> to speak up against this vitriol and kick them out? And then what? What is
>> the plan here exactly? Don't you folks realize this is a technical forum?
>>
>> ...

> Please, stop this.
>>
>> -
>> Giampaolo - gmpy.dev <https://gmpy.dev/about>
>>
>>
> The above response is how I feel about this. There is palpable fear right
> now that anyone who disagrees that these political types of discussion have
> a place in the professional world will be ostracized. I fear it even
> writing this short email. And that fear is more than warranted.
>
> The laudable goals of inclusion in the python community, which I support,
> are not being served by bringing these politically motivated changes-- a
> perfect example of which is this latest claim that S&W, an utterly
> inoffensive English language standard that itself has nothing to do with
> white supremacy, is a "relic of white supremacy" that has been place for
> two (or nearly two) decades in the core python founding PEPs, etc., and the
> absurd claim that it is hurtful in some way to non-white people, and these
> sorts of claims not only going unchallenged but even in some ways
> encouraged at the top of the leadership-- to the fore. It is divisive, and
> it makes me want to not want to be a part of the community because of 1.
> fear that I will pay dearly if I speak up (happily I'm not a developer
> although I've thought about a career change, but probably I can kiss that
> goodbye after this email) and 2. it is extremely unpleasant to have no
> realm of life-- not technical/professional, not sports, not even church--
> in which the American politics that permeate all of life these days (and
> seems to be reaching its tendrils across the water into other countries)
> can be put to the side.
>
> I'm tired. Please, please think about how we can make the focus of this
> community be technical considerations.
>

One of my proudest/happiest moments as a general Python contributor was
when I was nominated as a PSF Fellow in 2010.  In 2013, frustrated at
similar social/political discussions taking over some Python forum, and not
having the mental fortitude to speak up, I quietly asked for my status to
be converted to Emeritus (
https://www.python.org/psf/members/#emeritus-fellows) and withdrew for a
few years. This time, rather than be completely silent, I feel like I must
speak (for myself, and possibly for others) and ask to please stop these
non-technical digressions which only bring divisions.

André Roberge





>
> Rick.
>
> ___
> Python-ideas mailing list -- python-id...@python.org
> To unsubscribe send an email to python-ideas-le...@python.org
> https://mail.python.org/mailman3/lists/python-ideas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-id...@python.org/message/7AGI7S55LH44DTNYZGME7DZQFYTZFQ2X/
> 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/TLYM7MBDHMQDMF6OQC6ISAISPFG35JBW/
Code of Conduct: http://python.org/psf/codeofconduct/


[Python-Dev] Re: PEP 340 - possible new name for block-statement

2005-04-29 Thread André Roberge
Robin Munn wrote:
[snip]
Another possibility just occurred to me. How about "using"?
~using EXPR as VAR:
~BLOCK
Examples from PEP 340:
==
def synchronized(lock):
...
using synchronized(myLock):
...
= (+0)
def opening(filename, mode="r"):
...
using opening("/etc/passwd") as f:
...
= (+1)
def auto_retry(n=3, exc=Exception):
...
using auto_retry(3, IOError):
...
= (+1)
def synchronized_opening(lock, filename, mode="r"):
...
using synchronized_opening("/etc/passwd", myLock) as f:
...
= (+1)
A.R.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com