[Alireza Rafiei ]
> I have a list called count_list which contains tuples like below:
>
> > [('bridge', 2), ('fair', 1), ('lady', 1), ('is', 2), ('down', 4),
> > ('london', 2), ('falling', 4), ('my', 1)]
>
>
> I want to sort it based on the second parameter in descending order and the
> tuples with
On Oct 15, 2016 9:45 PM, "Greg Ewing" wrote:
>
> Steven D'Aprano wrote:
>
>> This thread is a huge, multi-day proof that people do not agree that
this is a "reasonable" interpretation.
>
>
> So far I've seen one very vocal person who disgrees, and
> maybe one other who isn't sure.
In case it wasn
On Sat, Oct 15, 2016 at 9:42 PM Steven D'Aprano wrote:
> On Sun, Oct 16, 2016 at 12:48:36PM +1300, Greg Ewing wrote:
> > Steven D'Aprano wrote:
> > >Are you now supporting my argument that starring the list comprehension
> > >expression isn't meaningful?
> >
> > The context it's in (a form of lis
On Sun, Oct 16, 2016 at 3:44 PM, Greg Ewing wrote:
> Steven D'Aprano wrote:
>
>> This thread is a huge, multi-day proof that people do not agree that this
>> is a "reasonable" interpretation.
>
>
> So far I've seen one very vocal person who disgrees, and
> maybe one other who isn't sure.
>
And wh
On Sun, Oct 16, 2016 at 3:29 PM, Alireza Rafiei
wrote:
> What I ended up doing is:
>
>> count_list = sorted(count_list,
>> key=lambda x: (x[1], map(lambda x: -x, map(ord,
>> x[0]))),
>> reverse=True)
>
>
> which works. Now my solution is very specific to str
Steven D'Aprano wrote:
This thread is a huge, multi-day proof that people do not agree that
this is a "reasonable" interpretation.
So far I've seen one very vocal person who disgrees, and
maybe one other who isn't sure.
This proposal only makes even a little
bit of sense if you imagine list
Hi all,
I have a list called count_list which contains tuples like below:
[('bridge', 2), ('fair', 1), ('lady', 1), ('is', 2), ('down', 4),
> ('london', 2), ('falling', 4), ('my', 1)]
I want to sort it based on the second parameter in descending order and the
tuples with the same second paramet
On Sun, Oct 16, 2016 at 12:10 PM, Steven D'Aprano wrote:
> On Sun, Oct 16, 2016 at 04:36:05AM +1100, Chris Angelico wrote:
>> On Sun, Oct 16, 2016 at 4:33 AM, אלעזר wrote:
>> > You are confusing here two distinct roles of the parenthesis:
>> > disambiguation
>> > as in "(1 + 2) * 2", and tuple c
On Oct 15, 2016 6:42 PM, "Steven D'Aprano" wrote:
> doesn't make sense, it is invalid. Call it something else: the new
> "flatten" operator:
>
> [^t for t in iterable]
>
> for example, which magically adds an second invisible for-loop to your
list comps:
This thread is a lot of work to try to
FWIW, Python 3.6 should print this in the console just fine. Feel free to
upgrade whenever you're ready.
Cheers,
Steve
-Original Message-
From: "Mikhail V"
Sent: 10/12/2016 16:07
To: "M.-A. Lemburg"
Cc: "python-ideas@python.org"
Subject: Re: [Python-ideas] Proposal for default char
On Sun, Oct 16, 2016 at 04:36:05AM +1100, Chris Angelico wrote:
> On Sun, Oct 16, 2016 at 4:33 AM, אלעזר wrote:
> > You are confusing here two distinct roles of the parenthesis: disambiguation
> > as in "(1 + 2) * 2", and tuple construction as in (1, 2, 3). This overload
> > is the reason that (1)
On Sun, Oct 16, 2016 at 12:48:36PM +1300, Greg Ewing wrote:
> Steven D'Aprano wrote:
> >Are you now supporting my argument that starring the list comprehension
> >expression isn't meaningful?
>
> The context it's in (a form of list display) has a clear
> meaning for a comma-separated list of valu
On 2016-10-12 22:46, Mikhail V wrote:
For numbers obviously you don't need so many character as for
speech encoding, so this means that only those glyphs or even a subset
of it should be used. This means anything more than 8 characters
is quite worthless for reading numbers.
Note that I can't pro
Mikhail V wrote:
Also I can only hard imagine that special purpose
of some language can ignore readability,
Readability is not something absolute that stands on its
own. It depends a great deal on what is being expressed.
even if it is assembler or whatever,
it can be made readable without mu
Steven D'Aprano wrote:
Are you now supporting my argument that starring the list comprehension
expression isn't meaningful?
The context it's in (a form of list display) has a clear
meaning for a comma-separated list of values, so there
is a reasonable interpretation that it *could* be given.
On 15.10.2016 16:47, Martti Kühne wrote:
[var for expression in iterable for var in expression]
you are right, though. List comprehensions are already stackable.
TIL.
Good catch, Paul. Comprehensions appear to be a special case when it
comes to unpacking as they provide an alternative path. So
On 15.10.2016 23:19, Nick Timkovich wrote:
Features and speed are good, but I'm interested in getting something
with the basic features into the Standard Library so it's just there.
Not having done that before and bit clueless, I'm wanting to learn
that slightly less-technical procedure. What are
Features and speed are good, but I'm interested in getting something
with the basic features into the Standard Library so it's just there.
Not having done that before and bit clueless, I'm wanting to learn
that slightly less-technical procedure. What are the steps to make
that happen?
On Sat, Oct
On 15 October 2016 at 16:27, Chris Angelico wrote:
> On Sun, Oct 16, 2016 at 12:06 AM, Mikhail V wrote:
>> But I can bravely claim that it is better than *any*
>> hex notation, it just follows from what I have here
>> on paper on my table, namely that it is physically
>> impossible to make up hig
On 15.10.2016 20:15, Nick Timkovich wrote:
I once again had a use for heaps, and after rewrapping the heapq.heap*
methods for the umpteenth time, figured I'd try my hand at freezing
off that wart.
We re-discussed this in the beginning of 2016 and xheap
https://pypi.python.org/pypi/xheap was on
>
> Are there precedences of combining verbose and version options in other
> programs?
>
No, I was just afraid about other programs rely on format of python -V.
> PyPy just outputs sys.version for the --version option.
>
> $ pypy -V
> Python 2.7.10 (5.4.1+dfsg-1~ppa1~ubuntu16.04, Sep 06 2016, 23
I once again had a use for heaps, and after rewrapping the heapq.heap*
methods for the umpteenth time, figured I'd try my hand at freezing
off that wart.
Some research turned up an older thread by Facundo Batista
(https://mail.python.org/pipermail/python-ideas/2009-April/004173.html),
but it seems
On Sat, Oct 15, 2016 at 8:45 PM Chris Angelico wrote:
> On Sun, Oct 16, 2016 at 4:38 AM, אלעזר wrote:
> > On Sat, Oct 15, 2016 at 8:36 PM Chris Angelico wrote:
> >>
> >> On Sun, Oct 16, 2016 at 4:33 AM, אלעזר wrote:
> >> > You are confusing here two distinct roles of the parenthesis:
> >> > di
On Sun, Oct 16, 2016 at 4:38 AM, אלעזר wrote:
> On Sat, Oct 15, 2016 at 8:36 PM Chris Angelico wrote:
>>
>> On Sun, Oct 16, 2016 at 4:33 AM, אלעזר wrote:
>> > You are confusing here two distinct roles of the parenthesis:
>> > disambiguation
>> > as in "(1 + 2) * 2", and tuple construction as in
On Sat, Oct 15, 2016 at 8:36 PM Chris Angelico wrote:
> On Sun, Oct 16, 2016 at 4:33 AM, אלעזר wrote:
> > You are confusing here two distinct roles of the parenthesis:
> disambiguation
> > as in "(1 + 2) * 2", and tuple construction as in (1, 2, 3). This
> overload
> > is the reason that (1) is
On Sat, Oct 15, 2016 at 5:01 AM Steven D'Aprano wrote:
> On Thu, Oct 13, 2016 at 01:30:45PM -0700, Neil Girdhar wrote:
>
> > From a CPython implementation standpoint, we specifically blocked this
> code
> > path, and it is only a matter of unblocking it if we want to support
> this.
>
> I find th
On Sun, Oct 16, 2016 at 4:33 AM, אלעזר wrote:
> You are confusing here two distinct roles of the parenthesis: disambiguation
> as in "(1 + 2) * 2", and tuple construction as in (1, 2, 3). This overload
> is the reason that (1) is not a 1-tuple and we must write (1,).
Parentheses do not a tuple ma
On Sat, Oct 15, 2016 at 1:49 PM Steven D'Aprano wrote:
...
> And the transformation of *t for the items of t (I don't care if it is a
> real transformation in the implementation, or only a fictional
> transformation) cannot work in a list comp. Let's make the number of
> items of t explicit so we
On Sat, Oct 15, 2016, at 06:38, Steven D'Aprano wrote:
> > Replacing it _with the items_ is not the same thing as replacing it
> > _with a sequence containing the items_,
>
> I don't think I ever used the phrasing "a sequence containing the
> items". I think that's *your* phrase, not mine.
It's
On Sat, Oct 15, 2016 at 3:06 PM, Paul Moore wrote:
> is the same as
>
> [ x for var in iterable for x in expression ]
>
correction, that would be:
[var for expression in iterable for var in expression]
you are right, though. List comprehensions are already stackable.
TIL.
cheers!
mar77i
__
On Sun, Oct 16, 2016 at 12:06 AM, Mikhail V wrote:
> But I can bravely claim that it is better than *any*
> hex notation, it just follows from what I have here
> on paper on my table, namely that it is physically
> impossible to make up highly effective glyph system
> of more than 8 symbols.
You
On 14 October 2016 at 11:36, Greg Ewing wrote:
>but bash wasn't designed for that.
>(The fact that some people use it that way says more
>about their dogged persistence in the face of
>adversity than it does about bash.)
I can not judge what bash is good for, since I never
tried to learn it. But
On 14 October 2016 at 10:48, Paul Moore wrote:
> 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-
Hello,
In the Code lay-out\Indentation section of PEP8 it is stated that
"
The closing brace/bracket/parenthesis on multi-line constructs may either
line up under the first non-whitespace character of the last line of list,
as in:
my_list = [
1, 2, 3,
4, 5, 6,
]
result = s
On Sat, Oct 15, 2016 at 12:48 PM, Steven D'Aprano wrote:
> Oh look, just like now:
>
> py> iterable = [(1, 'a'), (2, 'b')]
> py> [(100, *t) for t in iterable]
> [(100, 1, 'a'), (100, 2, 'b')]
>
> Hands up anyone who expected to flatten the iterable and get
>
> [100, 1, 'a', 100, 2, 'b']
>
> in
On 14.10.2016 10:26, Serhiy Storchaka wrote:
> 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 cha
On Sat, Oct 15, 2016 at 11:36:28PM +1300, Greg Ewing wrote:
> Indeed. In situations where there isn't any context for
> the interpretation of *, it's not allowed.
You mean like in list comprehensions?
Are you now supporting my argument that starring the list comprehension
expression isn't mean
On Sat, Oct 15, 2016 at 04:42:13AM -0400, Random832 wrote:
> On Sat, Oct 15, 2016, at 04:00, Steven D'Aprano wrote:
> > > This is unpacking. It unpacks the results into the destination.
> >
> > If it were unpacking as it is understood today, with no other changes,
> > it would be a no-op. (To be
Martti Kühne wrote:
You brush over the fact that *t is not limited to a replacement by a
comma-separated sequence of items from t, but *t is actually a
replacement by that comma-separated sequence of items from t INTO an
external context.
Indeed. In situations where there isn't any context for
Steven D'Aprano wrote:
t = (1, 2, 3)
iterable = [t]
[*t for t in iterable]
If you do the same manual replacement, you get:
[1, 2, 3 for t in iterable]
Um, no, you need to also *remove the for loop*, otherwise
you get complete nonsense, whether * is used or not.
Let's try a l
On 15.10.2016 08:10, Nick Coghlan wrote:
However, it's also the case that where we *do* have a well understood
and nicely constrained problem, it's still better to complain loudly
when data is unexpectedly missing, rather than subjecting ourselves to
the pain of having to deal with detecting prob
On Sat, Oct 15, 2016 at 10:09 AM, Steven D'Aprano wrote:
> Not everything is a function. What's your point?
>
> As far as I can see, in *every* other use of sequence unpacking, *t is
> conceptually replaced by a comma-separated sequence of items from t. If
> the starred item is on the left-hand si
On Sat, Oct 15, 2016 at 10:09 AM, Steven D'Aprano wrote:
> Not everything is a function. What's your point?
>
> As far as I can see, in *every* other use of sequence unpacking, *t is
> conceptually replaced by a comma-separated sequence of items from t. If
> the starred item is on the left-hand si
On Sat, Oct 15, 2016 at 01:42:34PM +1300, Greg Ewing wrote:
> 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 emoticon
On Thu, Oct 13, 2016 at 01:30:45PM -0700, Neil Girdhar wrote:
> From a CPython implementation standpoint, we specifically blocked this code
> path, and it is only a matter of unblocking it if we want to support this.
I find that difficult to believe. The suggested change seems like it
should be
On Fri, Oct 14, 2016 at 06:23:32PM +1300, Greg Ewing wrote:
> To maintain the identity
>
> list(*x for x in y) == [*x for x in y]
>
> it would be necessary for the *x in (*x for x in y) to expand
> to "yield from x".
Oh man, you're not even trying to be persuasive any more. You're just
assum
On Sat, Oct 15, 2016, at 04:00, Steven D'Aprano wrote:
> > This is unpacking. It unpacks the results into the destination.
>
> If it were unpacking as it is understood today, with no other changes,
> it would be a no-op. (To be technical, it would convert whatever
> iterable t is into a tuple.)
On Fri, Oct 14, 2016 at 07:51:18AM +, Neil Girdhar wrote:
> 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 cont
On Fri, Oct 14, 2016 at 08:29:28PM +1300, Greg Ewing wrote:
> 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
On Thu, Oct 13, 2016 at 11:32:49PM -0400, Random832 wrote:
> On Thu, Oct 13, 2016, at 18:15, Steven D'Aprano wrote:
> > Consider the analogy with f(*t), where t = (a, b, c). We *don't* have:
> >
> > f(*t) is equivalent to f(a); f(b); f(c)
>
> I don't know where this "analogy" is coming from.
On Fri, Oct 14, 2016, at 22:38, Steven D'Aprano wrote:
> 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 jus
On 14.10.16 10:40, INADA Naoki wrote:
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(s
52 matches
Mail list logo
