On Sep 3, 2019, at 06:17, Rhodri James wrote:
>
>> On 03/09/2019 13:31, Chris Angelico wrote:
>>> On Tue, Sep 3, 2019 at 10:27 PM Rhodri James wrote:
>>>
On 31/08/2019 12:31, Chris Angelico wrote:
We call it a string, but a bytes object has as much in common with
bytearray and wi
On Wed, Sep 4, 2019 at 12:43 AM Rhodri James wrote:
>
> On 03/09/2019 15:27, Chris Angelico wrote:
> > On Tue, Sep 3, 2019 at 11:19 PM Rhodri James wrote:
> >>
> >> On 03/09/2019 13:31, Chris Angelico wrote:
> >>> On Tue, Sep 3, 2019 at 10:27 PM Rhodri James wrote:
>
> On 31/08/2019 12
On 03/09/2019 15:27, Chris Angelico wrote:
On Tue, Sep 3, 2019 at 11:19 PM Rhodri James wrote:
On 03/09/2019 13:31, Chris Angelico wrote:
On Tue, Sep 3, 2019 at 10:27 PM Rhodri James wrote:
On 31/08/2019 12:31, Chris Angelico wrote:
We call it a string, but a bytes object has as much in c
On Tue, Sep 3, 2019 at 11:19 PM Rhodri James wrote:
>
> On 03/09/2019 13:31, Chris Angelico wrote:
> > On Tue, Sep 3, 2019 at 10:27 PM Rhodri James wrote:
> >>
> >> On 31/08/2019 12:31, Chris Angelico wrote:
> >>> We call it a string, but a bytes object has as much in common with
> >>> bytearray
On 03/09/2019 13:31, Chris Angelico wrote:
On Tue, Sep 3, 2019 at 10:27 PM Rhodri James wrote:
On 31/08/2019 12:31, Chris Angelico wrote:
We call it a string, but a bytes object has as much in common with
bytearray and with a list of integers as it does with a text string.
You say that as i
On Tue, Sep 3, 2019 at 10:27 PM Rhodri James wrote:
>
> On 31/08/2019 12:31, Chris Angelico wrote:
> > We call it a string, but a bytes object has as much in common with
> > bytearray and with a list of integers as it does with a text string.
>
> You say that as if text strings aren't sequences of
On 31/08/2019 12:31, Chris Angelico wrote:
We call it a string, but a bytes object has as much in common with
bytearray and with a list of integers as it does with a text string.
You say that as if text strings aren't sequences of bytes. Complicated
and restricted sequences, I grant you, but
On Mon, Sep 2, 2019 at 9:56 PM Steven D'Aprano wrote:
>
> On Sun, Sep 01, 2019 at 12:24:24PM +1000, Chris Angelico wrote:
>
> > Older versions of Python had text and bytes be the same things.
>
> Whether a string object is *text* is a semantic question, and
> independent of what data format you us
On Sun, Sep 01, 2019 at 12:24:24PM +1000, Chris Angelico wrote:
> Older versions of Python had text and bytes be the same things.
Whether a string object is *text* is a semantic question, and
independent of what data format you use. 'Hello world!' is text, whether
you are using Python 1.5 or Py
On Mon, 2 Sep 2019 at 07:04, Pasha Stetsenko wrote:
> > Don't say that this proposal won't be abused. Every one of the OP's
> > motivating examples is an abuse of the syntax, returning non-strings
> > from something that looks like a string.
>
> If you strongly believe that if something looks lik
> Don't say that this proposal won't be abused. Every one of the OP's
> motivating examples is an abuse of the syntax, returning non-strings
> from something that looks like a string.
If you strongly believe that if something looks like a string it ought to quack
like a string too, then we can
On Sun, Sep 1, 2019 at 10:47 AM Steven D'Aprano wrote:
>
> On Sat, Aug 31, 2019 at 09:31:15PM +1000, Chris Angelico wrote:
> > On Sat, Aug 31, 2019 at 8:44 PM Steven D'Aprano wrote:
> > > > So b"abc" should not be allowed?
> > >
> > > In what way are byte-STRINGS not strings? Unicode-strings and
On Thu, Aug 29, 2019 at 11:19:58PM +0100, Rob Cliffe via Python-ideas wrote:
> Just curious: Is there any reason not to make decimal.Decimal a
> built-in type?
Yes: it is big and complex, with a big complex API that is over-kill for
the major motivating use-case for a built-in decimal type.
T
On Sat, Aug 31, 2019 at 09:31:15PM +1000, Chris Angelico wrote:
> On Sat, Aug 31, 2019 at 8:44 PM Steven D'Aprano wrote:
> > > So b"abc" should not be allowed?
> >
> > In what way are byte-STRINGS not strings? Unicode-strings and
> > byte-strings share a significant fraction of their APIs, and are
On Sat, Aug 31, 2019 at 8:44 PM Steven D'Aprano wrote:
> > So b"abc" should not be allowed?
>
> In what way are byte-STRINGS not strings? Unicode-strings and
> byte-strings share a significant fraction of their APIs, and are so
> similar that back in Python 2.2 the devs thought it was a good idea
On Thu, Aug 29, 2019 at 02:10:21PM -0700, Andrew Barnert wrote:
[...]
> And most of the string affixes people have suggested are for
> string-ish things.
I don't think that's correct. Looking back at the original post in this
thread, here are the motivating examples:
[quote]
There are quite a
On Thu, 29 Aug 2019 at 22:12, Andrew Barnert via Python-ideas
wrote:
> As I’ve said before, I believe that anything that doesn’t have a builtin type
> does not deserve builtin syntax. And I don’t understand why that isn’t a
> near-ubiquitous viewpoint. But it’s not just you; at least three peopl
On Aug 29, 2019, at 16:58, Greg Ewing wrote:
>
> Steven D'Aprano wrote:
>> I don't think that stpa...@gmail.com means that the user literally assigns
>> to locals() themselves. I read his proposal as having the compiler
>> automatical mangle the names in some way, similar to name mangling insid
Steven D'Aprano wrote:
I don't think that stpa...@gmail.com means that the user literally
assigns to locals() themselves. I read his proposal as having the
compiler automatical mangle the names in some way, similar to name
mangling inside classes.
Yes, but at some point you have to define a f
Rhodri James wrote:
Suppose that we did have some funky mechanism to get the compiler to
create objects at compile time
It doesn't necessarily have to be at compile time. It can be at run
time, as long as it only happens once.
So we use "start_date" somewhere, and mutate it because the start d
One way to handle this particular case would be to do it as a variant
of f-string that doesn't join its arguments, but passes the list to
some other function. Just replace the final step BUILD_STRING step
with BUILD_LIST, then call the function. There'd need to be some way
to recognize which se
On 29/08/2019 22:10:21, Andrew Barnert via Python-ideas wrote:
As I’ve said before, I believe that anything that doesn’t have a builtin type
does not deserve builtin syntax. And I don’t understand why that isn’t a
near-ubiquitous viewpoint.
+1 (maybe that means I'm missing something).
Just cu
On Aug 29, 2019, at 07:52, Steven D'Aprano wrote:
>
>> On Thu, Aug 29, 2019 at 05:30:39AM -0700, Andrew Barnert wrote:
>>> On Aug 29, 2019, at 04:58, Steven D'Aprano wrote:
>>>
>>> - quote marks are also used for function calls, but only a limited
>>> subset of function calls (those which take
> On Aug 29, 2019, at 06:40, Rhodri James wrote:
>
> However, it sounds like what you really want is something I've often really
> wanted to -- a way to get the compiler to pre-create "constant" objects for
> me.
People often say they want this, but does anyone actually ever have a good
reaso
> There's no such thing, though, any more than there's such a thing as a
> "raw string". There are only two types of string in Python - text and
> bytes. You can't behave differently based on whether you were given a
> triple-quoted, raw, or other string literal.
A simple implementation could be s
On 8/29/19 11:14 AM, Chris Angelico wrote:
> On Fri, Aug 30, 2019 at 3:51 AM Pasha Stetsenko wrote:
>> My understanding is that for a sql prefix the most valuable part is to be
>> able
>> to know that it was created from a literal. No other magic, definitely not
>> auto-executing. Then it would b
On Fri, Aug 30, 2019 at 3:51 AM Pasha Stetsenko wrote:
>
> My understanding is that for a sql prefix the most valuable part is to be able
> to know that it was created from a literal. No other magic, definitely not
> auto-executing. Then it would be legal to write
>
> result = conn.execute(sql
> How does one get a value into locals()["re~"]?
You're right, I didn't think about that. I agree with Steven's
interpretation that the user is not expected to modify locals
herself, still the immutable nature of locals presents a
considerable challenge.
So I'm thinking that perhaps we could chan
My understanding is that for a sql prefix the most valuable part is to be able
to know that it was created from a literal. No other magic, definitely not
auto-executing. Then it would be legal to write
result = conn.execute(sql"SELECT * FROM people WHERE id=?",
user_
My understanding is that for a sql prefix the most valuable part is to be able
to know that it was created from a literal. No other magic, definitely not
auto-executing. Then it would be legal to write
result = conn.execute(sql"SELECT * FROM people WHERE id=?",
user_
On 8/26/19 4:03 PM, stpa...@gmail.com wrote:
> In Python strings are allowed to have a number of special prefixes:
>
> b'', r'', u'', f''
> + their combinations.
>
> The proposal is to allow arbitrary (or letter-only) user-defined prefixes as
> well.
> Essentially, a string prefix would s
On Thu, 29 Aug 2019 at 15:54, Steven D'Aprano wrote:
> Let me suggest some design principles that should hold for languages
> with more-or-less "conventional" syntax. Languages like APL or Forth
> excluded.
This will degenerate into nitpicking very fast, so let me just say
that I understand the
On Thu, Aug 29, 2019 at 05:30:39AM -0700, Andrew Barnert wrote:
> On Aug 29, 2019, at 04:58, Steven D'Aprano wrote:
> >
> > - quote marks are also used for function calls, but only a limited
> > subset of function calls (those which take a single string literal
> > argument).
>
> This is a dis
On 29/08/2019 14:40, Rhodri James wrote:
Pace Stephen's point
My apologies, it was Steven's point.
--
Rhodri James *-* Kynesim Ltd
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
On Thu, Aug 29, 2019 at 08:17:39PM +1200, Greg Ewing wrote:
> stpa...@gmail.com wrote:
>
> >re'a|b|c' --becomes--> (locals()["re~"])("a|b|c")
> >2.3f --becomes--> (locals()["~f"])("2.3")
>
> How does one get a value into locals()["re~"]?
I don't think that stpa...@gmail.com mean
On Thu, Aug 29, 2019 at 09:58:35PM +1000, Steven D'Aprano wrote:
> Since Python is limited to ASCII syntax, we only have a small number of
> symbols suitable for delimiters. With such a small number available,
Oops, I had an interrupted thought there.
With such a small number available, there
On 29/08/2019 00:24, Andrew Barnert wrote:
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 certain
On Thu, 29 Aug 2019 at 14:21, Andrew Barnert wrote:
> You can’t avoid tradeoffs by trying to come up with a rule that makes
> language decisions automatically. (If you could, why would this list even
> exist?) The closest thing you can get to that is the vague and
> self-contradictory and facet
On 28/08/2019 23:01, stpa...@gmail.com wrote:
you have something that looks like a kind of string czt'...'
but is really a function call that might return absolutely
anything at all;
This is kinda the whole point. I understand, of course, how the
idea of a string-that-is-not-a-string may sound
On Aug 29, 2019, at 00:58, Paul Moore wrote:
>
> If you
> assume everything should be handled by general mechanisms, you end up
> at the Lisp/Haskell end of the spectrum. If you decide that the
> language defines the limits, you are at the C end.
And if you don’t make either assumption, but inst
On Aug 29, 2019, at 04:58, Steven D'Aprano wrote:
>
> - quote marks are also used for function calls, but only a limited
> subset of function calls (those which take a single string literal
> argument).
This is a disingenuous argument.
When you read spam.eggs, of course you know that that mea
On Wed, Aug 28, 2019 at 10:01:25PM -, stpa...@gmail.com wrote:
> > you have something that looks like a kind of string czt'...'
> > but is really a function call that might return absolutely
> > anything at all;
>
> This is kinda the whole point.
Yes, I understand that. And that's one of t
stpa...@gmail.com wrote:
re'a|b|c' --becomes--> (locals()["re~"])("a|b|c")
2.3f --becomes--> (locals()["~f"])("2.3")
How does one get a value into locals()["re~"]?
--
Greg
___
Python-ideas mailing list -- python-ideas@python.org
To
On Thu, 29 Aug 2019 at 01:18, Andrew Barnert wrote:
> > Also, it's worth noting that the benefits of *user-defined* literals
> > are *not* the same as the benefits of things like 0.2f, or 3.14d, or
> > even re/^hello.*/. Those things may well be useful. But the benefit
> > you gain from *user-defi
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
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
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
> 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
> 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
> 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=
> 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
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.
>>
>>
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 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 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, 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 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, 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 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 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:
>>>
>>
ś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 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
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 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 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 Aug 27, 2019, at 18:19, Chris Angelico wrote:
>
>>> On Wed, Aug 28, 2019 at 10:52 AM Andrew Barnert wrote:
>>>
>>> On Aug 27, 2019, at 14:41, Chris Angelico wrote:
>>> All the examples about Windows paths fall into one of two problematic boxes:
>>>
>>> 1) Proposals that allow an arbitrar
On Aug 27, 2019, at 18:59, Steven D'Aprano wrote:
>
> On Tue, Aug 27, 2019 at 10:07:41AM -0700, Andrew Barnert wrote:
>
>>> How is that different from passing a string argument to a function or
>>> class constructor that can parse that token however it wants?
>>>
>>> x'...'
>>>
>>> x('...
On Tue, Aug 27, 2019 at 10:07:41AM -0700, Andrew Barnert wrote:
> > How is that different from passing a string argument to a function or
> > class constructor that can parse that token however it wants?
> >
> >x'...'
> >
> >x('...')
> >
> > Unless there is some significant difference
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
>>> (о, o, ο)
(3, 5, 6)
But just because some fea
On Wed, Aug 28, 2019 at 10:52 AM Andrew Barnert wrote:
>
> On Aug 27, 2019, at 14:41, Chris Angelico wrote:
> > All the examples about Windows paths fall into one of two problematic boxes:
> >
> > 1) Proposals that allow an arbitrary prefix to redefine the entire
> > parser - basically impossible
On Aug 27, 2019, at 14:41, Chris Angelico wrote:
>
>> On Wed, Aug 28, 2019 at 6:03 AM Andrew Barnert wrote:
>>
>>> On Tuesday, August 27, 2019, 11:12:51 AM PDT, Chris Angelico
>>> wrote:
>>> If your conclusion here were "and that's why Python needs a proper
>>> syntax for Decimal literals", t
On Wed, Aug 28, 2019 at 6:03 AM Andrew Barnert wrote:
>
> On Tuesday, August 27, 2019, 11:12:51 AM PDT, Chris Angelico
> wrote:
> > If your conclusion here were "and that's why Python needs a proper
> > syntax for Decimal literals", then I would be inclined to agree with
> > you - a Decimal lite
> But you haven't made the case for generic string prefixes or any sort
> of "arbitrary literal" that would let you import something that
> registers something to make your float32 literals.
The case can be made as follows: different people use different parts
of the Python language. Andrew would
On Tuesday, August 27, 2019, 11:12:51 AM PDT, Chris Angelico
wrote:
>On Wed, Aug 28, 2019 at 3:10 AM Andrew Barnert via Python-ideas
> wrote:
>> Before I get into this, let me ask you a question. What does the j suffix
>> give us? You can write complex numbers without it just fine:
>>
>>
On Tuesday, August 27, 2019, 11:42:23 AM PDT, Serhiy Storchaka
wrote:
> 27.08.19 20:07, Andrew Barnert via Python-ideas пише:
>> Before I get into this, let me ask you a question. What does the j suffix
>> give us? You can write complex numbers without it just fine:
>>
>> c = complex
>
27.08.19 20:07, Andrew Barnert via Python-ideas пише:
Before I get into this, let me ask you a question. What does the j suffix give
us? You can write complex numbers without it just fine:
c = complex
c(1, 2)
And you can even write a j function trivially:
def j(x): return compl
On Wed, Aug 28, 2019 at 3:10 AM Andrew Barnert via Python-ideas
wrote:
> Before I get into this, let me ask you a question. What does the j suffix
> give us? You can write complex numbers without it just fine:
>
> c = complex
> c(1, 2)
>
> And you can even write a j function trivially:
>
On Aug 27, 2019, at 08:36, Steven D'Aprano wrote:
>
> I don't wish to say that parsing strings to extract information is
> always an anti-pattern:
>
> http://cyrille.martraire.com/2010/01/the-string-obsession-anti-pattern/
>
> after all we often need to process data coming from config files or
> Unless there is some significant difference between the two, what does
> this proposal give us?
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
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 accepts exactly one token, but can
>> parse th
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 accepts exactly one token, but can
> parse that token however it wants.
How is that different from passing a st
On Tue, Aug 27, 2019 at 08:22:22AM -, stpa...@gmail.com wrote:
> The string (or number) prefixes add new power to the language
I don't think they do. It's just syntactic sugar for a function call.
There's nothing that czt'...' will do that czt('...') can't already do.
If you have a proposal
On Aug 27, 2019, at 01:42, Chris Angelico wrote:
>
> Will these "custom
> prefixes" be able to define anything syntactically? If not, why not
> just use a function call? And if they can, then you have created an
> absolute monster, where a v-string in one context can have completely
> different s
On Aug 26, 2019, at 23:43, Serhiy Storchaka wrote:
>
> 27.08.19 06:38, Andrew Barnert via Python-ideas пише:
>> * JSON (register the stdlib or simplejson or ujson),
>
> What if the JSON suffix for?
I think you’d mainly want it in combination with percent-, html-, or
uu-equals-decoding, which
On Tue, Aug 27, 2019 at 6:25 PM wrote:
> You're correct that, devoid of context, `v"smth..."` is not very meaningful.
> The
> "v" suffix could mean "version", or "verbose", or "volatile", or "vectorized",
> or "velociraptor", or whatever. Luckily, the code is almost always exists
> within a speci
Thank you, Steven, for taking the time to write such an elaborate rebuttal.
If I understand the heart of your argument correctly, you're concerned that
the prefixed strings may add confusion to the code. That nobody knows
what `l'abc'` or `czt'xxx'` could possibly mean, while at the same time
`v'1.
27.08.19 06:38, Andrew Barnert via Python-ideas пише:
* JSON (register the stdlib or simplejson or ujson),
What if the JSON suffix for? JSON is virtually a subset of Python except
that that it uses true, false and null instead of True, False and None.
If you set these three variables you ca
> On Aug 26, 2019, at 18:41, stpa...@gmail.com wrote:
>
> Thanks, Andrew, for your feedback. I didn't even think about string
> **suffixes**, but
> clearly they can be implemented together with the prefixes for additional
> flexibility.
What about _instead of_ rather than _together with_? Half
On Mon, Aug 26, 2019 at 11:03:38PM -, stpa...@gmail.com wrote:
> In Python strings are allowed to have a number of special prefixes:
>
> b'', r'', u'', f''
> + their combinations.
>
> The proposal is to allow arbitrary (or letter-only) user-defined prefixes as
> well.
> Essentially,
Thanks, Andrew, for your feedback. I didn't even think about string
**suffixes**, but
clearly they can be implemented together with the prefixes for additional
flexibility.
And your idea that ` ` is conceptually no different than
` ` is absolutely insightful.
Speaking of string suffixes, flags o
On 2019-08-27 00:03, stpa...@gmail.com wrote:
In Python strings are allowed to have a number of special prefixes:
b'', r'', u'', f''
+ their combinations.
The proposal is to allow arbitrary (or letter-only) user-defined prefixes as
well.
Essentially, a string prefix would serve as a
On Aug 26, 2019, at 16:03, stpa...@gmail.com wrote:
>
> In Python strings are allowed to have a number of special prefixes:
>
>b'', r'', u'', f''
>+ their combinations.
>
> The proposal is to allow arbitrary (or letter-only) user-defined prefixes as
> well.
> Essentially, a string pref
On Another Subject, we could also have a language change staying that those
two lines are equivalent :
something"hello"
something("hello")
So that, any callable in the context can be used as a prefix ?
On Tue, Aug 27, 2019, 01:11 wrote:
> In Python strings are allowed to have a number of speci
93 matches
Mail list logo
