[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

[Chris Angelico]

On Sat, Jul 25, 2020 at 12:09 PM André Roberge  wrote:
>
>
>
> On Fri, Jul 24, 2020 at 10:43 PM Chris Angelico  wrote:
> SNIP
>>
>>
>> > If we had some sort of easy to use standard library support for
>> > transpiling code, then your advice could actually be practical and not
>> > just dismissive. "Pft, if you don't like it, write your own language" is
>> > not exactly practical for most people. Even if a transpiler is a tad
>> > simpler than writing an entire interpreter or compiler, it's still a new
>> > language.
>>
>> ... would be best done with stdlib support, yes. I think import hooks
>> can do everything that's needed, but I've never actually done it.
>> Normally I'd just use a simple source-to-source transformation before
>> execution, and usually I do things that aren't ever going to show up
>> (string literals aside), so I don't need it to be very smart.
>
>
> Already done (with a different keyword):
>
> https://aroberge.github.io/ideas/docs/html/nobreak.html
>

Thank you. Especially since the source code is extremely short:

https://github.com/aroberge/ideas/blob/master/ideas/examples/nobreak.py

I'd like to see this 'ideas' module (or similar) better known. It'd
help a lot with complaints like Steven's.

ChrisA
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/CVCNTLEZPZRYXAHSYQAHCE3ZNXW6HUNP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

[André Roberge]

On Fri, Jul 24, 2020 at 10:43 PM Chris Angelico  wrote:
SNIP

>
> > If we had some sort of easy to use standard library support for
> > transpiling code, then your advice could actually be practical and not
> > just dismissive. "Pft, if you don't like it, write your own language" is
> > not exactly practical for most people. Even if a transpiler is a tad
> > simpler than writing an entire interpreter or compiler, it's still a new
> > language.
>
> ... would be best done with stdlib support, yes. I think import hooks
> can do everything that's needed, but I've never actually done it.
> Normally I'd just use a simple source-to-source transformation before
> execution, and usually I do things that aren't ever going to show up
> (string literals aside), so I don't need it to be very smart.
>

Already done (with a different keyword):

https://aroberge.github.io/ideas/docs/html/nobreak.html

André Roberge


> ChrisA
> ___
> Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/TZ7XW73YHYSIYTNT3NA4PBCNNBWELFHL/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/2OEICXV6JWWO4KYGJMIQ6FY2GJLB23ON/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

[Chris Angelico]

On Sat, Jul 25, 2020 at 11:13 AM Steven D'Aprano  wrote:
>
> On Thu, Jul 23, 2020 at 07:22:51AM +1000, Chris Angelico wrote:
>
> > Please, everyone, can we NOT keep coming up with ideas that are
> > basically "let's invent a new spelling for exactly the same thing,
> > with no benefits,
>
> Surely having a less confusing and misleading spelling is a benefit.

Minor, given that the existing spelling still has to be supported. Now
you have two ways to do it, for the foreseeable future, and only style
guides will differentiate. And a lot of style guides will say "prefer
else because it's compatible with more Python versions". How long will
it be before you can actually take advantage of it?

> We like to use Python because its syntax is so readable and obvious.
> "for...else" is a wart on the language, it is a lovely feature marred by
> a confusing keyword. The long term benefit is to reduce that confusion.

I don't dispute that, but that's very long term benefit, with a lot of
short and medium term costs. The concept is a bit unusual (I don't
know many other languages that support this with *any* spelling), so
it still has to be explained, and a lot of people will still be
confused no matter how you spell it. How much benefit do you actually
gain?

> Guido seems to be open to the use of *soft keywords* now that CPython
> has moved to a PEG parser. Perhaps we could introduce a soft keyword as
> an alternative spelling for "else":
>
>
> for x in sequence:
> ...
> then:  # allow the bike-shedding to begin :-(
> ...
>
>
> Being a soft keyword, outside of that context it will remain legal, so
> no-one needs to rename their "then" methods or variables.

That's a notable reduction in cost (and an improvement in flexibility
for the bikeshedding - although that will, of course, mean that the
bikeshedding takes ten times longer!), but the cost of creating a
second way to do things isn't just the creation of the keyword.

> So here's a concrete proposal:
>
> (1) `for...else` and `while...else` stay, for backwards compatibility.
>
> (2) Add a soft keyword "then" (bikeshed away...) to use in for and
> while loops, as an alternative preferred spelling to "else".
>
> (3) Update PEP 8 to make it clear that new code should use `for...then`
> and `while...then` rather than "else". (Old code need not change just
> for the sake of changing it.)
>
> (4) Linters and style-checkers can prefer `then`, but the interpreter
> itself will remain neutral and accept both.
>
> To avoid all doubt:
>
> (5) There is no plan to depreciate the hard keyword `else`, not even a
> PendingDepreciation warning.

Linters and style checkers will have to choose whether to recommend
the "better" spelling (unquantifiable benefit) or the one that runs on
more versions of Python (concrete, meaningful benefit).

> (6) Any suggestion that we repurpose `for...else` to mean "run this if
> the loop is empty" will have to justify itself. It is not part of this
> proposal.

I hope nobody EVER proposes that. Having code that means different
things on different Python versions would be an absolute pest to work
with. But if all the prior objections are overcome and "for... then"
gains currency, there'd be some reasonable grounds for proposing a
completely different keyword to have the "if loop is empty" semantics.

> It seems to me that this is a pretty minor change, with little downside,
> that could have a big effect on the readability and usefulness of what's
> currently spelled as `for...else` and underused because people find it
> confusing. Compared to the benefits, the downsides are small:
>
> - Someone has to do the work. That's a one-off cost.
>
> - Double the tests: we have to verify `for...else` and `for...then` both
> work. This is a pretty small cost.
>
> - Two ways to do it. Despite the Zen, there are two ways to do many
> things in Python. But this is a pure alias: for...then and for...else
> are literally compiled to the same code. The Zen should be understood as
> *food for thought* not unbreakable rules of nature. If we accept this
> proposal, we could interpret it as follows:
>
> * the One Way to do it is `for...then`;
>
> * but for backwards compatibility there's also an alternative
>   spelling that we prefer not to talk about, see the docs if
>   you care.

And all your documentation, examples, etc, have to care.

> > and demanding new keywords, so we can break people's
> > code for no reason"? You can always just write your own transpiler to
> > let yourself spell it your preferred way.
>
> How do I do that?
>
> That's not a rhetorical question. I keep wanting to study projects like
> LikePython for hints, because I am sick of *Old Man Python* telling
> me what I can and can't write, but somehow never find the time.

It depends how smart you want it to be. If you literally just search
and replace "then:" into "else:" without caring about context, it'd be
trivially easy. Obviously that's pretty risky, 

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

[Steven D'Aprano]

On Thu, Jul 23, 2020 at 07:22:51AM +1000, Chris Angelico wrote:

> Please, everyone, can we NOT keep coming up with ideas that are
> basically "let's invent a new spelling for exactly the same thing,
> with no benefits, 

Surely having a less confusing and misleading spelling is a benefit.

We like to use Python because its syntax is so readable and obvious. 
"for...else" is a wart on the language, it is a lovely feature marred by 
a confusing keyword. The long term benefit is to reduce that confusion.

We have heard from people in this thread that they reject for...else in 
code reviews because it is too confusing.

The question to me is not "Why make this change for no benefit?" but "Is 
the benefit sufficient to go through the pain of change?".

Guido seems to be open to the use of *soft keywords* now that CPython 
has moved to a PEG parser. Perhaps we could introduce a soft keyword as 
an alternative spelling for "else":


for x in sequence:
...
then:  # allow the bike-shedding to begin :-(
...


Being a soft keyword, outside of that context it will remain legal, so 
no-one needs to rename their "then" methods or variables. Code using 
"for...else" remains legal, although linters might warn against it.

We need not actually depreciate the use of "else", not unless we plan to 
reintroduce it with a different meaning. But that's a separate 
discussion. So here's a concrete proposal:

(1) `for...else` and `while...else` stay, for backwards compatibility.

(2) Add a soft keyword "then" (bikeshed away...) to use in for and 
while loops, as an alternative preferred spelling to "else".

(3) Update PEP 8 to make it clear that new code should use `for...then` 
and `while...then` rather than "else". (Old code need not change just 
for the sake of changing it.)

(4) Linters and style-checkers can prefer `then`, but the interpreter 
itself will remain neutral and accept both.

To avoid all doubt:

(5) There is no plan to depreciate the hard keyword `else`, not even a 
PendingDepreciation warning.

(6) Any suggestion that we repurpose `for...else` to mean "run this if 
the loop is empty" will have to justify itself. It is not part of this 
proposal.


It seems to me that this is a pretty minor change, with little downside, 
that could have a big effect on the readability and usefulness of what's 
currently spelled as `for...else` and underused because people find it 
confusing. Compared to the benefits, the downsides are small:

- Someone has to do the work. That's a one-off cost.

- Double the tests: we have to verify `for...else` and `for...then` both 
work. This is a pretty small cost.

- Two ways to do it. Despite the Zen, there are two ways to do many 
things in Python. But this is a pure alias: for...then and for...else 
are literally compiled to the same code. The Zen should be understood as 
*food for thought* not unbreakable rules of nature. If we accept this 
proposal, we could interpret it as follows:

* the One Way to do it is `for...then`;

* but for backwards compatibility there's also an alternative 
  spelling that we prefer not to talk about, see the docs if
  you care.


There are no runtime costs. The compiler should generate the exact same 
bytecode for the two spellings. There's no breaking backwards 
compatibility, as `then:` followed by a block is not currently legal. If 
`then` is a soft keyword, existing uses of "then" won't be affected.


> and demanding new keywords, so we can break people's
> code for no reason"? You can always just write your own transpiler to
> let yourself spell it your preferred way.

How do I do that?

That's not a rhetorical question. I keep wanting to study projects like 
LikePython for hints, because I am sick of *Old Man Python* telling 
me what I can and can't write, but somehow never find the time.

https://jon.how/likepython/

If we had some sort of easy to use standard library support for 
transpiling code, then your advice could actually be practical and not 
just dismissive. "Pft, if you don't like it, write your own language" is 
not exactly practical for most people. Even if a transpiler is a tad 
simpler than writing an entire interpreter or compiler, it's still a new 
language.


-- 
Steven
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/CAABTU7PYU3CPUWCAFDZNUEXY24VPAGQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Deprecation of Enum members

[Ethan Furman]

On 7/23/20 12:24 PM, s.williamswynn.m...@gmail.com wrote:


I have run into a situations when an enum member becomes obsolete.
However, I'd like to avoid removing the member from the enum to give time for 
users to catch up to a libraries core types.


This would be good.


I've seen Java has a @Deprecated annotation for their Enums.
Python enum's can also set an _ignore_ attribute which will avoid instantiating 
a member in the list.


The purpose behind _ignore_ is to be able to use temporary variables 
without those variables becoming members.



I've implemented a similar approach to solve deprecating enum members.

You can check it out here: https://github.com/foxyblue/cpython/pull/1


Interesting.  I prefer the approach in my Stackoverflow answer:

  https://stackoverflow.com/a/62309159/208880

Yours is quite similar, but mine is more general-purpose and so easily 
allows for a useful message as well.


--
~Ethan~
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/2QYCUQRJUTNQOFHVWGDNIYW2RHUAXDSL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: add !p to pprint.pformat() in str.format() an f-strings

[Jelle Zijlstra]

El mar., 21 jul. 2020 a las 17:27, Guido van Rossum ()
escribió:

> A philosophical problem with this is proposal is that it takes a notation
> that is processed by the bytecode compiler and makes it dependent on user
> code to be imported from the stdlib. We only do that in rare cases — IIRC
> the only other case is ‘import’ calling ‘__import__()’.
>
> There's also `__build_class__`, which gets called during class creation.
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/ZYXD5PWFMPIDP5BOFOD2OYCZY6GRAC7A/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Faster object representation for UIs

[Alex Hall]

You may be interested in my library https://github.com/alexmojaki/cheap_repr

It was created precisely for the purpose of generating many reprs quickly
for my debugging libraries.

On Fri, Jul 24, 2020 at 5:17 PM Gábor Bernát  wrote:

> Hello, I'd like to bring to your attention
> https://bugs.python.org/issue41383. The core idea here is per Elizaveta
> Shashkova:
>
> I would like to have a lazy repr evaluation for the objects! Sometimes
> users have many really large objects, and when debugger is trying to show
> them in Variables View (=show their string representation) it can takes a
> lot of time. We do some tricks, but they not always work. It would be
> really-really cool to have parameter in repr, which defines max number of
> symbols we want to evaluate during repr for this object.
> Maybe repr is not the best here, because that should be interpreter
> meaningful, but instead the __str__ method that's better for this. Maybe we
> could pass in an optional limit argument to these methods, so that the user
> can decide what to print depending on how many characters he has left?
>
> Any takes, better ideas how we could help this problem?
>
> Thanks,
>
> Bernat
> ___
> Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/O7TCM7F4XQAMAQJ43C6SAVKC7M2C4QHR/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/VKPEQD5AXCYTD7U2AH6NEBD63CR63WIX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Faster object representation for UIs

[Guido van Rossum]

But adding an optional parameter to an existing dunder is pretty much the
worst choice. Every existing method of that name would have to be altered,
or you’d end up with horrible code to cope with it — either catching
exceptions or introspection.

On Fri, Jul 24, 2020 at 10:35 Bernat Gabor  wrote:

> You could do it with a custom function, however the hope in this e-mail
> thread was that the language should agree on this function name, and
> ideally should be __str__/__repr__ with an optional argument. And then we
> should implement stdlib types to follow this custom logic (think e.g. of
> repr-ing an array that has lots of values).
>
> On Fri, Jul 24, 2020 at 5:59 PM Paul Moore  wrote:
>
>> On Fri, 24 Jul 2020 at 16:15, Gábor Bernát 
>> wrote:
>> >
>> > Hello, I'd like to bring to your attention
>> https://bugs.python.org/issue41383. The core idea here is per Elizaveta
>> Shashkova:
>> >
>> > I would like to have a lazy repr evaluation for the objects! Sometimes
>> users have many really large objects, and when debugger is trying to show
>> them in Variables View (=show their string representation) it can takes a
>> lot of time. We do some tricks, but they not always work. It would be
>> really-really cool to have parameter in repr, which defines max number of
>> symbols we want to evaluate during repr for this object.
>> > Maybe repr is not the best here, because that should be interpreter
>> meaningful, but instead the __str__ method that's better for this. Maybe we
>> could pass in an optional limit argument to these methods, so that the user
>> can decide what to print depending on how many characters he has left?
>> >
>> > Any takes, better ideas how we could help this problem?
>>
>> Why not just use a custom function for this? I don't understand why
>> this has to be coupled to repr, or indeed to anything that's special
>> to the repr.
>>
>> The debugger (presumably a custom application) could call a custom
>> function to generate the string representation, and that function
>> could have any API it wants. The default implementation of the
>> function (functools.singledispatch seems like it would be ideal for
>> this) could just call repr, so that objects that don't need special
>> treatment would use repr.
>>
>> This doesn't seem like it's something that should need language support
>> at all.
>>
>> Paul
>>
> ___
> Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/KVAZJCNLO7N7DHGGTV6FYPRDKKUP7EY6/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-- 
--Guido (mobile)
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/2NOFHHHQSMPOEBPCYU4IE5OGMSYV24FS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Faster object representation for UIs

[Eric V. Smith]

On 7/24/2020 1:33 PM, Bernat Gabor wrote:
You could do it with a custom function, however the hope in this 
e-mail thread was that the language should agree on this function 
name, and ideally should be __str__/__repr__ with an optional 
argument. And then we should implement stdlib types to follow this 
custom logic (think e.g. of repr-ing an array that has lots of values).


This seems more like a feature for pprint, if it doesn't already provide it.

Eric



On Fri, Jul 24, 2020 at 5:59 PM Paul Moore > wrote:


On Fri, 24 Jul 2020 at 16:15, Gábor Bernát mailto:jokerjoke...@gmail.com>> wrote:
>
> Hello, I'd like to bring to your attention
https://bugs.python.org/issue41383. The core idea here is per
Elizaveta Shashkova:
>
> I would like to have a lazy repr evaluation for the objects!
Sometimes users have many really large objects, and when debugger
is trying to show them in Variables View (=show their string
representation) it can takes a lot of time. We do some tricks, but
they not always work. It would be really-really cool to have
parameter in repr, which defines max number of symbols we want to
evaluate during repr for this object.
> Maybe repr is not the best here, because that should be
interpreter meaningful, but instead the __str__ method that's
better for this. Maybe we could pass in an optional limit argument
to these methods, so that the user can decide what to print
depending on how many characters he has left?
>
> Any takes, better ideas how we could help this problem?

Why not just use a custom function for this? I don't understand why
this has to be coupled to repr, or indeed to anything that's special
to the repr.

The debugger (presumably a custom application) could call a custom
function to generate the string representation, and that function
could have any API it wants. The default implementation of the
function (functools.singledispatch seems like it would be ideal for
this) could just call repr, so that objects that don't need special
treatment would use repr.

This doesn't seem like it's something that should need language
support at all.

Paul


___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/KVAZJCNLO7N7DHGGTV6FYPRDKKUP7EY6/
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/N6JJLAOEVJA4MD6W6KWFL6UQBK3BBEGV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Faster object representation for UIs

[Bernat Gabor]

You could do it with a custom function, however the hope in this e-mail
thread was that the language should agree on this function name, and
ideally should be __str__/__repr__ with an optional argument. And then we
should implement stdlib types to follow this custom logic (think e.g. of
repr-ing an array that has lots of values).

On Fri, Jul 24, 2020 at 5:59 PM Paul Moore  wrote:

> On Fri, 24 Jul 2020 at 16:15, Gábor Bernát  wrote:
> >
> > Hello, I'd like to bring to your attention
> https://bugs.python.org/issue41383. The core idea here is per Elizaveta
> Shashkova:
> >
> > I would like to have a lazy repr evaluation for the objects! Sometimes
> users have many really large objects, and when debugger is trying to show
> them in Variables View (=show their string representation) it can takes a
> lot of time. We do some tricks, but they not always work. It would be
> really-really cool to have parameter in repr, which defines max number of
> symbols we want to evaluate during repr for this object.
> > Maybe repr is not the best here, because that should be interpreter
> meaningful, but instead the __str__ method that's better for this. Maybe we
> could pass in an optional limit argument to these methods, so that the user
> can decide what to print depending on how many characters he has left?
> >
> > Any takes, better ideas how we could help this problem?
>
> Why not just use a custom function for this? I don't understand why
> this has to be coupled to repr, or indeed to anything that's special
> to the repr.
>
> The debugger (presumably a custom application) could call a custom
> function to generate the string representation, and that function
> could have any API it wants. The default implementation of the
> function (functools.singledispatch seems like it would be ideal for
> this) could just call repr, so that objects that don't need special
> treatment would use repr.
>
> This doesn't seem like it's something that should need language support at
> all.
>
> Paul
>
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/KVAZJCNLO7N7DHGGTV6FYPRDKKUP7EY6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Faster object representation for UIs

[Paul Moore]

On Fri, 24 Jul 2020 at 16:15, Gábor Bernát  wrote:
>
> Hello, I'd like to bring to your attention 
> https://bugs.python.org/issue41383. The core idea here is per Elizaveta 
> Shashkova:
>
> I would like to have a lazy repr evaluation for the objects! Sometimes users 
> have many really large objects, and when debugger is trying to show them in 
> Variables View (=show their string representation) it can takes a lot of 
> time. We do some tricks, but they not always work. It would be really-really 
> cool to have parameter in repr, which defines max number of symbols we want 
> to evaluate during repr for this object.
> Maybe repr is not the best here, because that should be interpreter 
> meaningful, but instead the __str__ method that's better for this. Maybe we 
> could pass in an optional limit argument to these methods, so that the user 
> can decide what to print depending on how many characters he has left?
>
> Any takes, better ideas how we could help this problem?

Why not just use a custom function for this? I don't understand why
this has to be coupled to repr, or indeed to anything that's special
to the repr.

The debugger (presumably a custom application) could call a custom
function to generate the string representation, and that function
could have any API it wants. The default implementation of the
function (functools.singledispatch seems like it would be ideal for
this) could just call repr, so that objects that don't need special
treatment would use repr.

This doesn't seem like it's something that should need language support at all.

Paul
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/U7NCTAV2LYESJ64H3TNV2T7CK5WYAFRL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Faster object representation for UIs

[2QdxY4RzWzUUiLuE]

On 2020-07-24 at 15:10:46 -,
Gábor Bernát  wrote:

> ... Sometimes users have many really large objects, and when debugger
> is trying to show them in Variables View (=show their string
> representation) it can takes a lot of time. We do some tricks, but
> they not always work. It would be really-really cool to have parameter
> in repr, which defines max number of symbols we want to evaluate
> during repr for this object.

> Maybe repr is not the best here, because that should be interpreter
> meaningful, but instead the __str__ method that's better for
> this. Maybe we could pass in an optional limit argument to these
> methods, so that the user can decide what to print depending on how
> many characters he has left?

> Any takes, better ideas how we could help this problem?

Use the pretty printer/formatter.¹

Start with a small depth and let the user adjust it.

¹ https://docs.python.org/3/library/pprint.html
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/PTYLW3NVCVWJIGXKN5DQQBAWHEKQ23Z3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Faster object representation for UIs

[Chris Angelico]

On Sat, Jul 25, 2020 at 1:18 AM Gábor Bernát  wrote:
>
> Hello, I'd like to bring to your attention 
> https://bugs.python.org/issue41383. The core idea here is per Elizaveta 
> Shashkova:
>
> I would like to have a lazy repr evaluation for the objects! Sometimes users 
> have many really large objects, and when debugger is trying to show them in 
> Variables View (=show their string representation) it can takes a lot of 
> time. We do some tricks, but they not always work. It would be really-really 
> cool to have parameter in repr, which defines max number of symbols we want 
> to evaluate during repr for this object.
> Maybe repr is not the best here, because that should be interpreter 
> meaningful, but instead the __str__ method that's better for this. Maybe we 
> could pass in an optional limit argument to these methods, so that the user 
> can decide what to print depending on how many characters he has left?
>

I honestly don't think that either __repr__ or __str__ is appropriate
for this. You need some sort of hook that has, potentially, a lot of
debugger hooks in it. I would say it's best handled by some sort of
multiple dispatch within the debugger itself; it can handle core data
types (list/tuple, dict) and then provide hooks for custom types to
register themselves with it.

But one thing that would be kinda nice would be to have a way for a
class to say "I'm like a dict, but with extra info". Consider
defaultdict and Counter:

>>> c = collections.defaultdict(list)
>>> c[1].append("asdf")
>>> c
defaultdict(, {1: ['asdf']})
>>> collections.Counter("Hello, world")
Counter({'l': 3, 'o': 2, 'H': 1, 'e': 1, ',': 1, ' ': 1, 'w': 1, 'r':
1, 'd': 1})

Both of them include a dict-like repr in their reprs, and both of them
would probably want to have the debugger display them in a dict-like
way too.

Maybe reprlib would be the place for something like this?

ChrisA
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/SLBUWGKDYNZ5RXXVIDXH27XM4RKBCMDQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Faster object representation for UIs

[Gábor Bernát]

While I agree the implementation on how to represent in limited space the 
object should be the responsibility of the project that provides objects of 
long size, I think it's a language-behaviour material what type of solution we 
want to propose/recommend.
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/64FIMMAXNZWSR2OM26KACZTVVEGVDHUK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: Faster object representation for UIs

[Joao S. O. Bueno]

That is definitely not language-behavior material  - and should be a worry
of the authors of whatever projects have objects that demand so much
processing to generate a "repr".

It certainly is not a common problema met with - I often have to deal
with cumbersome repr's (even in my own projects), but due to their size.

If an object performs recursive external-resource queries just for
ordinarily
printing a repr, to a point it is getting in the way of interactive use it
obviously should not,
 and should create a separate "full_repr(...)" method for that.

note that you can _already_ accept an optional parameter in the
`__repr__` method to behave like you  proposed - or your `__repr__`
could check a setting somewhere to find out the behavior it should have.

On Fri, 24 Jul 2020 at 12:14, Gábor Bernát  wrote:

> Hello, I'd like to bring to your attention
> https://bugs.python.org/issue41383. The core idea here is per Elizaveta
> Shashkova:
>
> I would like to have a lazy repr evaluation for the objects! Sometimes
> users have many really large objects, and when debugger is trying to show
> them in Variables View (=show their string representation) it can takes a
> lot of time. We do some tricks, but they not always work. It would be
> really-really cool to have parameter in repr, which defines max number of
> symbols we want to evaluate during repr for this object.
> Maybe repr is not the best here, because that should be interpreter
> meaningful, but instead the __str__ method that's better for this. Maybe we
> could pass in an optional limit argument to these methods, so that the user
> can decide what to print depending on how many characters he has left?
>
> Any takes, better ideas how we could help this problem?
>
> Thanks,
>
> Bernat
> ___
> Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/O7TCM7F4XQAMAQJ43C6SAVKC7M2C4QHR/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/ZEEM4G7SFWLAOZ324UYOSH3U7IOZOB2J/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Faster object representation for UIs

[Gábor Bernát]

Hello, I'd like to bring to your attention https://bugs.python.org/issue41383. 
The core idea here is per Elizaveta Shashkova:

I would like to have a lazy repr evaluation for the objects! Sometimes users 
have many really large objects, and when debugger is trying to show them in 
Variables View (=show their string representation) it can takes a lot of time. 
We do some tricks, but they not always work. It would be really-really cool to 
have parameter in repr, which defines max number of symbols we want to evaluate 
during repr for this object.
Maybe repr is not the best here, because that should be interpreter meaningful, 
but instead the __str__ method that's better for this. Maybe we could pass in 
an optional limit argument to these methods, so that the user can decide what 
to print depending on how many characters he has left?

Any takes, better ideas how we could help this problem?

Thanks,

Bernat
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/O7TCM7F4XQAMAQJ43C6SAVKC7M2C4QHR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Deprecation of Enum members

[s . williamswynn . mail]

Evening,

I have run into a situations when an enum member becomes obsolete.
However, I'd like to avoid removing the member from the enum to give time for 
users to catch up to a libraries core types.

I've seen Java has a @Deprecated annotation for their Enums.
Python enum's can also set an _ignore_ attribute which will avoid instantiating 
a member in the list.

I've implemented a similar approach to solve deprecating enum members.

You can check it out here: https://github.com/foxyblue/cpython/pull/1
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/IGVV425PWIAQ622XJ267QVN3KLVZZEVA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

[Mathew Elman]

On Thu, 23 Jul 2020 at 16:25, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> Mathew Elman writes:
>
>  > Frankly, saying that a part of a language that is frequently
>  > misunderstood, is *never* allowed to be improved is disappointing
>  > when the suggestion that it can be (somehow) has been so well
>  > received by everyone else.
>
> The highly improbable is frequently well-received.
>
> What can surely be improved is the documentation, specifically the
> Tutorial.  Something like
>
> The else clause of a loop statement has frequently been
> misunderstood.  In a for or while loop *statement*, on each
> iteration, the condition is tested and exactly one of the
> following occurs:
>
> 1.  If truthy, the loop *suite* runs to completion and the test is
> repeated for the next iteration,
> 2.  OR the loop *suite* runs and there is a nonlocal exit such as
> return or break or raise, which exits the statement as well.
> 3.  OTHERWISE the condition is false, and the else suite, if any,
> runs, then the statement is exited.
>
> The emphasis is for contrast in this discussion.  The Language
> Reference already says precisely this, although much more concisely.
>
> I don't expect supporters of "elif not break" etc to think this is
> sufficient, and supporters of the Else Ban similarly.  Please consider
> if this is helps clarify the Tutorial, and if it doesn't get booed
> into oblivion, I'll work up a patch (I think that the section on
> control flow would benefit from some reorganization as well, "just
> stick it in somewhere" is not what I have in mind :-).
>

Credit where credit is due, I think this is definitely an improvement. It
does make it require slightly less meticulous reading to understand `else`.
However, I still think that there is value in improving the `for...else`
and `while...else` intuitiveness, if it can be done at an acceptable cost.
(As is the case with any change)

IMO the solution is not to change `else` but to add an additional with the
opposite meaning that makes the use of `else` with `for` and `while` more
intuitive, such as adding `elif`, which feels natural, and a special
boolean, which perhaps doesn't. Or adding `except` for catching raised
Exceptions  rather than breaks, which makes `else` clearly behave how it
does for `try`. Or another solution that achieves the additional clarity
*without* removing/changing else itself.



> Steve
>

-- 


Notice: 
This email is confidential and may contain copyright material of 
members of the Ocado Group. Opinions and views expressed in this message 
may not necessarily reflect the opinions and views of the members of the 
Ocado Group.

If you are not the intended recipient, please notify us 
immediately and delete all copies of this message. Please note that it is 
your responsibility to scan this message for viruses.

References to the 
"Ocado Group" are to Ocado Group plc (registered in England and Wales with 
number 7098618) and its subsidiary undertakings (as that expression is 
defined in the Companies Act 2006) from time to time. The registered office 
of Ocado Group plc is Buildings One & Two, Trident Place, Mosquito Way, 
Hatfield, Hertfordshire, AL10 9UL.
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/TN7G7VPAOUKW7FPCYYU5CZIKNSIQPMPX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

[Barry Scott]

> On 23 Jul 2020, at 17:04, Rob Cliffe via Python-ideas 
>  wrote:
> 
> 
> 
> On 23/07/2020 16:24, Stephen J. Turnbull wrote:
>> Steven D'Aprano writes:
>>  > On Wed, Jul 22, 2020 at 06:14:39AM +0300, Paul Sokolovsky wrote:
>> 
>>  > > But no, loop executes, *or else* the following "else" block
>>  > > executes ;-).
>> 
>> He means the loop *suite* executes (this includes "getting to" a break
>> statement or other control flow that leaves the loop *statement*
>> entirely), and if it doesn't, the else suite does.  This is "why" such
>> nonlocal exits differ from finally in that they don't run the else suite.
>> 
>> I personally think this is a perfectly clear and convincing argument
>> for "else" as the keyword for this statement (once "suite" is added to
>> Paul's phrasing).
>> 
>> This is why programmers should major in English, and do a graduate
>> degree in programming if they really think they need a degree in
>> programming.
>> 
>> 
> The upholders of the status quo regularly provide gallant explanations of why 
> "else" is perfectly natural, even intuitive.
> The fact is, it isn't.  If it were, it wouldn't *need* to be repeatedly 
> explained by gurus to lesser mortals.  I can't think of any other area of 
> Python that needs to be defended so regularly and so vociferously, nor that 
> very experienced Python programmers confess they find confusing.  Swelp me, 
> someone in this very thread (Barry) misunderstood it[1].  And suggesting that 
> those of us who don't find it clear lack skill in English is just plain 
> insulting.

Yes indeed, my intuition cannot get the for else into my head.
And as I proved wonderfully I got it wrong.
I never use the for else and in the rare cases I have seen it in code reviews 
ask that it is replaced because so few people know what it means.

Barry

> 
> YMMV, but the only way I can grok it when I see it is to mentally translate 
> "else" to "if no break".  This is mental effort that would be spared or at 
> least diminished if it were spelt in a more obvious way in the first place.
> 
> Best wishes
> Rob Cliffe
> [1] or at least I think he did, I had trouble understanding him.
> ___
> Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/5GP4ECQNS456YW5I73F4Y7N7ALSLHDQ2/
> Code of Conduct: http://python.org/psf/codeofconduct/

___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/CM37P5UODT4OF4NKR6FM32IC24GO7NFK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-ideas] Re: New clause in FOR and WHILE instead of ELSE

[Paul Moore]

On Fri, 24 Jul 2020 at 02:18, Rob Cliffe via Python-ideas
 wrote:

> The upholders of the status quo regularly provide gallant explanations of why 
> "else" is perfectly natural, even intuitive.
> The fact is, it isn't.  If it were, it wouldn't *need* to be repeatedly 
> explained by gurus to lesser mortals.

Fair point. It needs to be learned and remembered. It's not intuitive.

> YMMV, but the only way I can grok it when I see it is to mentally translate 
> "else" to "if no break".  This is mental effort that would be spared or at 
> least diminished if it were spelt in a more obvious way in the first place.

Again, probably true. With hindsight, if we were designing Python from
scratch now, we'd probably not spell this as "else". We'd probably
omit it altogether rather than using an alternative spelling, but
that's a side issue.

BUT - we're not designing Python now. The "else" clause on loops has
been around for many years. It's in books, training courses and in
existing, working code. We can't break all of that without a fairly
large cost. And (as I've noted before) having *two* ways of writing
this obscure construct would be even more confusing, particularly as
people working with existing code or learning from existing training
materials will naturally see the (presumably less intuitive and
obvious) "else" spelling.

So even accepting all of your points above, it's still very unlikely
this will change. Not because there's no benefit, but because the cost
is too high.

Paul
___
Python-ideas mailing list -- python-ideas@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-ideas@python.org/message/PT534P37SLBJJUUC6WSDXE46KNGT4ZKC/
Code of Conduct: http://python.org/psf/codeofconduct/