> I think this method is easy to miss, since people look at the docs for bytes
> (e.g. using dir(bytes)). It might be worthwhile to either add a
> `bytes.to_int(...)` method (better, IMHO), or to point to int.from_bytes on
> the relevant part of the docs.
>
> Elazar
A note in the docs about int.fr
Hi all,
I've been following the discussion of assignment expressions and what the
syntax for them should be for awhile. The ones that seem to crop up most
are the original spelling, :=, the "as" keyword (and variants including
it), and the recently "local" pseudo-function idea.
I have another ide
On Wed, 02 May 2018 05:08:41 +1000, Steven D'Aprano wrote:
> The difference was that when Windows users used the mouse, even though
> they were *objectively* faster to complete the task compared to using
> the arrow keys, subjectively they swore that they were slower, and
> were *very confident* a
[MRAB]
>>> Would/should it be possible to inject a name into a local scope? You can't
>>> inject into a function scope, and names in a function scope can be
>>> determined statically (they are allocated slots), so could the same kind of
>>> thing be done for names in a local scope?
...
[Steven D'
On Wed, May 2, 2018 at 4:03 AM, Matt Arcidy wrote:
> On Tue, May 1, 2018 at 5:35 PM, Mikhail V wrote:
>
>> to be pedantic - ReallyLongDescriptiveIdentifierNames
>> has also an issue with "I" which might confuse because it
>> looks same as little L. Just to illustrate that choice of
>> comparison
Matt, you took the words right out of my mouth! The fonts that are being
used will have a big difference in readability, as will font size,
foreground and background coloring, etc. It would be interesting to see if
anyone has done a serious study of this type though, especially if they
studied it
On Tue, May 1, 2018 at 5:35 PM, Mikhail V wrote:
> to be pedantic - ReallyLongDescriptiveIdentifierNames
> has also an issue with "I" which might confuse because it
> looks same as little L. Just to illustrate that choice of
> comparison samples is very sensitive thing.
> In such a way an experie
On Tue, May 1, 2018 at 6:04 PM, Jacco van Dorp wrote:
> 2018-05-01 14:54 GMT+02:00 Greg Ewing :
>> Rhodri James wrote:
>>>
>>> I'd be interested to know if there is a readability difference between
>>> really_long_descriptive_identifier_name and
>>> ReallyLongDescriptiveIdentifierNames.
>>
>>
>> A
[MRAB]
>>> Imagine renaming the specified names that are declared 'local'
>>> throughout the nested portion:
>>>
>>> def f():
>>> a = 10
>>> local local_a:
>>> def showa():
>>> print("a is", local_a)
>>> showa() # Raises NameError in showa because nothing bound t
On 2018-05-01 19:12, Tim Peters wrote:
[MRAB]
> Imagine renaming the specified names that are declared 'local' throughout
> the nested portion:
>
> def f():
> a = 10
> local local_a:
> def showa():
> print("a is", local_a)
> showa() # Raises NameError in showa
On Tue, May 1, 2018 at 3:42 AM, Steven D'Aprano wrote:
> On Mon, Apr 30, 2018 at 11:28:17AM -0700, Matt Arcidy wrote:
>
> - people are not good judges of readability;
People are the only judges of readability.
Just need the right people.
___
Python-idea
On Tue, May 01, 2018 at 03:02:27PM +, Dan Sommers wrote:
> >> I happen to be an excellent judge of whether a given block of code is
> >> readable to me.
>
> > In the same way that 93% of people say that they are an above-average
> > driver, I'm sure that most people think that they are an exc
On Fri, Apr 27, 2018 at 6:24 PM Nick Coghlan wrote:
> On 27 April 2018 at 21:27, Steven D'Aprano wrote:
>
>> Obviously dp() would have to be magic. There's no way that I know of for
>> a Python function to see the source code of its own arguments. I have no
>> idea what sort of deep voodoo would
Objectively quantifying is easy. For example,
def objective_readability_score(text):
"Return the readability of `text`, a float in 0.0 .. 1.0"
return 2.0 * text.count(":=") / len(text)
Then
>>> objective_readability_score("if value:")
0.0
>>> objective_readability_score("if value := f()
On Tue, May 1, 2018, 02:55 Matt Arcidy wrote:
>
> I am not inferring causality when creating a measure.
No, but when you assume that you can use that measure to *make* code more
readable, then you're assuming causality.
Measuring the
> temperature of a steak doesn't infer why people like it me
[MRAB]
> By "inject" I mean putting a name into a namespace:
>
> import my_module
> my_module.foo = 'FOO'
>
> You can't insert a name into a function's body to make a new local variable.
So you do mean at runtime, I think. Then as before, you can do that
with module and the builtin namesp
[MRAB]
> Imagine renaming the specified names that are declared 'local' throughout
> the nested portion:
>
> def f():
> a = 10
> local local_a:
> def showa():
> print("a is", local_a)
> showa() # Raises NameError in showa because nothing bound to local_a
> yet.
On 2018-05-01 16:23, Steven D'Aprano wrote:
On Mon, Apr 30, 2018 at 08:52:13PM -0500, Tim Peters wrote:
> Would/should it be possible to inject a name into a local scope? You can't
> inject into a function scope, and names in a function scope can be
> determined statically (they are allocated s
On Tue, May 01, 2018 at 09:26:09PM +1200, Greg Ewing wrote:
> Steven D'Aprano wrote:
> >So what was the closure? If the surrounding function was still running,
> >there was no need to capture the running environment in a closure?
>
> You seem to be interpreting the word "closure" a bit
> differen
On 2018-05-01 04:40, Tim Peters wrote:
[MRAB]
>> Any binding that's not specified as local is bound in the parent scope:
[Tim]
> Reverse-engineering the example following, is this a fair way of
> making that more precise?
>
> Given a binding-target name N in scope S, N is bound in scope T, wher
On 2018-05-01 02:52, Tim Peters wrote:
[MRAB ]
> ...
> The intention is that only the specified names are local.
>
> After all, what's the point of specifying names after the 'local' if _any_
> binding in the local scope was local?
Don't look at me ;-) In the absence of use cases, I don't know
[Tim]
> ...
> Here's an example where I don't know what the consequences of "the
> rules" should be:
>
> def f():
> a = 10
> local a:
> def showa():
> print("a is", a)
> showa() # 10
> a = 20
> showa() # 20
> a = 30
> showa() # 10
>
>
I think this method is easy to miss, since people look at the docs for
bytes (e.g. using dir(bytes)). It might be worthwhile to either add a
`bytes.to_int(...)` method (better, IMHO), or to point to int.from_bytes on
the relevant part of the docs.
Elazar
On Tue, May 1, 2018 at 5:09 PM Ken Hilton
On Tue, May 1, 2018 at 8:04 AM, Jacco van Dorp wrote:
> 2018-05-01 14:54 GMT+02:00 Greg Ewing :
> > Rhodri James wrote:
> >>
> >> I'd be interested to know if there is a readability difference between
> >> really_long_descriptive_identifier_name and
> >> ReallyLongDescriptiveIdentifierNames.
> >
On Mon, Apr 30, 2018 at 08:52:13PM -0500, Tim Peters wrote:
> > Would/should it be possible to inject a name into a local scope? You can't
> > inject into a function scope, and names in a function scope can be
> > determined statically (they are allocated slots), so could the same kind of
> > thin
2018-05-01 14:54 GMT+02:00 Greg Ewing :
> Rhodri James wrote:
>>
>> I'd be interested to know if there is a readability difference between
>> really_long_descriptive_identifier_name and
>> ReallyLongDescriptiveIdentifierNames.
>
>
> As one data point on that, jerking my eyes quickly across
> that l
On Tue, 01 May 2018 22:37:11 +1000, Steven D'Aprano wrote:
> On Tue, May 01, 2018 at 04:50:05AM +, Dan Sommers wrote:
>> On Tue, 01 May 2018 10:42:53 +1000, Steven D'Aprano wrote:
>>
>> > - people are not good judges of readability;
>> I happen to be an excellent judge of whether a given blo
Whoops! Never seen that before. Nothing I searched up pointed me to it.
Sorry for wasting your time!
Ken;
--
Sincerely,
Ken;
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: htt
On 1 May 2018 at 21:30, Antoine Pitrou wrote:
>
> Hi Ken,
>
> On Tue, 1 May 2018 19:22:52 +0800
> Ken Hilton wrote:
> >
> > So I'm pretty sure everyone here is familiar with how the "bytes" object
> > works in Python 3. It acts mostly like a string, with the exception that
> > 0-dimensional subs
On Tue, May 01, 2018 at 07:22:52PM +0800, Ken Hilton wrote:
> The only way to get 493182234161465432041076 out of b'hovercraft'
You seem to be using a bytes object as a base-256 number. Under what
circumstances is this desirable?
> in a single expression is as follows:
What's so special about
Rhodri James wrote:
I'd be interested to know if there is a readability difference between
really_long_descriptive_identifier_name and
ReallyLongDescriptiveIdentifierNames.
As one data point on that, jerking my eyes quickly across
that line I found it much easier to pick out the component
word
On Tue, May 01, 2018 at 04:50:05AM +, Dan Sommers wrote:
> On Tue, 01 May 2018 10:42:53 +1000, Steven D'Aprano wrote:
>
> > - people are not good judges of readability;
>
> WTF? By definition, people are the *only* judge of readability.ยน
We're discussing an actual study that attempted, with
On 01/05/18 01:42, Steven D'Aprano wrote:
That's a really nice study, and thank you for posting it.
Seconded!
There are some
interested observations here, e.g.:
- line length is negatively correlated with readability;
(a point against those who insist that 79 character line
limits are
Hi Ken,
On Tue, 1 May 2018 19:22:52 +0800
Ken Hilton wrote:
>
> So I'm pretty sure everyone here is familiar with how the "bytes" object
> works in Python 3. It acts mostly like a string, with the exception that
> 0-dimensional subscripting (var[idx]) returns an integer, not a bytes
> object -
Hi all,
So I'm pretty sure everyone here is familiar with how the "bytes" object
works in Python 3. It acts mostly like a string, with the exception that
0-dimensional subscripting (var[idx]) returns an integer, not a bytes
object - the integer being the ordinal number of the corresponding
charact
On Tue, May 1, 2018 at 1:29 AM, Nathaniel Smith wrote:
> On Mon, Apr 30, 2018 at 8:46 PM, Matt Arcidy wrote:
>> On Mon, Apr 30, 2018 at 5:42 PM, Steven D'Aprano wrote:
>>> (If we know that, let's say, really_long_descriptive_identifier_names
>>> hurt readability, how does that help us judge whet
Yes, it seems that this study has many limitations which don't make its
results very interesting for our community. I think the original point
was that readability *can* be studied rationnally and scientifically,
though.
Regards
Antoine.
On Tue, 1 May 2018 09:00:44 +0200
Jacco van Dorp
wrote
Steven D'Aprano wrote:
So what was the closure? If the surrounding function was still running,
there was no need to capture the running environment in a closure?
You seem to be interpreting the word "closure" a bit
differently from most people. It doesn't imply anything
about whether a surround
On Mon, Apr 30, 2018 at 8:46 PM, Matt Arcidy wrote:
> On Mon, Apr 30, 2018 at 5:42 PM, Steven D'Aprano wrote:
>> (If we know that, let's say, really_long_descriptive_identifier_names
>> hurt readability, how does that help us judge whether adding a new kind
>> of expression will hurt or help read
On Tue, May 01, 2018 at 06:06:06PM +1200, Greg Ewing wrote:
> Steven D'Aprano wrote:
> >Pascal, for example, had lexical scoping back in the 1970s, but
> >no closures.
>
> Well, it kind of had a limited form of closure. You could pass
> a procedure or function *in* to another procedure or functio
I must say my gut agrees that
really_long_identifier_names_with_a_full_description don't look
readable to me. Perhaps it's my exposure to (py)Qt, but I really like
my classes like ThisName and my methods like thisOne. I also tend to
keep them to three words max (real code from yesterday:
getActiveO
41 matches
Mail list logo
