On 5 October 2016 at 05:09, Ken Kundert wrote:
> On Wed, Oct 05, 2016 at 03:07:42AM +1100, Steven D'Aprano wrote:
>>
>> Extra newlines are cheap. Writing
>>
>
> The cost is paid in newlines *and* extra levels of indentation.
No extra indentation if you ise "if not condition: continue" or
refactor
Ken Kundert writes:
> Why isn't it the programmer that is writing the code the best
> person to decide what is best?
Aside from what Paul said, there's a reason why this proposal is
unlikely to attract support from senior devs.
Python language design and style guides take the position that mos
On Tue, Oct 04, 2016 at 09:09:40PM -0700, Ken Kundert wrote:
> On Wed, Oct 05, 2016 at 03:07:42AM +1100, Steven D'Aprano wrote:
> >
> > Extra newlines are cheap. Writing
> >
>
> The cost is paid in newlines *and* extra levels of indentation.
You've quoted me out of context -- I did also refer t
> On 04 Oct 2016, at 18:15, Guido van Rossum wrote:
>
> On Tue, Oct 4, 2016 at 4:30 AM, Nick Coghlan wrote:
>>class SomeClass(object):
>>def some_sync_method(self):
>>return 42
>>async def some_async_method(self):
>>await asyncio.sleep(3)
>>
Hi all,
A bit of shameless self-promotion but in case anyone interested, a while
ago, I had started to work on a project to improve error message. In case
anyone's interested, you can found everything at:
https://github.com/SylvainDe/DidYouMean-Python . It can be invoked in
different ways, one of
Rene Nejsum writes:
> On 04 Oct 2016, at 18:40, Sven R. Kunze wrote:
> > I don't think that's actually what I wanted here. One simple
> > keyword should have sufficed just like golang did. So, the
> > developer gets a way to decide whether or not he needs it
> > blocking or nonblocking **whe
On 05.10.2016 11:20, Stephen J. Turnbull wrote:
Eg, there's no question in my mind that
for i in range(m):
for j in range (n):
for k in range (p):
m_out(i, k) += m_in1(i, j) * m_in2(j, k)
is easier to read[1] than
for i in range(m) for j in rang
On 5 October 2016 at 14:27, Sven R. Kunze wrote:
> For small scripts this is still useful. Not everybody writes huge programs,
> which needs to adhere to style guides and QA.
Sure. But convenience in small scripts and the REPL typically isn't a
good enough argument to justify a language change. I
On 5 October 2016 at 16:49, Rene Nejsum wrote:
>> On 04 Oct 2016, at 18:40, Sven R. Kunze wrote:
>> I don't think that's actually what I wanted here. One simple keyword should
>> have sufficed just like golang did. So, the developer gets a way to decide
>> whether or not he needs it blocking or
On 5 October 2016 at 23:40, Paul Moore wrote:
> On 5 October 2016 at 14:27, Sven R. Kunze wrote:
>> For small scripts this is still useful. Not everybody writes huge programs,
>> which needs to adhere to style guides and QA.
>
> Sure. But convenience in small scripts and the REPL typically isn't
On 5 October 2016 at 17:26, Nick Coghlan wrote:
> Compared to those, locally modifying the token stream to inject ":
> INDENT" pairs when the if and for keywords are encountered between an
> opening "for" keyword and a closing ":" keyword would be a relatively
> straightforward change that only im
+1
I've definitely seen a lot of new users make this error, an improved
message could go a long way.
On Tue, Oct 4, 2016 at 1:52 PM, Nathan Goldbaum
wrote:
> Hi all,
>
> Recently pypy received a patch that improves the error message one gets
> when 'self' is missing in a method's signature:
>
>
On 5 October 2016 at 18:17, Lisa Roach wrote:
> +1
>
> I've definitely seen a lot of new users make this error, an improved message
> could go a long way.
I'm not a new user by any means, and I still regularly make this
mistake. Because I've got the experience, I recognise the error when I
see it
+∞
Another long-time user here who occasionally still makes this mistake.
Stephan
2016-10-05 19:29 GMT+02:00 Paul Moore :
> On 5 October 2016 at 18:17, Lisa Roach wrote:
> > +1
> >
> > I've definitely seen a lot of new users make this error, an improved
> message
> > could go a long way.
>
> I
On the other hand, await / async is a fantastic interface to unify all
concurrent paradigms and asyncio already provide a bridge with threads
and subprocess. So it kinda make sense.
Le 04/10/2016 à 18:40, Sven R. Kunze a écrit :
On 04.10.2016 13:30, Nick Coghlan wrote:
What it *doesn't* do, a
+1. Python does need better error messages. This and the recent new
import exception will really help.
Will feature freeze prevent this to get into 3.6 if some champion it?
I also really like https://github.com/SylvainDe/DidYouMean-Python and as
a trainer, will use it in my next training sessi
On Thu, Oct 6, 2016 at 5:27 AM, Michel Desmoulin
wrote:
> +1. Python does need better error messages. This and the recent new import
> exception will really help.
>
> Will feature freeze prevent this to get into 3.6 if some champion it?
>
Given that it's not changing semantics at all, just adding
On 2016-10-05 2:50 PM, Nathan Goldbaum wrote:
On Wed, Oct 5, 2016 at 1:27 PM, Michel Desmoulin
wrote:
+1. Python does need better error messages. This and the recent new import
exception will really help.
Will feature freeze prevent this to get into 3.6 if some champion it?
Speaking of, I
On Wed, Oct 5, 2016 at 1:27 PM, Michel Desmoulin
wrote:
> +1. Python does need better error messages. This and the recent new import
> exception will really help.
>
> Will feature freeze prevent this to get into 3.6 if some champion it?
>
Speaking of, I'm not much of a C hacker, and messing with
On 05.10.2016 08:49, Rene Nejsum wrote:
As a result of past discussions, I wrote the module "xfork" which basically does this "golang
goroutine" stuff. It's just a thin wrapper around "futures" but it allows to avoid that what
René and Anthony objects about.
I had a look at xfork, and really
On 5 October 2016 at 20:55, Yury Selivanov wrote:
>
> Speaking of, I'm not much of a C hacker, and messing with CPython internals
>> is a little daunting. If anyone wants to take this on, you have my
>> blessing. I also may take a shot at implementing this idea in the next
>> couple weeks when I
On 05.10.2016 20:23, Michel Desmoulin wrote:
On the other hand, await / async is a fantastic interface to unify all
concurrent paradigms and asyncio already provide a bridge with threads
and subprocess. So it kinda make sense.
Almost if it would not require duplicate pieces of code. But maybe
On 05.10.2016 06:11, Ethan Furman wrote:
On 10/04/2016 09:40 AM, Sven R. Kunze wrote:
As a result of past discussions, I wrote the module "xfork"
which basically does this "golang goroutine" stuff. It's just
a thin wrapper around "futures" but it allows to avoid that
what René and Anthony ob
Isn't it possible to implement it as a pure Python exception hook?
On Wed, Oct 5, 2016 at 10:04 PM Ivan Levkivskyi
wrote:
>
> On 5 October 2016 at 20:55, Yury Selivanov
> wrote:
>
>
> Speaking of, I'm not much of a C hacker, and messing with CPython internals
> is a little daunting. If anyone w
On 05.10.2016 18:06, Nick Coghlan wrote:
[runtime matters]
I think I understand your point.
I also hope that others and me could provide you with our perspective.
We see Python not as a C-like runtime but as an abstract modelling
language. I know that it's different from the point of view of
On 10/05/2016 12:20 PM, Sven R. Kunze wrote:
On 05.10.2016 18:06, Nick Coghlan wrote:
Guido's idea of a shadow thread to let synchronous threads run
coroutines without needing to actually run a foreground event
loop should provide a manageable way of getting the two runtime
models (traditional
> On 05 Oct 2016, at 21:20, Sven R. Kunze wrote:
>
> On 05.10.2016 18:06, Nick Coghlan wrote:
>> [runtime matters]
>
> I think I understand your point.
>
> I also hope that others and me could provide you with our perspective. We see
> Python not as a C-like runtime but as an abstract modelli
On 5 October 2016 at 21:28, Rene Nejsum wrote:
> But, are the runtimes for Python and Erlang that fundamentally different? Is
> it Python’s tight integration with C that is the big difference?
I don't know *that* much about Erlang, but Python's model is that of a
single shared address space with
Paul Moore wrote:
It's also worth noting that the obvious response "but I don't want to
have to run a preprocessor against my code" is another indication that
this isn't solving a significant enough problem to warrant a language
change.
There are valid reasons for disliking preprocessors other
Paul Moore wrote:
I don't know *that* much about Erlang, but Python's model is that of a
single shared address space with (potentially multiple) threads of
code running, having access to that address space.
I don't know much about Erlang either, but from what I
gather, it's a functional languag
On Wed, Oct 05, 2016 at 09:02:50PM +0200, Ivan Levkivskyi wrote:
> I agree with Yury here. There are corner cases (like what to do with
> classmethods etc). If behaviour for all of them are specified, it would be
> quite straightforward to implement this.
I don't know... there's a lot of corner c
On 2016-10-05 7:34 PM, Steven D'Aprano wrote:
On Wed, Oct 05, 2016 at 09:02:50PM +0200, Ivan Levkivskyi wrote:
>I agree with Yury here. There are corner cases (like what to do with
>classmethods etc). If behaviour for all of them are specified, it would be
>quite straightforward to implement
Nick Coghlan writes:
> Python's core runtime model is the C runtime model: threads (with a
> local stack and access to a global process heap) and processes (which
> contain a heap and one or more threads). Anything else we do (whether
> it's generators, coroutines, or some other form of paused
> On 06 Oct 2016, at 07:15, Stephen J. Turnbull
> wrote:
>
> Nick Coghlan writes:
>
>> Python's core runtime model is the C runtime model: threads (with a
>> local stack and access to a global process heap) and processes (which
>> contain a heap and one or more threads). Anything else we do (w
On Wed, Oct 5, 2016 at 1:28 PM, Rene Nejsum wrote:
> When I first read about the async idea, I initially expected that it would be
> some stackless like additions to Python. My wish for Python was an addition
> to the language the allowed an easy an elegant concurrent model on the
> language le
35 matches
Mail list logo
