> 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
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'...'
>>>
>>>
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
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
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",
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
Consider the following example:
import unittest
def foo():
for x in [1, 2, 'oops', 4]:
print(x + 100)
class TestFoo(unittest.TestCase):
def test_foo(self):
self.assertIs(foo(), None)
if __name__ == '__main__':
unittest.main()
If
> 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 Tue, Aug 27, 2019 at 8:04 PM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Paul Moore writes:
>
> > [S]ubjecting a newcomer to the need to [deal with extra
> > requirements from other participants] right up front isn't exactly
> > fair or helpful.
>
> But avoiding that
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
On Wed, 28 Aug 2019 03:03:00 +0900
"Stephen J. Turnbull" wrote:
> Antoine Pitrou writes:
>
> > Here is a use case where it may remove some pain from users'life:
> > https://bugs.python.org/issue24313
>
> The problem is that a protocol like __json__ doesn't help in
> deserializing, so you
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:
>
Paul Moore writes:
> [S]ubjecting a newcomer to the need to [deal with extra
> requirements from other participants] right up front isn't exactly
> fair or helpful.
But avoiding that is what core-mentorship is for. Perhaps we can
advertise that list better, and maybe more people can mentor
Antoine Pitrou writes:
> Here is a use case where it may remove some pain from users'life:
> https://bugs.python.org/issue24313
The problem is that a protocol like __json__ doesn't help in
deserializing, so you either can't use json.loads(), or more likely
you'll need to have a post-parser to
On Aug 27, 2019, at 10:38, Nick Timkovich wrote:
>
> Currently the datetime docs say:
>
> > An object of type time or datetime may be naive or aware. A datetime object
> > d is aware if d.tzinfo is not None and d.tzinfo.utcoffset(d) does not
> > return None. If d.tzinfo is None, or if
Currently the datetime docs say:
> An object of type time or datetime may be naive or aware. A datetime
object d is aware if d.tzinfo is not None and d.tzinfo.utcoffset(d) does
not return None. If d.tzinfo is None, or if d.tzinfo is not None but
d.tzinfo.utcoffset(d) returns None, d is naive. A
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
> 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
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
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
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
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
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, 27 Aug 2019 10:51:52 +0100
Paul Moore wrote:
>
> For example, the numpy case might be covered completely by the JSON
> module just adding supporting for types that provide an __index__
> method. So rather than needing a new protocol, an existing one might
> be perfectly adequate.
On Tue, 27 Aug 2019 at 10:22, Richard Musil wrote:
>
> On Tue, Aug 27, 2019 at 10:48 AM Antoine Pitrou wrote:
>>
>> On Sun, 11 Aug 2019 20:09:41 -0400
>> David Shawley
>> wrote:
>> > On Aug 8, 2019, at 3:55 PM, Chris Angelico wrote:
>> >
>> > I proposed something similar about a year ago [1].
On Tue, 27 Aug 2019 11:20:58 +0200
Richard Musil wrote:
>
> To resolve the bpo issue with numpy, one would need to implement complete
> custom serialization (1) or simply convert numpy number types into Python
> number types.
Yes, both are possible and both could even be implemented. For Numpy
On Tue, Aug 27, 2019 at 10:48 AM Antoine Pitrou wrote:
> On Sun, 11 Aug 2019 20:09:41 -0400
> David Shawley
> wrote:
> > On Aug 8, 2019, at 3:55 PM, Chris Angelico wrote:
> >
> > I proposed something similar about a year ago [1]. I really like the
> idea
> > of a protocol for this.
On Sun, 11 Aug 2019 20:09:41 -0400
David Shawley
wrote:
> On Aug 8, 2019, at 3:55 PM, Chris Angelico wrote:
>
> >
> > There are two broad suggestions that came out of that thread and
> > others, and I think it may be worth reopening them.
> >
> > 1) Should JSONEncoder (the class underlying
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
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
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
33 matches
Mail list logo
