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

2020-07-25 Thread Marco Sulla
Well, about pprint, the solution is not easy... but about debugging, pytest for example does not show the full repr of an object, if the object is too large. You have to run pytest with the flag -v or -vv. Maybe that code could be moved in a separate little library. Another simple solution could b

[Python-ideas] Thoughts about implementing object-compare in unittest package?

2020-07-25 Thread Henry Lin
Hey all, What are thoughts about implementing an object-compare function in the unittest package? (Compare two objects recursively, attribute by attribute.) This seems like a common use case in many testing scenarios, and there are many 3rd party solutions solving the same problem. (Maybe we can p

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

2020-07-25 Thread Eric V. Smith
On 7/25/2020 3:11 PM, Christopher Barker wrote: On Sat, Jul 25, 2020 at 4:39 AM Eric V. Smith > wrote: But all of these always make me wonder about a return inside the suite. Does the "else" part execute (answer: no). So as a rule, I avoid the construc

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

2020-07-25 Thread David Mertz
On Sat, Jul 25, 2020, 3:12 PM Christopher Barker > I'm not advocating for any change (Obviously :-) ) -- but if there were to > be one, I"d strongly vote for some version of else not break or else if > not break because it introduces no keywords, and it's a lot more > compatible documentation-wise

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

2020-07-25 Thread Greg Ewing
How about we just document the whole feature as deprecated and never speak of it again? -- Greg ___ 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] Re: Faster object representation for UIs

2020-07-25 Thread Greg Ewing
On 26/07/20 1:34 am, Elizabeth Shashkova wrote: 1. We need this lazy `__repr__` calculation inside our debugger, where we work with different user's objects. Usually it isn't some specific type, for which you know that it'll be big and its `__repr__` calculation will be slow Seems to me it wo

[Python-ideas] Re: Fwd: Re: Experimenting with dict performance, and an immutable dict

2020-07-25 Thread Guido van Rossum
On Sat, Jul 25, 2020 at 12:45 PM Marco Sulla wrote: > I also remembered another possible use-case: kwargs in CPython. In C code, > kwargs are PyDictObjects. I suppose they are usually not modified; if so, > fdict could be used, since it seems to be faster at creation. > That's an interesting ide

[Python-ideas] Re: Fwd: Re: Experimenting with dict performance, and an immutable dict

2020-07-25 Thread Marco Sulla
On Thu, 23 Jul 2020 at 07:02, Yury Selivanov wrote: > If you're fascinated by functional programming then your version of > the frozen dict should support efficient (not "O(n)") mutations. > Well, I tried it. No O(n), but the result is quite interesting. Name: `o.set(key, value)`; Size:

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

2020-07-25 Thread Christopher Barker
On Sat, Jul 25, 2020 at 4:39 AM Eric V. Smith wrote: > On 7/25/2020 7:28 AM, Chris Angelico wrote: > > Do you REALLY think that everyone will automatically understand it > > just because it's spelled "for... then" instead of "for... else"? > > I wouldn't find "for ... then" any less confusing tha

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

2020-07-25 Thread Paul Sokolovsky
Hello, On Sat, 25 Jul 2020 16:34:16 +0300 Elizabeth Shashkova wrote: > Hi! > > Thanks everyone for the interest and for the suggested options! I > would like ro add my two coins and clarify some moments as the > original requester of this feature. > > 1. We need this lazy `__repr__` calculatio

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

2020-07-25 Thread Elizabeth Shashkova
Hi! Thanks everyone for the interest and for the suggested options! I would like ro add my two coins and clarify some moments as the original requester of this feature. 1. We need this lazy `__repr__` calculation inside our debugger, where we work with different user's objects. Usually it isn't s

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

2020-07-25 Thread Eric V. Smith
On 7/25/2020 7:28 AM, Chris Angelico wrote: Do you REALLY think that everyone will automatically understand it just because it's spelled "for... then" instead of "for... else"? I wouldn't find "for ... then" any less confusing than "for ... else". I do find "for ... else if not break" easier t

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

2020-07-25 Thread Chris Angelico
On Sat, Jul 25, 2020 at 7:18 PM Steven D'Aprano wrote: > > On Sat, Jul 25, 2020 at 11:40:06AM +1000, Chris Angelico wrote: > > > And a lot of style guides will say "prefer > > else because it's compatible with more Python versions". > > Like they did in Python 2 when we had two ways of getting the

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

2020-07-25 Thread Serhiy Storchaka
24.07.20 18:10, Gábor Bernát пише: 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

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

2020-07-25 Thread Serhiy Storchaka
16.07.20 07:34, Charles Machalow пише: Right now in str.format(), we have !s, !r, and !a to allow us to call str(), repr(), and ascii() respectively on the given expression. I'm proposing that we add a !p conversion to have pprint.pformat() be called to convert the given expression to a 'prett

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

2020-07-25 Thread Paul Sokolovsky
Hello, On Sat, 25 Jul 2020 18:44:55 +1000 Steven D'Aprano wrote: [] > I fear that even if we could get the average developer to say "I > know, let's use `ideas` to write a DSL", the project manager -- and > the rest of the team -- will probably respond "Over my dead body". > We're a long, long

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

2020-07-25 Thread Steven D'Aprano
On Sat, Jul 25, 2020 at 11:40:06AM +1000, Chris Angelico wrote: > And a lot of style guides will say "prefer > else because it's compatible with more Python versions". Like they did in Python 2 when we had two ways of getting the next element from an iterator? # Python 2.7 py> it = iter

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

2020-07-25 Thread Steven D'Aprano
On Sat, Jul 25, 2020 at 12:49:36PM +1000, Chris Angelico wrote: > On Sat, Jul 25, 2020 at 12:09 PM André Roberge > wrote: > > Already done (with a different keyword): > > > > https://aroberge.github.io/ideas/docs/html/nobreak.html > > That's a very nice project André, and I think it will probab

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

2020-07-25 Thread Paul Moore
On Fri, 24 Jul 2020 at 16:43, Gábor Bernát wrote: > > 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 t

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

2020-07-25 Thread Rob Cliffe via Python-ideas
On 25/07/2020 07:59, David Mertz wrote: On Thu, Jul 23, 2020, 9:19 PM Rob Cliffe via Python-ideas The upholders of the status quo regularly provide gallant explanations of why "else" is perfectly natural, even intuitive. They remind me of these two mathematicians: M1: This result is

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

2020-07-25 Thread David Mertz
On Thu, Jul 23, 2020, 9:19 PM Rob Cliffe via Python-ideas > 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 mortal