I like null coalesce too. :)
I know that BDFL has said no to ? Before, but was that for the if-then
shorthand only?
Perhaps submit a new thread to this list so people can discuss/find?
-Joseph
> On Feb 28, 2017, at 10:21 AM, Mark E. Haase wrote:
>
> This could be solved with a null-coalesci
+1
I think this makes a lot of sense. What would you name the built in?
-Joseph
> On Feb 28, 2017, at 7:17 AM, Michel Desmoulin
> wrote:
>
> We have the immutable frozenset for sets and and tuples for lists.
>
> But we also have something to manipulate dict as immutable datastructures:
>
>>
Yes I do think this is precisely where a lazy or delayed feature would work
well. I'm working on writing up a complete PEP now, and have made some progress
on the things left unsolved in the other thread. I will post again when the PEP
is closer to complete.
Fundamentally, anything can be done
behavior is ['a']
I maintain that it would be nice for there to be a way to say (the default
value of this argument is to run some expression *every time*), but
delayed/lazy probably isn't that.
On 19 February 2017 at 13:33, David Mertz wrote:
> On Sun, Feb 19, 2017
Michel-
Thanks for the feedback!
On 19 February 2017 at 11:24, Michel Desmoulin
wrote:
> A great proposal, although now I would have to explain to my students
> the subtle difference between:
>
> res = (print(i * i) for i in range(x))
> print('foo')
> print(res)
>
> And
>
> res = delayed [prin
I'm not married to the colon. Does anyone else see any issue with dropping
it?
On 18 February 2017 at 00:27, David Mertz wrote:
> On Fri, Feb 17, 2017 at 2:35 PM, Joseph Hackman
> wrote:
>
>> I think we should use the colon to make the delayed word (or whatever
Well, yes. I think the 'is' operator is where other attempts fall short,
and why it would require a change to Python. But yes, it would need to
force the promise.
On 17 February 2017 at 21:20, Nathaniel Smith wrote:
> On Thu, Feb 16, 2017 at 9:24 PM, Joseph Hackman
> wrot
On 17 February 2017 at 20:23, Steven D'Aprano wrote:
>
> > I think it would be key, like async/await, to narrowly define the scope
> in
> > which the word delayed functions as a keyword.
>
> The PEP makes it clear that's just a transition phase: they will be
> turned into proper keywords in Pytho
On 17 February 2017 at 18:13, Joshua Morton
wrote:
> @ Joseph
>
> Function annotations can be arbitrary python expressions, it is completely
> legal to have something like
>
> >>> def foo(bar: lambda x: x + 1):
> ... pass
>
> Why you would want that I can't say, but it is legal. In th
On 17 February 2017 at 06:10, Steven D'Aprano wrote:
> On Fri, Feb 17, 2017 at 12:24:53AM -0500, Joseph Hackman wrote:
>
> > I propose a keyword to mark an expression for delayed/lazy execution, for
> > the purposes of standardizing such behavior across the language.
>
I think we should use the colon to make the delayed word (or whatever word
is selected), unambiguously used in this way (and to prevent any existing
code from breaking).
On 17 February 2017 at 17:09, David Mertz wrote:
> That was a problem with the colon that occurred to me. I think it can't be
gt; My earlier proposal (using unpacking syntax) doesn't work for the same
> reason.
>
>> On Fri, Feb 17, 2017 at 2:31 PM, Joseph Hackman
>> wrote:
>> Couldn't the same thing be true of delayed if it is always followed by a
>> colon?
>>
>> I
Couldn't the same thing be true of delayed if it is always followed by a colon?
I.e.
delayed=1
x= delayed: slow_function()
print(delayed) # prints 1
-Joseph
> On Feb 17, 2017, at 2:39 PM, Mark E. Haase wrote:
>
>> On Fri, Feb 17, 2017 at 1:55 PM, Joshua Morton
>> wrote:
>> but I'm wondering
gt;>> b = a + 1
>>
>> That syntax sort-of resembles generator expressions, however; I usually like
>> how python favors actual words over obscure symbol combinations for
>> readability's sake.
>>
>> On Fri, Feb 17, 2017 at 10:57 AM, Abe Dillon wrote:
&
still the thunk, and stuff wouldn't be executed until either
d['a'] or b actually is read from.
-Joseph
> On Feb 17, 2017, at 11:34 AM, Chris Angelico wrote:
>
>> On Sat, Feb 18, 2017 at 3:29 AM, Joseph Hackman
>> wrote:
>> ChrisA: I am not sure about
o wrote:
>
>> On Sat, Feb 18, 2017 at 2:12 AM, Joseph Hackman
>> wrote:
>> As for what triggers execution? I think everything except being on the right
>> side of an assignment. Even identity. So if a delayed expression would
>> evaluate to None, then c
A few points for clarity:
Yes, I would expect each instance of delayed to result in a new delayed
expression, without caching, except for multiple calls to that same delayed
expression instance.
Also, I suggested the colon : because unlike async/await, the following
expression is NOT executed
Howdy All!
This suggestion is inspired by the question on "Efficient debug logging".
I propose a keyword to mark an expression for delayed/lazy execution, for
the purposes of standardizing such behavior across the language.
The proposed format is:
delayed:
i.e. log.info("info is %s", delayed: e
Generally speaking, I'm +1 on this idea, I think it would make code more
readable, especially for tools like IDEs.
I just wanted to ask: can someone point me to the reason Python doesn't support
referencing a class inside it's own definition? It seems like that would solve
some of the cases di
Welp! You're definitely correct. Ah well.
On 28 December 2016 at 18:33, Joseph Hackman
wrote:
> The quick answer is that the MSDN doc indicates support from windows 2000
> onward, with no notes for partial compatability:
> https://msdn.microsoft.com/en-us/library/windows/desktop
ault, but until then I'd prefer it were an opt-in option.
> Paul
>
> On 28 December 2016 at 23:00, Joseph Hackman
> wrote:
> > Hey All!
> >
> > I propose that Windows CPython flip the bit for VT100 support (colors and
> > whatnot) for the stdout/stderr streams
Hey All!
I propose that Windows CPython flip the bit for VT100 support (colors and
whatnot) for the stdout/stderr streams at startup time.
I believe this behavior is worthwhile because ANSI escape codes are
standard across most of Python's install base, and the alternative for
Windows (using ctyp
22 matches
Mail list logo
