On Feb 18, 2017 02:30, "Mikhail V" wrote:
On 18 February 2017 at 04:13, Joao S. O. Bueno
wrote:
> I don't see the point in continuing this thread.
How does this add to the syntax discussion?
I was replying to Nicks quite vague comments
which were supposed to be critics.
There is no point disc
Hi Erik,
I have changed my proposal to the alternative syntax
a:: b
(Note my preferred spacing.
This is to make it read like some annoation applied to the expression,
like
delayed:: expensive_function()+1
)
Since :: is a binary operator, we need to think about
associativity.
My conservative
On Fri, Feb 17, 2017 at 2:46 AM, Stephan Houben wrote:
> Hi Nathaniel,
>
>
> 2017-02-17 11:28 GMT+01:00 Nathaniel Smith :
>>
>> Note that this is definitely a different proposal from the original,
>> since the original proposer's goal was to be able to use this with
>> existing, unmodified functio
2017-02-18 11:55 GMT+01:00 Nathaniel Smith :
>
> This is also potentially a downside, though... the macro-call proposal
> not only handles the cases you're worrying about, but also handles a
> bunch of cases that are basically impossible to handle in Python right
> now. OTOH all the cases where yo
On Fri, Feb 17, 2017 at 9:34 PM, David Mertz wrote:
> On Fri, Feb 17, 2017 at 6:20 PM, Nathaniel Smith wrote:
>>
>> value = delayed: some_dict.get("whatever")
>> if value is None:
>> ...
>>
>> I.e., the question is, how does 'is' work on delayed objects? I guess
>> it has to force the promise
Using "delayed" in function signatures:
On Fri, Feb 17, 2017 at 09:27:35PM -0800, David Mertz wrote:
> That said, I think you are right that it makes no sense to declare a
> function signature with 'delayed' (or 'lazy', 'deferred', whatever word).
It makes perfect sense! That gives us function d
On 2/18/17, Steven D'Aprano wrote:
Sorry Steve that I use your words probably too much out of context!
I just want to reuse your examples to analyze if proposed "delayed
execution" is really necessary. Thanks for them! :)
> print("Start")
> result = delayed: get_nth_prime(10**6) # I dislike th
On 18 February 2017 at 05:43, Steven D'Aprano wrote:
> On Fri, Feb 17, 2017 at 06:31:19PM +0100, Mikhail V wrote:
>
>> I have said I need the index, probably you've misread my last comment.
>> Further more I explained why I think iteration over index should be the
>> preferred way, it help with re
On 18/02/17 19:35, Mikhail V wrote:
You mean what my proposal would bring
technically better than e.g.:
for i,e in enumerate(Seq)
Well, nothing, and I will simply use it,
with only difference it could be:
for i,e over enumerate(Seq)
In this case only space holes will be
smoothed out, so pure
On 2/18/2017 2:25 AM, Steven D'Aprano wrote:
On Fri, Feb 17, 2017 at 11:37:04AM -0500, Mark E. Haase wrote:
Python has two string formatting mini-languages.
Four. % string formatting, .format method, f-strings, string.Template
strings.
But who's counting? :-)
Technical correctness is the b
On 19 February 2017 at 01:01, Erik wrote:
> On 18/02/17 19:35, Mikhail V wrote:
>>
>> You mean what my proposal would bring
>> technically better than e.g.:
>>
>> for i,e in enumerate(Seq)
>>
>> Well, nothing, and I will simply use it,
>> with only difference it could be:
>>
>> for i,e over enumer
Barry Warsaw writes:
> On Feb 16, 2017, at 03:20 PM, M.-A. Lemburg wrote:
>
> >I know some people will disagree, but IMO using "assert" is the wrong
> >approach in such situations - it's meant for development and testing
> >only, not as short-cut to avoid having to write a proper error
> >ha
12 matches
Mail list logo
