[ideas to bcc]
I'm not as excited about this as I am about the PEP 8 change.
PEP 8 affects most Python programmers.
But PEP 7 is really just for CPython and its extensions, and I don't think
it has found anything like as widespread a following as PEP 8.
I worry that if we change this in PEP 7 w
On Tue, Apr 19, 2016 at 5:33 AM, Joseph Jevnik wrote:
> I saw that there was recently a change to pep 8 to suggest adding a line
> break before a binary operator. Pep 7 suggests the opposite:
>
>> When you break a long expression at a binary operator, the operator goes
>> at the end of the previou
On Jan 11, 2016, at 03:25 PM, anatoly techtonik wrote:
>On Wed, Jan 6, 2016 at 2:49 AM, Barry Warsaw wrote:
>
>> reStructuredText is clearly a better format
>
>Can you expand on that? I use markdown everywhere
reST is better than plain text. Markdown is not a PEP format option.
>> all recent P
On Thu, Nov 20, 2014 at 3:45 AM, Nick Coghlan wrote:
> The part I found most compelling was when you pointed out that in the
> special method implementations, the normal return path was always spelled
> with "return", while the "value missing" result was indicated with a special
> kind of exceptio
On Wed, Jan 9, 2013 at 12:14 AM, Guido van Rossum wrote:
> But which half? A socket is two independent streams, one in each
> direction. Twisted uses half_close() for this concept but unless you
> already know what this is for you are left wondering which half. Which
> is why I like using 'write'
Well, if we're at the "bikeshedding about names" stage, that means that no
serious issues with the proposal are left. So it's a sign of progress.
On Wed, Jan 9, 2013 at 12:42 AM, Stephen J. Turnbull wrote:
> Is this thread really ready to migrate to python-dev when we're still
> bikeshedding met
On Wed, Jan 9, 2013 at 8:55 PM, Yuriy Taraday wrote:
> My interns told me that they remember EOF as special object only from high
> school when they had to study Pascal. I guess, in 5 years students won't
> understand how one can write an EOF. (and schools will finally replace
> Pascal with Python
Is this thread really ready to migrate to python-dev when we're still
bikeshedding method names?
Yuriy Taraday writes:
> > But which half? A socket is two independent streams, one in each
> > direction. Twisted uses half_close() for this concept but unless you
> > already know what this is for
As the maintainer of a pretty large, complex app written in Twisted, I
think this is great. I look forward to a future of being able to select
from a broad library of async tools, and being able to write tools that can
be used outside of Twisted.
Buildbot began, lo these many years ago, doing
On Fri, Jan 4, 2013 at 2:38 PM, Dustin Mitchell wrote:
> As the maintainer of a pretty large, complex app written in Twisted, I think
> this is great. I look forward to a future of being able to select from a
> broad library of async tools, and being able to write tools that can be used
> outside
On Fri, Dec 21, 2012 at 8:02 PM, Guido van Rossum wrote:
... snip ...
In PEP 3156 conformant code you're supposed always to use 'yield
> from'. The only time you see a bare yield is when it's part of the
> implementation's internals. (However I think tulip actually will
> handle a yield the same
On Fri, Dec 21, 2012 at 5:17 PM, Jasper St. Pierre
wrote:
> On Fri, Dec 21, 2012 at 8:02 PM, Guido van Rossum wrote:
>
> ... snip ...
>
>> In PEP 3156 conformant code you're supposed always to use 'yield
>> from'. The only time you see a bare yield is when it's part of the
>> implementation's int
On Fri, Dec 21, 2012 at 2:26 PM, Jonathan Slenders wrote:
> As far as I understand, "yield from" will always work, because a Future
> object can act like an iterator, and you can delegate your own generator to
> this iterator at the place of "yield from".
> "yield" only works if the parameter behi
On Fri, Dec 21, 2012 at 1:04 PM, Laurens Van Houtven <_...@lvh.cc> wrote:
> Looks reasonable to me :) Comments:
>
> create_transport "combines" a transport and a protocol. Is that process
> reversible? that might seem like an exotic thing (and I guess it kind of
> is), but I've wanted this e.g for
As far as I understand, "yield from" will always work, because a Future
object can act like an iterator, and you can delegate your own generator to
this iterator at the place of "yield from".
"yield" only works if the parameter behind yield is already a Future
object. Right Guido?
In case of sleep
Looks reasonable to me :) Comments:
create_transport "combines" a transport and a protocol. Is that process
reversible? that might seem like an exotic thing (and I guess it kind of
is), but I've wanted this e.g for websockets, and I guess there's a few
other cases where it could be useful :)
eof_
On 2012-03-08, at 22:08 , Mark Janssen wrote:
> I just noticed something in Guido's example. Something gives me a strange
> feeling that using a variable as a key doesn't smell right. Presumably
> Python just hashes the variable's id, or uses the id itself as the key
Python calls ``hash`` on the
Le 08/10/2011 17:14, Victor Stinner a écrit :
Le 08/10/2011 15:03, Antoine Pitrou a écrit :
On Fri, 07 Oct 2011 21:14:44 -0600
Jeffrey wrote:
I would like to suggest adding an integer presentation type for base 36
to PEP 3101. I can't imagine that it would be a whole lot more
difficult than the
On Sat, 08 Oct 2011 17:14:55 +0200
Victor Stinner wrote:
> Le 08/10/2011 15:03, Antoine Pitrou a écrit :
> > On Fri, 07 Oct 2011 21:14:44 -0600
> > Jeffrey wrote:
> >> I would like to suggest adding an integer presentation type for base 36
> >> to PEP 3101. I can't imagine that it would be a wh
Le 08/10/2011 15:03, Antoine Pitrou a écrit :
On Fri, 07 Oct 2011 21:14:44 -0600
Jeffrey wrote:
I would like to suggest adding an integer presentation type for base 36
to PEP 3101. I can't imagine that it would be a whole lot more
difficult than the existing types. Python's built-in long inte
20 matches
Mail list logo
