Dom Grigonis writes:
> By “elegant", I wasn’t talking about the syntax.
Neither was I, except in the comment about "mnemonic". I use "postfix
=" and "prefix =" because I don't know of better names that indicate
the semantics of the feature.
Semantically, "prefix =" is a reasonable solution to
> But it's far from concise
What could be more concise?
> and
> violates DRY -- it doesn't solve the problem of the first draft typo.
And how is “postfix =“ different?
> I don't see it as elegant the way "postfix =" is.
Agreed.
DG
___
Python-ideas mai
Dom Grigonis writes:
> > But it's far from concise
> What could be more concise?
A notation where you don't have to repeat a possibly long expression.
For example, numerical positions like regular expressions. Consider
this possible notation:
f'There are {count} expression{pluralize(count
The problem is that `f'{exp,format}'` is the current 'status
quo'/'zeitgeist'
You are trying to invert it. It looks wrong. (That's taste, not technical,
if you don't think it is a problem, it isn't a problem for *you*)
The technical: `f'{=name}'` doesn't tell what you're trying to do if you
don't
> On 24 Sep 2023, at 16:42, Stephen J. Turnbull
> wrote:
>
> Dom Grigonis writes:
>
>>> But it's far from concise
>> What could be more concise?
>
> A notation where you don't have to repeat a possibly long expression.
> For example, numerical positions like regular expressions. Consider
>
On Mon, 25 Sept 2023 at 00:15, Dom Grigonis wrote:
> I see what you mean, but this property is arguably intrinsic to what it is.
> And is part of f-strings vs explicit formatting property too:
>
> variable = 1
> print(f'{variable=} and b={variable}')
> # VS
> msg = 'variable={v} and b={v}'
> prin
or
print('{a=} and b={a}')
This already exists. Kindly stop reinventing the wheel.
the thing that does not exist now is:
print('In this context, variable', 'name', 'means an esoteric thing
that we all know about')
where `'name'` can be substituted easily (the 'nameof' case) but it could
be,
> On 24 Sep 2023, at 17:23, Chris Angelico wrote:
>
> On Mon, 25 Sept 2023 at 00:15, Dom Grigonis wrote:
>> I see what you mean, but this property is arguably intrinsic to what it is.
>> And is part of f-strings vs explicit formatting property too:
>>
>> variable = 1
>> print(f'{variable=} a
I think the separation is needed between the 2:
a) identifier name
b) expression text
I think there is a mix-up between these 2 which causes some confusion (at least
to me). Wanting both made me cling to f-strings as they currently do b) in
‘postfix=' and a) can be extracted from it.
—
I
There definitely is a miscommunication:
The 2 first options was me spitballing an alternative against the third.
The not reinventing the wheel remark was me saying that the particular
example that you gave *on that particular message* can already be done.
Also the case 2 f'{name!i}', I suggested
> On 24 Sep 2023, at 19:27, Tiago Illipronti Girardi
> wrote:
>
> There definitely is a miscommunication:
>
> The 2 first options was me spitballing an alternative against the third.
>
> The not reinventing the wheel remark was me saying that the particular
> example that you gave *on that
Appling my specific advice elsewhere is at most cute, in this case it was
offensive, and I doubt it was only to me.
The `'f{name!id}'` syntax is what *I* prefer, but *I* think that
subclassing typing.LiteralString is less disruptive.
'Esoteric' means something hidden, it is the exact opposite of
> 'Esoteric' means something hidden, it is the exact opposite of 'we all know
> about'
What I meant is that functions in __builtins__ are low level, with
functionality which is hidden from the user. So my point is that it seems like
an appropriate place for nameof(). After all, f’{v!}’ applies
On Mon, 25 Sept 2023 at 07:05, Dom Grigonis wrote:
> What I meant is that functions in __builtins__ are low level, with
> functionality which is hidden from the user.
>
What does that even mean?
ChrisA
___
Python-ideas mailing list -- python-ideas@pyt
What is your position on this?
Do you think that such thing is worth having?
If yes, do any of the 3 final options seem sensible to you?
> On 25 Sep 2023, at 02:39, Chris Angelico wrote:
>
> On Mon, 25 Sept 2023 at 07:05, Dom Grigonis wrote:
>> What I meant is that functions in __builtins__ a
datetime.datetime has microsecond precision, and if you want to reconstruct
a datetime from microseconds since the Unix epoch in a provided timezone,
you can do:
(datetime(1970, 1, 1, tzinfo=timezone.utc) +
timedelta(microseconds=timestamp_us)).astimezone(tz)
This is a general solution, but it co
On Mon, 25 Sept 2023 at 10:05, Dom Grigonis wrote:
>
> What is your position on this?
>
> Do you think that such thing is worth having?
>
> If yes, do any of the 3 final options seem sensible to you?
>
My position is that so far, you haven't shown it to be of much value.
Which might be because th
Can you please stop manufacturing consent?
Em dom., 24 de set. de 2023 às 21:06, Dom Grigonis
escreveu:
> What is your position on this?
>
> Do you think that such thing is worth having?
>
> If yes, do any of the 3 final options seem sensible to you?
>
> > On 25 Sep 2023, at 02:39, Chris Angelic
18 matches
Mail list logo