On 13 October 2016 at 12:05, Cory Benfield wrote:
>
> integer & 0x00FF # Hex
> integer & 16777215 # Decimal
> integer & 0o # Octal
> integer & 0b # Binary
>
> The octal representation is infuriating because one octal digit refers to
> *three* bits
Correct,
Paul Moore wrote:
PS I can counter a suggestion of using *f(t) rather than from f(t) in
the above, by saying that it adds yet another meaning to the already
heavily overloaded * symbol.
We've *already* given it that meaning in non-comprehension
list displays, though, so we're not really adding
Paul Moore wrote:
3. *fn(x) isn't an expression, and yet it *looks* like it should be ...
> To me, that suggests it would be hard to teach.
It's not an expression in any of the other places it's
used, either. Is it hard to to teach in those cases as
well?
--
Greg
__
אלעזר wrote:
I think it is an unfortunate accident of syntax, the use of "yield from
foo()" instead of "yield *foo()".
I think that was actually discussed back when yield-from
was being thrashed out, but as far as I remember we didn't
have * in list displays then, so the argument for it was
wea
On Fri, Oct 14, 2016 at 08:05:40AM +0200, Mikhail V wrote:
> Any critics on it? Besides not following the unicode consortium.
Besides the other remarks on "tradition", I think this is where a big
problem lies: We should not deviate from a common standard (without
very good cause).
There are cases
Steven D'Aprano wrote:
So why would yield *t give us this?
yield a; yield b; yield c
By analogy with the function call syntax, it should mean:
yield (a, b, c)
This is a false analogy, because yield is not a function.
However, consider the following spelling:
l = [from f(t) fo
On Fri, Oct 14, 2016 at 07:06:12PM +1300, Greg Ewing wrote:
> Sjoerd Job Postmus wrote:
> >I think the suggested spelling (`*`) is the confusing part. If it were
> >to be spelled `from ` instead, it would be less confusing.
>
> Are you suggesting this spelling just for generator
> comprehensions,
When reporting issue to some project and want to include
python version in the report, python -V shows very limited information.
$ ./python.exe -V
Python 3.6.0b2+
sys.version is more usable, but it requires one liner.
$ ./python.exe -c 'import sys; print(sys.version)'
3.6.0b2+ (3.6:86a1905ea28d+
On 13 October 2016 at 16:50, Chris Angelico wrote:
> On Fri, Oct 14, 2016 at 1:25 AM, Steven D'Aprano wrote:
>> On Thu, Oct 13, 2016 at 03:56:59AM +0200, Mikhail V wrote:
>>> and in long perspective when the world's alphabetical garbage will
>>> dissapear, two digits would be ok.
>> Talking about
Here's an interesting idea regarding yield **x:
Right now a function containing any yield returns a generator. Therefore,
it works like a generator expression, which is the lazy version of a list
display. lists can only contain elements x and unpackings *x. Therefore,
it would make sense to onl
On Fri, Oct 14, 2016 at 6:53 PM, Mikhail V wrote:
> On 13 October 2016 at 16:50, Chris Angelico wrote:
>> On Fri, Oct 14, 2016 at 1:25 AM, Steven D'Aprano wrote:
>>> On Thu, Oct 13, 2016 at 03:56:59AM +0200, Mikhail V wrote:
and in long perspective when the world's alphabetical garbage will
> On 14 Oct 2016, at 08:53, Mikhail V wrote:
>
> What keeps people from using same characters?
> I will tell you what - it is local law. If you go to school you *have* to
> write in what is prescribed by big daddy. If youre in europe or America, you
> are
> more lucky. And if you're in China yo
On Fri, Oct 14, 2016 at 7:18 PM, Cory Benfield wrote:
> The many glyphs that exist for writing various human languages are not
> inefficiency to be optimised away. Further, I should note that most places to
> not legislate about what character sets are acceptable to transcribe their
> languages
On 13.10.16 17:50, Chris Angelico wrote:
Solution: Abolish most of the control characters. Let's define a brand
new character encoding with no "alphabetical garbage". These
characters will be sufficient for everyone:
* [2] Formatting characters: space, newline. Everything else can go.
* [8] Digi
Regarding all those examples:
Le 14/10/2016 à 00:08, אלעזר a écrit :
Trying to restate the proposal, somewhat more formal following Random832
and Paul's suggestion.
I only speak about the single star.
---
*The suggested change of syntax:*
comprehension ::= starred_expression comp_for
*S
בתאריך יום ו׳, 14 באוק' 2016, 12:19, מאת Michel Desmoulin <
desmoulinmic...@gmail.com>:
> Regarding all those examples:
>
> Le 14/10/2016 à 00:08, אלעזר a écrit :
> > Trying to restate the proposal, somewhat more formal following Random832
> > and Paul's suggestion.
> >
> > I only speak about the
Mikhail V wrote:
if "\u1230" <= c <= "\u123f":
and:
o = ord (c)
if 100 <= o <= 150:
Note that, if need be, you could also write that as
if 0x64 <= o <= 0x96:
So yours is a valid code but for me its freaky,
and surely I stick to the second variant.
The thing is, where did you get those
On Fri, Oct 14, 2016 at 8:36 PM, Greg Ewing wrote:
>> I know people who can read bash scripts
>> fast, but would you claim that bash syntax can be
>> any good compared to Python syntax?
>
>
> For the things that bash was designed to be good for,
> yes, it can. Python wins for anything beyond very
On 14 October 2016 at 07:54, Greg Ewing wrote:
>> I think it's probably time for someone to
>> describe the precise syntax (as BNF, like the syntax in the Python
>> docs at
>> https://docs.python.org/3.6/reference/expressions.html#displays-for-lists-sets-and-dictionaries
>
>
> Replace
>
>compr
On Fri, Oct 14, 2016, at 01:54, Steven D'Aprano wrote:
> Good luck with that last one. Even if you could convince the Chinese and
> Japanese to swap to ASCII, I'd like to see you pry the emoji out of the
> young folk's phones.
This is actually probably the one part of this proposal that *is*
fea
On Fri, Oct 14, 2016 at 10:56 PM, Random832 wrote:
> On Fri, Oct 14, 2016, at 01:54, Steven D'Aprano wrote:
>> Good luck with that last one. Even if you could convince the Chinese and
>> Japanese to swap to ASCII, I'd like to see you pry the emoji out of the
>> young folk's phones.
>
> This is act
Sorry if I missed the boat, but only just now saw this PEP.
Glancing through the PEP, I don't see mentioned anywhere the SQL
alternative of having a coalesce() function:
https://www.postgresql.org/docs/9.6/static/functions-conditional.html#FUNCTIONS-COALESCE-NVL-IFNULL
In Python, something like t
On Fri, Oct 14, 2016 at 4:14 PM Gustavo Carneiro
wrote:
> Sorry if I missed the boat, but only just now saw this PEP.
>
> Glancing through the PEP, I don't see mentioned anywhere the SQL
> alternative of having a coalesce() function:
> https://www.postgresql.org/docs/9.6/static/functions-conditio
On 14 October 2016 at 14:19, אלעזר wrote:
> On Fri, Oct 14, 2016 at 4:14 PM Gustavo Carneiro
> wrote:
>
>> Sorry if I missed the boat, but only just now saw this PEP.
>>
>> Glancing through the PEP, I don't see mentioned anywhere the SQL
>> alternative of having a coalesce() function: https://ww
On Oct 14, 2016 9:14 AM, "Gustavo Carneiro" wrote:
>
> Sorry if I missed the boat, but only just now saw this PEP.
>
> Glancing through the PEP, I don't see mentioned anywhere the SQL
alternative of having a coalesce() function:
https://www.postgresql.org/docs/9.6/static/functions-conditional.html
My mistake. You're talking about the ?? operator, and I'm thinking about
the null-aware operators.
You say short-circuiting would be nice to have, but short-circuiting is
what people want it for. As for using `if-else`, that's listed as an
alternative here:
https://www.python.org/dev/peps/pep-0505
On 14 October 2016 at 14:46, Franklin? Lee
wrote:
> On Oct 14, 2016 9:14 AM, "Gustavo Carneiro" wrote:
> >
> > Sorry if I missed the boat, but only just now saw this PEP.
> >
> > Glancing through the PEP, I don't see mentioned anywhere the SQL
> alternative of having a coalesce() function: https
On Fri, Oct 14, 2016 at 9:37 AM, Gustavo Carneiro
wrote:
>
> I see. short-circuiting is nice to have, sure.
>
> But even without it, it's still useful IMHO.
>
It's worth mentioning that SQL's COALESCE is usually (always?) short
circuiting:
https://www.postgresql.org/docs/9.5/static/functions-
On 14 October 2016 at 00:04, Steven D'Aprano wrote:
> Error messages are not part of Python's public API. We should be able to
> change error messages at any time, including point releases.
>
> Nevertheless, we shouldn't abuse that right. If it's only a change to
> the error message, and not a fun
On 14 October 2016 at 06:48, Neil Girdhar wrote:
> Related:
>
> Nick posted an excellent answer to this question here:
> http://stackoverflow.com/questions/5953205/why-are-there-no-sorted-containers-in-pythons-standard-libraries
Ah, so this thread is why I've been getting SO notifications for tha
On 13 October 2016 at 02:32, Sven R. Kunze wrote:
> Here I disagree with you. We use *args all the time, so we know what * does.
> I don't understand why this should not work in between brackets [...].
It does work between brackets:
>>> [*range(3)]
[0, 1, 2]
It doesn't work as part of t
On Fri, Oct 14, 2016 at 6:37 AM, Gustavo Carneiro wrote:
> I see. short-circuiting is nice to have, sure.
No. Short-circuiting is the entire point of the proposed operators.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Pyth
For all intents and purposes other than debugging C (for cpython, rpython
for pypy, java for jython, .NET for IronPython... you get the idea), the
extra details are unnecessary to debug most problems. Most of the time it
is sufficient to know what major, minor, and patchlevel you are using. You
o
I actually think the spelling is the main stumbling block. The
intrinsic value of the behavior is clear, it's finding an acceptable
spelling that hold back the proposal.
I propose that the next phase of the process should be to pick the
best operator for each sub-proposal. Then we can decide which
On Fri, Oct 14, 2016 at 9:09 AM, wrote:
> For all intents and purposes other than debugging C (for cpython, rpython
> for pypy, java for jython, .NET for IronPython... you get the idea), the
> extra details are unnecessary to debug most problems. Most of the time it
> is sufficient to know what
For what it's worth, I like the C# syntax with question marks.
It is probably more risky (breaks more code) to introduce a new keyword
than a new symbol as operator.
If we have to pick a symbol, it's less confusing if we pick something
another language already uses. There is no shame in copying
Nathaniel Smith wrote:
> The compiler information generally reveals the OS as well (if only
> accidentally), and the OS is often useful information.
But in which situation would you really need to call Python from
outside to find out which OS you're on?
Sebastian
On Sat, Oct 15, 2016 at 4:52 AM, Sebastian Krause
wrote:
> Nathaniel Smith wrote:
>> The compiler information generally reveals the OS as well (if only
>> accidentally), and the OS is often useful information.
>
> But in which situation would you really need to call Python from
> outside to find
I'm all for adding more featureful data structures. At the risk of
confusing Nick's folks, I think it's possible to do even better than
Sorted/Ordered for many collections. In my experience, the simple Ordered
trait alone was not enough of a feature improvement over the simpler
builtin, leading me
On Fri, Oct 14, 2016 at 07:56:29AM -0400, Random832 wrote:
> On Fri, Oct 14, 2016, at 01:54, Steven D'Aprano wrote:
> > Good luck with that last one. Even if you could convince the Chinese and
> > Japanese to swap to ASCII, I'd like to see you pry the emoji out of the
> > young folk's phones.
>
Steven D'Aprano wrote:
That's because some sequence of characters
is being wrongly interpreted as an emoticon by the client software.
The only thing wrong here is that the client software
is trying to interpret the emoticons.
Emoticons are for *humans* to interpret, not software.
Subtlety and
On Fri, Oct 14, 2016 at 04:18:40AM +0100, MRAB wrote:
> On 2016-10-14 02:04, Steven D'Aprano wrote:
> >On Thu, Oct 13, 2016 at 08:15:36PM +0200, Martti Kühne wrote:
> >
> >>Can I fix my name, though?
> >
> >I don't understand what you mean. Your email address says your name is
> >Martti Kühne. Is t
On Fri, Oct 14, 2016 at 12:10 PM, Guido van Rossum wrote:
> I propose that the next phase of the process should be to pick the
> best operator for each sub-proposal. Then we can decide which of the
> sub-proposals we actually want in the language, based on a combination
> of how important the fun
On Thu, Oct 13, 2016 at 05:30:49PM -0400, Random832 wrote:
> Frankly, I don't see why the pattern isn't obvious
*shrug*
Maybe your inability to look past your assumptions and see things from
other people's perspective is just as much a blind spot as our inability
to see why you think the patte
I'm not usually swayed by surveys -- Python is not a democracy. Maybe
a bunch of longer examples would help all of us see the advantages of
the proposals.
On Fri, Oct 14, 2016 at 8:09 PM, Mark E. Haase wrote:
> On Fri, Oct 14, 2016 at 12:10 PM, Guido van Rossum wrote:
>>
>> I propose that the ne
On Mon, Oct 10, 2016 at 11:29 PM, Elliot Gorokhovsky
wrote:
>> Note that when Python's current sort was adopted in Java, they still kept
>> a quicksort variant for "unboxed" builtin types. The adaptive merge sort
>> incurs many overheads that often cost more than they save unless comparisons
>> a
On 15 October 2016 at 03:52, Sebastian Krause wrote:
> Nathaniel Smith wrote:
>> The compiler information generally reveals the OS as well (if only
>> accidentally), and the OS is often useful information.
>
> But in which situation would you really need to call Python from
> outside to find out
On 15 October 2016 at 13:36, Guido van Rossum wrote:
> I'm not usually swayed by surveys -- Python is not a democracy. Maybe
> a bunch of longer examples would help all of us see the advantages of
> the proposals.
Having been previously somewhere between -1 and -0, I've been doing a
lot more data
15 Жов 2016 08:11 "Nick Coghlan" пише:
>
> On 15 October 2016 at 13:36, Guido van Rossum wrote:
> > I'm not usually swayed by surveys -- Python is not a democracy. Maybe
> > a bunch of longer examples would help all of us see the advantages of
> > the proposals.
>
> Having been previously somewhe
49 matches
Mail list logo
