On Wed, Aug 28, 2019 at 2:40 PM Andrew Barnert wrote:
> > People can be trusted with powerful features that can introduce
> > complexity. There's just not a lot of point introducing a low-value
> > feature that adds a lot of complexity.
>
> But it really doesn’t add a lot of complexity.
>
> If you
On Wed, 28 Aug 2019 at 05:04, Andrew Barnert via Python-ideas
wrote:
> What matters here is not whether things like the OP’s czt'abc' or my 1.23f or
> 1.23d are literals to the compiler, but whether they’re readable ways to
> enter constant values to the human reader.
>
> If so, they’re useful.
On 27/08/2019 18:07, Andrew Barnert via Python-ideas wrote:
On Aug 27, 2019, at 08:52, Steven D'Aprano wrote:
On Tue, Aug 27, 2019 at 05:24:19AM -0700, Andrew Barnert via Python-ideas wrote:
There is a possibility in between the two extremes of “useless” and
“complete monster”: the prefix acce
On Tue, Aug 27, 2019 at 05:13:41PM -, stpa...@gmail.com wrote:
> The difference between `x'...'` and `x('...')`, other than visual noise, is
> the
> following:
>
> - The first "x" is in its own namespace of string prefixes. The second "x"
> exists in the global namespace of all other symbo
śr., 28 sie 2019 o 13:18 Steven D'Aprano napisał(a):
>
> On Tue, Aug 27, 2019 at 05:13:41PM -, stpa...@gmail.com wrote:
>
> > The difference between `x'...'` and `x('...')`, other than visual noise, is
> > the
> > following:
> >
> > - The first "x" is in its own namespace of string prefixes.
> On 28 Aug 2019, at 14:09, Piotr Duda wrote:
>
> śr., 28 sie 2019 o 13:18 Steven D'Aprano napisał(a):
>>
>>> On Tue, Aug 27, 2019 at 05:13:41PM -, stpa...@gmail.com wrote:
>>>
>>> The difference between `x'...'` and `x('...')`, other than visual noise, is
>>> the
>>> following:
>>>
>>
On 28/08/2019 02:38, stpa...@gmail.com wrote:
Thanks, Andrew, you're able to explain this much better than I do.
Just wanted to add that Python*already* has ways to grossly abuse
its syntax and create unreadable code. For example, I can write
>>> о = 3
>>> o = 5
>>> ο = 6
>>
On Wed, 28 Aug 2019 at 13:15, Anders Hovmöller wrote:
>
> > On 28 Aug 2019, at 14:09, Piotr Duda wrote:
> > There is much simpler solution, just make `abc"whatever"` synatctic
> > sugar for `string_literal_abc(r"whatever", closure)` where closure is
> > object that allow read only access to vari
On Wed, 28 Aug 2019 at 13:49, Rhodri James wrote:
> OK, I'll bite: how? If you were using "thing.o" I would believe you
> were doing something unhelpful with properties, but just "o"?
Presumably Unicode variables with confusable characters?
Paul
___
On Wed, Aug 28, 2019 at 10:50 PM Rhodri James wrote:
>
> On 28/08/2019 02:38, stpa...@gmail.com wrote:
> > Thanks, Andrew, you're able to explain this much better than I do.
> > Just wanted to add that Python*already* has ways to grossly abuse
> > its syntax and create unreadable code. For exampl
On 2019-08-28 01:05, Paul Moore wrote:
However, I know of almost no examples of other languages that have
added*user-definable* literal types (with the notable exception of
Believe there is such a feature in modern JavaScript:
https://developers.google.com/web/updates/2015/01/ES6-Template-S
On Wed, 28 Aug 2019 at 15:55, Mike Miller wrote:
>
>
> On 2019-08-28 01:05, Paul Moore wrote:
> > However, I know of almost no examples of other languages that have
> > added*user-definable* literal types (with the notable exception of
>
> Believe there is such a feature in modern JavaScript:
>
>
On Wed, Aug 28, 2019 at 04:02:26PM +0100, Paul Moore wrote:
On Wed, 28 Aug 2019 at 15:55, Mike Miller wrote:
On 2019-08-28 01:05, Paul Moore wrote:
> However, I know of almost no examples of other languages that have
> added*user-definable* literal types (with the notable exception of
Belie
On Aug 28, 2019, at 00:40, Chris Angelico wrote:
>
> On Wed, Aug 28, 2019 at 2:40 PM Andrew Barnert wrote:
>>> People can be trusted with powerful features that can introduce
>>> complexity. There's just not a lot of point introducing a low-value
>>> feature that adds a lot of complexity.
>>
>>
Usually slices are created with integers such as `foo[1:5]`. However slices are
not restricted to having integers for the `start, stop, step` parameters and
thus can be used with any types. The most prominent example is probably
`pandas` which allows slicing by index (and the index can be `str`
> Ouch! That's adding a lot of additional complexity to the language.
> ...
> This proposal adds a completely separate, parallel set of scoping rules
> for these string prefixes. How many layers in this parallel scope?
Right, having a parallel set of scopes sounds like WAY too much work.
Which i
> In addition, there is the question of how user-defined literals would
> get turned into constants within the code.
So, I'm just brainstorming here, but how about the following
approach:
- Whenever a compiler sees `abc"def"`, it creates a constant of
the type `ud_literal` with fields `.prefix=
Hi Dominik,
There's an existing "typing" issue open for this:
https://github.com/python/typing/issues/159
You may meet more people interested in discussing additions to the typing
module in the typing-sig mailing list.
Finally, be aware that PEP 585 is a draft and not even one that's submitted
f
> A really good example here is the p"C:\" question. Is the
> proposal that the "string part" of the literal is just a normal
> string? If so, then how do you address this genuine issue
> that not all paths are valid? What about backslash-escapes
> (p"C:\temp")? Is the string a raw string or no
> all of which hugely outweighs the gain of being able to avoid a pair
> of parentheses.
Thank you for summarizing the main objections so succinctly,
otherwise it becomes too easy to get lost in the discussion. Let me
try to answer them as best as I can:
> you have something that looks like a
On Aug 27, 2019, at 10:21, Rhodri James wrote:
>
> You make the point yourself: this is something we already understand from
> dealing with complex numbers in other circumstances. That is not true of
> generic single-character string prefixes.
It certainly is true for 1.23f.
And, while 1.23d
On Aug 28, 2019, at 01:05, Paul Moore wrote:
>
> On Wed, 28 Aug 2019 at 05:04, Andrew Barnert via Python-ideas
> wrote:
>> What matters here is not whether things like the OP’s czt'abc' or my 1.23f
>> or 1.23d are literals to the compiler, but whether they’re readable ways to
>> enter constant
Antoine Pitrou writes:
> > And it actually doesn't help as much as you'd hope in
> > serializing, either, not for a decade or so, because most objects
> > won't have a __json__ method.
>
> By the exact same reasoning, you can believe JSON "doesn't help very
> much" because most Python objec
On Aug 28, 2019, at 12:45, stpa...@gmail.com wrote:
>
> In the thread from
> 2013 where this issue was discussed, many people wanted `sql"..."`
> literal to be available as literal and nothing else.
Since this specific use has come up a few times—and a similar feature in other
languages—can you
24 matches
Mail list logo
