On 17 August 2014 15:08, Guido van Rossum wrote:
> I think this would be a great topic for a blog post. Once you've written it
> I can even bless it by Tweeting about it. :-)
Sounds like a plan - I'll try to put together something coherent this week :)
> PS. Why isn't PEP 387 accepted yet?
Not
I think this would be a great topic for a blog post. Once you've written it
I can even bless it by Tweeting about it. :-)
PS. Why isn't PEP 387 accepted yet?
On Sat, Aug 16, 2014 at 8:48 PM, Nick Coghlan wrote:
> On 17 August 2014 12:43, Guido van Rossum wrote:
> > On Sat, Aug 16, 2014 at 6:2
On 17 August 2014 12:43, Guido van Rossum wrote:
> On Sat, Aug 16, 2014 at 6:28 PM, Nick Coghlan wrote:
>> I've also had people express the concern that "you broke compatibility
>> in a major way once, how do we know you won't do it again?".
>
>
> Well, they won't, really. You can't predict the f
On Aug 16, 2014, at 7:43 PM, Guido van Rossum wrote:
> But can we really say there won't be a 4.0? Never? Why not? Who is to say
> that at some point some folks won't be going off on their own to design a
> whole new language and name it Python 4, following Larry Wall's Perl 6
> example?
If t
On Aug 16, 2014, at 6:28 PM, Nick Coghlan wrote:
> I've seen a few people on python-ideas express the assumption that
> there will be another Py3k style compatibility break for Python 4.0.
Whenever I mention Python 4 or PEP 4000, it’s always a joke. However, saying
upfront that we will never br
On Sat, Aug 16, 2014 at 6:28 PM, Nick Coghlan wrote:
> I've seen a few people on python-ideas express the assumption that
> there will be another Py3k style compatibility break for Python 4.0.
>
There used to be only joking references to 4.0 or py4k -- how things have
changed! I've seen nothing
On Sun, Aug 17, 2014 at 11:28:48AM +1000, Nick Coghlan wrote:
> I've seen a few people on python-ideas express the assumption that
> there will be another Py3k style compatibility break for Python 4.0.
I used to refer to Python 4000 as the hypothetical compatibility break
version. Now I refer to
I've seen a few people on python-ideas express the assumption that
there will be another Py3k style compatibility break for Python 4.0.
I've also had people express the concern that "you broke compatibility
in a major way once, how do we know you won't do it again?".
Both of those contrast strong
On 17 August 2014 07:42, Chris Angelico wrote:
> On Sat, Aug 16, 2014 at 10:47 PM, Marko Rauhamaa wrote:
>>
>> You might be able to have it bothways. You could have:
>>
>>with (open(name) for name in os.listdir("config")) as files:
>
> But that's not a tuple, it's a generator. Should generato
On Sat, Aug 16, 2014 at 10:47 PM, Marko Rauhamaa wrote:
>
> You might be able to have it bothways. You could have:
>
>with (open(name) for name in os.listdir("config")) as files:
But that's not a tuple, it's a generator. Should generators be context
managers? Is anyone seriously suggesting th
Steven D'Aprano :
> I simply don't care. They will try it, discover that tuples are not
> context managers, fix their code, and move on.
*Could* tuples (and lists and sequences) be context managers?
*Should* tuples (and lists and sequences) be context managers?
> I don't think that some vague
On Sat, Aug 16, 2014 at 05:25:33PM +1000, Ben Finney wrote:
[...]
> > they would have already mistaken:
> >
> > with a, b, c: ...
> >
> > the same way. But they haven't.
>
> Right. The presence or absence of parens make a big semantic difference.
from silly.mistakes.programmers.make import (
I added some extra coverage for basic auth in the tests and I notice that
in buildbots, some of them are throwing "error: [Errno 32] Broken pipe"
error.
I am looking into this and will fix this.
Thanks,
Senthil
On Sat, Aug 16, 2014 at 2:19 PM, senthil.kumaran wrote:
> http://hg.python.org/cp
On Sat, Aug 16, 2014 at 12:25 AM, Ben Finney wrote:
> Steven D'Aprano writes:
>
>> If people were going to be prone to mistake
>>
>> with (a, b, c): ...
>>
>> as including a tuple
>
> … because the parens are a strong signal “this is an expression to be
> evaluated, resulting in a single valu
Steven D'Aprano writes:
> If people were going to be prone to mistake
>
> with (a, b, c): ...
>
> as including a tuple
… because the parens are a strong signal “this is an expression to be
evaluated, resulting in a single value to use in the statement”.
> they would have already mistaken:
>
15 matches
Mail list logo
