Thanks for the reply! Is this really deserving of a PEP? It's such a minor
change in the language, can't it be resolved as a python issue?
Out of curiosity, why have you always resisted changing this?
On Tue, Feb 4, 2020 at 2:08 AM Guido van Rossum wrote:
> I’ve always resisted changing this, b
On 2/4/2020 4:07 AM, Ben Avrahami wrote:
Thanks for the reply! Is this really deserving of a PEP? It's such a
minor change in the language, can't it be resolved as a python issue?
Out of curiosity, why have you always resisted changing this?
PEP-318 references
https://mail.python.org/piperma
I've been doing some work with large ints, of well over 100 digits. For
example, this number has 131 digits:
P =
29674495668685510550154174642905332730771991799853043350995075531276838753171770199594238596428121188033664754218345562493168782883
Sometimes I'm tempted to write numbers like th
On Tue, Feb 4, 2020 at 9:41 PM Steven D'Aprano wrote:
> Or if you don't like backslashes, trailing underscores are currently
> illegal, so we could use them:
>
> P = 29674495668685510550154174642905332730771991_
> 79985304335099507553127683875317177019959423_
> 8596428121188033
On Tue, 4 Feb 2020 at 10:39, Steven D'Aprano wrote:
>
> I've been doing some work with large ints, of well over 100 digits. For
> example, this number has 131 digits:
>
> P =
> 29674495668685510550154174642905332730771991799853043350995075531276838753171770199594238596428121188033664754218345
Yes, it requires a PEP -- note that I am not longer the decider, and none
of the core devs will want to take responsibility for such a change of
heart, so it has to go to the Steering Council. And the easiest way for
that is a PEP.
On Tue, Feb 4, 2020 at 02:04 Eric V. Smith wrote:
> On 2/4/2020
This has struck me as unnecessarily restrictive ever since I first bumped up
against it. I think that the reoccurring threads on this topic, the
availability of awful (and inefficient) hacks to circumvent this restriction,
and the presentation here of a legitimate use case are all solid argument
On 2020-02-04 3:33 a.m., Bruce Leban wrote:
Here is a much more readable alternative which has the advantage that
it is already supported by Python. I'm going to show a harder example
where I want to reference foo.bar and allow both foo and bar to be
refactored. Here's the original proposa
This seems like a pretty uncommon use case.
But are there applications to other contexts where we might want easy line
continuation?
-CHB
On Tue, Feb 4, 2020 at 6:55 AM Paul Moore wrote:
> On Tue, 4 Feb 2020 at 10:39, Steven D'Aprano wrote:
> >
> > I've been doing some work with large ints, o
why not add an identity function to the builtins?
@noop(buttons[0].clicked.connect)
def foo():
... # do whatever
On 2020-02-03 9:08 p.m., Guido van Rossum wrote:
I’ve always resisted changing this, but it keeps coming up, and in
other cases we don’t restrict the grammar (except when there are
> A statement like print("bar", foo.bar) would be very hard to notice that
> the "bar" match the foo.bar, while
>
> print(nameof(foo.bar), foo.bar) makes the connection explicit.
Isn’t someone working on a “debug string” PEP that would mitigate this?
Maybe not a full PEP:
https://bugs.python.o
On 2020-02-04 02:37, Steven D'Aprano wrote:
Sometimes I'm tempted to write numbers like that as follows:
P = int('29674495668685510550154174642905332730771991'
'79985304335099507553127683875317177019959423'
'8596428121188033664754218345562493168782883')
which is
On Wed, Feb 5, 2020 at 5:14 AM Christopher Barker wrote:
>
> > A statement like print("bar", foo.bar) would be very hard to notice that
>>
>> the "bar" match the foo.bar, while
>>
>> print(nameof(foo.bar), foo.bar) makes the connection explicit.
>
>
> Isn’t someone working on a “debug string” PEP
On 2020-02-03 03:55, Soni L. wrote:
On 2020-02-02 11:29 p.m., Eric V. Smith wrote:
On 2/2/2020 8:28 PM, Soni L. wrote:
It'd be cool to attach metadata to string literals that doesn't end up in the
resulting string object. This metadata could be used by all sorts of tools,
everything from lo
I'll sponsor.
On Tue, Feb 4, 2020 at 9:43 AM Brandt Bucher wrote:
> This has struck me as unnecessarily restrictive ever since I first bumped
> up against it. I think that the reoccurring threads on this topic, the
> availability of awful (and inefficient) hacks to circumvent this
> restriction,
[Paul Moore ]
> ...
> Can you share a bit more about why you need to do this? In the
> abstract, having the ability to split numbers over lines seems
> harmless and occasionally useful, but conversely it's not at all
> obvious why anyone would be doing this in real life.
It's not all that uncommon
> On 3 Feb 2020, at 01:28, Soni L. wrote:
>
> It'd be cool to attach metadata to string literals that doesn't end up in the
> resulting string object. This metadata could be used by all sorts of tools,
> everything from localization to refactoring.
>
> In C, some localization libraries use m
Great! I'll begin work on this soon and reach out to you when I have something.
Thanks, Ben, for bringing this up.
___
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.
Thanks Tim, this is the sort of thing that I do like to dabble in, so
the background information is really interesting.
But as I say, I'd view it the same way as you. I'd copy/paste it in,
leave the long line as it is and add a comment saying where I got it
from. So I'm pretty neutral on the propo
Thanks everyone for your comments. Replying to everyone (so far) at
once.
Chris Angelico:
I would be okay with your suggestion that line-breaking the int requires
parentheses:
a = 123_ # remains a SyntaxError
b = (123_
456) # legal
but I don't know how easy that is for th
Why not just build the number using some kind of fancy "continuing integer"
constructor function? Then you could just use commas, Blacken the code, and
it will look great, right?
P = my_int_maker(29674495668685510550154174642905332730771991,
79985304335099507553127683875317177019959423,
that's not such a good idea if you can't specify base.
On 2020-02-04 8:17 p.m., Ricky Teachey wrote:
Why not just build the number using some kind of fancy "continuing
integer" constructor function? Then you could just use commas, Blacken
the code, and it will look great, right?
P = my_int_ma
On Tue, Feb 4, 2020 at 3:21 PM Ricky Teachey wrote:
> Why not just build the number using some kind of fancy "continuing
> integer" constructor function? Then you could just use commas, Blacken the
> code, and it will look great, right?
>
> P = my_int_maker(296744956686855105501541746429053327307
>
> (Rhetorical question:) How could my_int_maker(1, 00, 23) return 10023?
>
Sorry I haven't been on the list long: does "rhetorical question" mean the
same thing to the Dutch as to Americans? ;)
___
Python-ideas mailing list -- [email protected]
T
On Wed, Feb 5, 2020 at 10:30 AM Ricky Teachey wrote:
>>
>> (Rhetorical question:) How could my_int_maker(1, 00, 23) return 10023?
>
>
> Sorry I haven't been on the list long: does "rhetorical question" mean the
> same thing to the Dutch as to Americans? ;)
>
Not sure about Dutch and American usa
Maybe I meant "Socratic question." I was hoping you would realize there's
no way (short of parsing the source code) to know how many zeros were
entered as the second argument, hence that the proposal has a flaw.
On Tue, Feb 4, 2020 at 3:28 PM Ricky Teachey wrote:
> (Rhetorical question:) How cou
On Tue, Feb 4, 2020, 6:35 PM Guido van Rossum wrote:
> Maybe I meant "Socratic question." I was hoping you would realize there's
> no way (short of parsing the source code) to know how many zeros were
> entered as the second argument, hence that the proposal has a flaw.
>
I don't deserve your ki
On 2/4/2020 6:17 PM, Ricky Teachey wrote:
Why not just build the number using some kind of fancy "continuing
integer" constructor function? Then you could just use commas, Blacken
the code, and it will look great, right?
P = my_int_maker(29674495668685510550154174642905332730771991,
79
On Tue, Feb 4, 2020 at 3:29 AM Chris Angelico wrote:
>
> Another one to throw into the mix: Trailing underscores, but only if
> the expression is incomplete. So in simple cases like this, that means
> parenthesizing the number:
>
> P = (29674495668685510550154174642905332730771991_
> 7998
29 matches
Mail list logo
