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.
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
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
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
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 @D
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
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.pyth
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:
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 follo
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
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 objec
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 real
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 obj
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.
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), b
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 (
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 _ignor
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
> 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
>
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 lesse
20 matches
Mail list logo
