My vim configuration for a year or two has looked something like this (the
screenshot doesn't show the empty set symbol, but that's part of my conceal
configuration: http://gnosis.cx/bin/.vim/after/syntax/python.vim).
On Sun, Oct 30, 2016 at 7:13 AM, Chris Angelico wrote:
> On Mon, Oct 31, 2016
On Sun, Oct 30, 2016 at 10:16:19AM -0700, David Mertz wrote:
> My vim configuration for a year or two has looked something like this (the
> screenshot doesn't show the empty set symbol, but that's part of my conceal
> configuration: http://gnosis.cx/bin/.vim/after/syntax/python.vim).
Oh nice!
By
On Mon, Oct 31, 2016 at 10:19:58AM +0900, Stephen J. Turnbull wrote:
> Steven D'Aprano writes:
>
> > I see that Perl is leading the way here, supporting a large number of
> > Unicode symbols:
> >
> > https://docs.perl6.org/language/unicode_entry.html
>
> In what sense is that "support"?
Stephen J. Turnbull wrote:
> I gather you think you have a deadlock here. The way to break it is
> to just do it. Pick a syntax and do the rewriting. My memory of some
> past instances is that many of the senior devs (especially Guido) will
> "see through the syntax" to evaluate the benefits of
On 31 October 2016 at 15:51, Mark E. Haase wrote:
> Therefore, I have updated the PEP with the punctuation mentioned above, and
> at this point the PEP can't go any farther. If the best spelling for this
> new operator is unacceptable, then there's no getting around that. This PEP
> should be reje
The PEP combines ideas from several different languages. For example:
* Both Dart and C# have "x ?? y" and "x?.y".
* Dart has "x ??= y" and C# does not.
* C# has short circuit semantics for "?." and Dart does not.
* PHP has "??" but does not have "?."
* Etc.
Wikipedia lists a lot of other languag
I think we should try to improve our intutition about these operators. Many
things that are intuitively clear still require long turgid paragraphs in
reference documentation to state the behavior unambiguously -- but that
doesn't stop us from intuitively grasping concepts like a+b (when does
b.__ra
On 31 October 2016 at 17:16, Guido van Rossum wrote:
> I think we should try to improve our intutition about these operators. Many
> things that are intuitively clear still require long turgid paragraphs in
> reference documentation to state the behavior unambiguously -- but that
> doesn't stop us
On 2016-10-31 17:16, Guido van Rossum wrote:
I think we should try to improve our intutition about these operators.
Many things that are intuitively clear still require long turgid
paragraphs in reference documentation to state the behavior
unambiguously -- but that doesn't stop us from intuitive
On 31 October 2016 at 18:11, MRAB wrote:
> With this feature it could be:
>
> if x in stop_on or end_if?(x):
I don't think "null-aware function call" is in the current version of the PEP.
Paul
___
Python-ideas mailing list
Python-ideas@python.org
ht
On 2016-10-31 19:14, Paul Moore wrote:
On 31 October 2016 at 18:11, MRAB wrote:
> With this feature it could be:
>
> if x in stop_on or end_if?(x):
I don't think "null-aware function call" is in the current version of the PEP.
That might be because it's not clear how useful it would be in p
On Mon, Oct 31, 2016, at 13:16, Guido van Rossum wrote:
> For "everything to the right" it would seem we have some freedom: e.g.
> if we have "foo.bar?.baz(bletch)" is the call included? The answer is
> yes -- the concept we're after here is named "trailer" in the Grammar
> file in the source code
Obviously the AST needs to be changed. How? I dunno. Sounds like you have
some ideas. :-)
On Mon, Oct 31, 2016 at 2:44 PM, Random832 wrote:
> On Mon, Oct 31, 2016, at 13:16, Guido van Rossum wrote:
> > For "everything to the right" it would seem we have some freedom: e.g.
> > if we have "foo.bar
On Fri, Oct 28, 2016 at 7:28 AM, Terry Reedy wrote:
> >>> s = 'kjskljkxcvnalsfjaweirKJZknzsnlkjsvnskjszsdscccjasfdjf'
> >>> s2 = ''.join(c for c in s if c in set('abc'))
>
pretty slick -- but any hope of it being as fast as a C implemented method?
for example, with a 1000 char string:
In [59]:
14 matches
Mail list logo