> On Tue, Aug 30, 2016 at 3:13 PM Eric V. Smith wrote:
> >On 08/30/2016 07:02 AM, Philipp A. wrote:
> > Also the name “f-strings” is really misleading: They’re composite
> > expressions that evaluate to strings. They can only be considered
> > strings if you have no braced code parts in them. So I
Naive shuffled() can be emulated using a single expression:
sorted(lst, key=lambda _: random())
So there's even less incentive for standardization.
~Elazar
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinf
(Just to be clear, I wasn't trying to suggest this as more than an ad-hoc
solution for a throwaway script. But to me, "sorted by random key" is
almost as obvious as "shuffled", perhaps more so for non english speakers
with little background in CS terms; the words "sorted" and "random" jumps
to the
This has come up before. It will be a special case of making "if" without
"else" result in a special "empty" type that is not part of the iteration.
As in `[1, (2 if False) ] == [1]`.
בתאריך יום א׳, 11 בספט' 2016, 13:29, מאת Bernardo Sulzbach <
mafagafogiga...@gmail.com>:
> On 09/11/2016 06:36 A
This suggestion is so obvious that it's likely has been discussed, but I
can't find any reference (It's not what PEP-3124 talks about).
Generic class syntax, now:
_T_co = TypeVar('_T', covariant=True)
class Container(Generic[_T_co]):
@abstractmethod
def __contains__(self,
Does that mean that if I did, it would be reconsidered?
On Thu, Sep 15, 2016 at 12:43 PM Ivan Levkivskyi
wrote:
> On 15 September 2016 at 11:21, אלעזר wrote:
>
>> This suggestion is so obvious that it's likely has been discussed, but I
>> can't find any reference (
And that thread is only about variance. What about the generic syntax?
On Thu, Sep 15, 2016 at 12:44 PM אלעזר wrote:
> Does that mean that if I did, it would be reconsidered?
>
> On Thu, Sep 15, 2016 at 12:43 PM Ivan Levkivskyi
> wrote:
>
>> On 15 September 2016 a
hu, Sep 15, 2016 at 2:03 PM Nick Coghlan wrote:
> On 15 September 2016 at 19:53, Ivan Levkivskyi
> wrote:
> >
> >
> > On 15 September 2016 at 11:46, אלעזר wrote:
> >>
> >> And that thread is only about variance. What about the generic syntax?
> >
> &
With the new variable annotation syntax, it is possible to implement a
useful "modifiers" library, all used as superclasses.
Possible modifiers:
* Named / Struct: annotation-defined fields. No monkey patching.
* Immutable / Const
* Sealed / Final: unsubclassable class
* Array: a mutable tu
Thanks for the reply
בתאריך יום ו׳, 16 בספט' 2016, 13:16, מאת Steven D'Aprano <
st...@pearwood.info>:
> On Fri, Sep 16, 2016 at 12:10:22AM +, אלעזר wrote:
>
> [...]
> > Benefits of putting such a collection in stdlib (instead of as an
> external
> >
>
> > 1. This information can be used by typecheckers, and also by users, to
>> > reason about programs. If isinstance(x, ImmutableArray), then x is an
>> > instantiation of ImmutableArray.
>>
>> That's how type-checkers work. The class doesn't need to be in the std
>> lib for a type-checker to rea
On Fri, Sep 16, 2016 at 1:16 PM Steven D'Aprano wrote:
> On Fri, Sep 16, 2016 at 12:10:22AM +0000, אלעזר wrote:
>
> [...]
> > Benefits of putting such a collection in stdlib (instead of as an
> external
> > package) include:
>
> Slow down! Before getting al
Thank you all!
אלעזר
(AKA Elazar)
On Sat, Sep 17, 2016 at 4:53 AM Steven D'Aprano wrote:
> On Sat, Sep 17, 2016 at 03:39:08AM +1000, Chris Angelico wrote:
> > On Fri, Sep 16, 2016 at 11:22 PM, אלעזר wrote:
> > > P.S. how do I change the name in my quotes? I believe א
If at all, it should be function.bind(). It was discussed and dropped; I
don't remember why, but one problem is that it looks like an in-place
modification.
Personally I think that higher order programming should not be encouraged
(as opposed to functional programming), and from the lambda syntax
Many proposals to add something to stdlib are rejected here with the
suggestion to add such library to pypi first. As noted by someone, pypi is
not as reachable as stdlib, and one should install that package first,
which many people don't know how. Additionally, there is no natural
distinction betw
r
On Mon, Sep 19, 2016 at 7:38 PM Ethan Furman wrote:
> On 09/19/2016 09:25 AM, אלעזר wrote:
>
> > Many proposals to add something to stdlib are rejected here with the
> suggestion to add such library to pypi first. As noted by someone, pypi is
> not as reachable as stdlib, and
Thanks Joonas. I withdraw my proposal - nothing more is strictly needed. It
should be idiomatic somehow, but I don't have any specific suggestion.
On Mon, Sep 19, 2016 at 7:59 PM Joonas Liik wrote:
> On 19 September 2016 at 19:55, אלעזר wrote:
> > A library in PyPi still requi
ain minuses:
>
>
> from __pip__ import nova-lxd # would this work?
>
> What about versions?
>
> from __pip__ import run-lambda>=0.1.0 # would this work?
>
>
> Maybe, I thinking too complicated here but if it works for, say,
> "requests" people tend to want
> [ERROR]: Your autotools build scripts are 200 lines longer than your
> program. Something’s wrong.
> http://kirbyfan64.github.io/
> On Sep 19, 2016 11:26 AM, "אלעזר" wrote:
>
>> Many proposals to add something to stdlib are rejected here with the
>> suggestion
Then you'll get
SyntaxError: from __pip__ imports must occur at the beginning of the
file
Or "must be string literal or an identifier" if it's allowed outside the
beginning of the file.
On Mon, Sep 19, 2016 at 9:44 PM MRAB wrote:
> On 2016-09-19 18:20, אלע
:
> > On 2016-09-19 18:20, אלעזר wrote:
> >>
> >> Obviously
> >>
> >> from __pip__ import "run-lambda>=0.1.0"
> >>
> >> Which is ugly but not my fault :)
> >>
> > [snip]
> > One possible problem I
other answers will have comments saying "just add this statement to the
beginning of your script".
On Mon, Sep 19, 2016 at 11:24 PM Paul Moore wrote:
> On 19 September 2016 at 19:52, אלעזר wrote:
> > Of course it doesn't address the issues - for example, running a python
Another use case, though I admit not the top priority of anyone here, is
that of assignment checkers. In most courses I took at the university, the
person who checks the assignments says something like "you are allowed to
use only this this and this libraries", in order not to mess with unknown
dep
Alternative syntax might be that of import decorators
@from_pip("attrs")
import attr
It's only worthwhile if there are any other uses for import decorators. One
possibility is for other online modules, probably by giving a url. I can
come up with more, but it's making a solution without having a
On Tue, Sep 20, 2016 at 1:40 AM Paul Moore wrote:
> On 19 September 2016 at 23:13, אלעזר wrote:
> > Alternative syntax might be that of import decorators
> >
> > @from_pip("attrs")
> > import attr
>
> At which point you may as well just (insert disclai
ld not find a version that satisfies the requirement nonesuch (from
> versions: )
> No matching distribution found for nonesuch
> 1
>
>
> On Mon, Sep 19, 2016 at 3:46 PM, אלעזר wrote:
>
>> On Tue, Sep 20, 2016 at 1:40 AM Paul Moore wrote:
>>
>>> On 19 Septe
On Tue, Sep 20, 2016 at 2:20 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> אלעזר writes:
>
> > Another use case, though I admit not the top priority of anyone here, is
> > that of assignment checkers. In most courses I took at the universit
t; On Tue, Sep 20, 2016 at 2:20 AM Stephen J. Turnbull <
> turnbull.stephen...@u.tsukuba.ac.jp> wrote:
>
>> אלעזר writes:
>>
>> > Another use case, though I admit not the top priority of anyone here,
>> is
>> > that of assignment checkers. In mo
On Tue, Sep 20, 2016 at 2:34 AM Chris Angelico wrote:
> On Tue, Sep 20, 2016 at 9:20 AM, Stephen J. Turnbull
> wrote:
> > אלעזר writes:
> >
> > > Another use case, though I admit not the top priority of anyone here,
> is
> > > that of assignment
But grepping and piping could work I assume?
On Tue, Sep 20, 2016 at 2:41 AM Chris Angelico wrote:
> On Tue, Sep 20, 2016 at 9:27 AM, Xavier Combelle
> wrote:
> > I find the idea of tracking the dependencies in the script might be a
> > good idea.
> > However, magically downloading without warn
On Tue, Sep 20, 2016 at 3:06 AM Ethan Furman wrote:
> On 09/19/2016 04:38 PM, אלעזר wrote:
>
> > I was talking specifically about advanced courses, in which an assignment
> > is "implement a side-channel attack using data" and you can use whatever
>
But the foo() finds the function to call, so foo.bind() could be made to
find it too.
בתאריך יום ג׳, 20 בספט' 2016, 08:24, מאת Stefan Behnel :
> אלעזר schrieb am 19.09.2016 um 17:59:
> > If at all, it should be function.bind(). It was discussed and dropped; I
> > don
On Tue, Sep 20, 2016 at 4:56 AM Steven D'Aprano wrote:
> On Mon, Sep 19, 2016 at 01:35:53PM -0700, João Matos wrote:
> > Hello,
> >
> > I don't see why creating a clear command would interfere with
> dict.clear()
> > which is a function/method.
>
> For the same reason that you can't have a method
On Tue, Sep 20, 2016 at 10:54 AM Chris Angelico wrote:
> On Tue, Sep 20, 2016 at 5:01 PM, אלעזר wrote:
> > But the foo() finds the function to call, so foo.bind() could be made to
> > find it too.
>
> class Demo:
> def __init__(self):
> self.bind =
Yeah I did say it was a strawman :)
On Tue, Sep 20, 2016 at 11:17 AM Chris Angelico wrote:
> On Tue, Sep 20, 2016 at 6:09 PM, אלעזר wrote:
> > I meant something like making it a "__bind__" (just a strawman
> suggestion)
> > and do the same lookup as fo
amespace.
> It solves the import problem and feels very natural IMO.
>
> The only issue is the name. In my mind, bind() convey the idea you are
> modifying the function it self, while partial() convey the idea you
> return new function.
>
> It could also be written in C for perf
I believe that at least some of these problems can be addressed given that
pip *knows* that this import is an in-script import. So the list of corner
cases will be shorter.
Elazar
On Tue, Sep 20, 2016 at 1:35 PM Paul Moore wrote:
> On 19 September 2016 at 23:46, אלעזר wrote:
> >>
On Tue, Sep 20, 2016 at 1:42 PM Paul Moore wrote:
> On 20 September 2016 at 00:28, אלעזר wrote:
> > On Tue, Sep 20, 2016 at 2:20 AM Stephen J. Turnbull
> > wrote:
> >>
> >> אלעזר writes:
> >>
> >> > Another use case, though I admit not th
- is so
much better.
Elazar
On Tue, Sep 20, 2016 at 1:56 PM Paul Moore wrote:
> On 20 September 2016 at 11:46, אלעזר wrote:
> > So it should be something like
> >
> > from unsafe.__pip__ import benchmark
> >
> > Where unsafe is the hypothetical
On Tue, Sep 20, 2016 at 1:56 PM Paul Moore wrote:
>
>> On 20 September 2016 at 11:46, אלעזר wrote:
>> > So it should be something like
>> >
>> > from unsafe.__pip__ import benchmark
>> >
>> > Where unsafe is the hypothetical namespace in w
Guido, can you please elaborate?
"What's going on" is usually that the same arguments are going to be passed
over and over again, and the programmer wanted to avoid this repetition.
The other option is adjusting the function to a predefined interface.
The alternative to partial is writing a closu
On Tue, Sep 20, 2016 at 9:18 PM Stephan Houben wrote:
> I must admit I am a bit partial to partial, you can do fun things like
> this:
>
> >>> from functools import partial
> >>> @partial(partial, partial)
> ... def add(x, y):
> ... return x+y
> ...
> >>> add(3)(4)
> 7
>
> I suppose that isn'
On Tue, Sep 20, 2016 at 9:48 PM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Paul Moore writes:
>
> > I'm just saying that I don't want core Python to implicitly install
> > packages for me.
>
> +1
>
> > But that's simply a personal opinion.
>
> +0.5
>
> It's not *purely*
On Wed, Sep 21, 2016 at 12:04 AM Terry Reedy wrote:
> On 9/20/2016 11:51 AM, Guido van Rossum wrote:
>
> ... (The greater flexibility of lambda, pointed out by David Mertz, is
> another.)
>
>
I just wanted to point out that the greater flexibility of lambda is a very
good reason *not* to choose i
is outside the
whole class, it might be very far away from your logic, doing a very simple
thing that is not needed anywhere else.
Elazar
On Wed, Sep 21, 2016 at 5:32 AM Dan Sommers wrote:
> On Tue, 20 Sep 2016 15:29:36 +, אלעזר wrote:
>
> > The alternative to partial is writing
Hi all,
Annotations of function parameters and variables are evaluated when
encountered. This makes it necessary to use string representation for names
that are not yet bound, which affects almost every class definition. It is
also easy to forget, and the result might be a (very uninteresting)
exc
On Thu, Sep 22, 2016 at 9:43 PM Steven D'Aprano wrote:
> On Thu, Sep 22, 2016 at 05:19:12PM +0000, אלעזר wrote:
> > Hi all,
> >
> > Annotations of function parameters and variables are evaluated when
> > encountered.
>
> Right, like all other Python ex
On Thu, Sep 22, 2016 at 10:29 PM David Mertz wrote:
> On Thu, Sep 22, 2016 at 11:42 AM, Steven D'Aprano
> wrote:
>
>> > This makes it necessary to use string representation for names
>> > that are not yet bound, which affects almost every class definition.
>>
>> Almost every class? Really? I fin
On Thu, Sep 22, 2016 at 10:45 PM David Mertz wrote:
> On Thu, Sep 22, 2016 at 12:35 PM, אלעזר wrote:
>
>> In such a hypothetical future world we might come to allow, e.g.
>>> `Sequence[#CustomThing]` where some general lazy facility or indirection is
>>> indicated
On Thu, Sep 22, 2016 at 10:58 PM David Mertz wrote:
> On Thu, Sep 22, 2016 at 12:35 PM, אלעזר wrote:
>
>> I think we're talking about different things here. I just referred to the
>> common need to use the name of the current class in type annotation
>>
>> cla
On Thu, Sep 22, 2016 at 11:02 PM David Mertz wrote:
> On Thu, Sep 22, 2016 at 12:59 PM, אלעזר wrote:
>
>> I don't If this feature is "nice, but does not worth the complication",
>>> then so be it; I can't claim I know better. I only speculate that i
On Thu, Sep 22, 2016 at 11:02 PM David Mertz wrote:
> On Thu, Sep 22, 2016 at 12:59 PM, אלעזר wrote:
>
>> I don't If this feature is "nice, but does not worth the complication",
>>> then so be it; I can't claim I know better. I only speculate that i
On Fri, Sep 23, 2016 at 12:05 AM Ivan Levkivskyi
wrote:
> On 22 September 2016 at 22:02, אלעזר wrote:
>
>> On Thu, Sep 22, 2016 at 10:58 PM David Mertz wrote:
>>
>>> On Thu, Sep 22, 2016 at 12:35 PM, אלעזר wrote:
>>>
>>>> I think we're ta
On Fri, Sep 23, 2016 at 12:18 AM Chris Angelico wrote:
> # Recursion in functions
> def spam():
> return spam()
>
I just note that it *is* surprising, for most users, that you can't be sure
that this is a recursion, yet. So it if you want a trusted-upon recursion
you should write
# spam:
de
On Fri, Sep 23, 2016 at 4:17 AM Nick Coghlan wrote:
...
> As others have noted, the general idea of allowing either a
> placeholder name or the class name to refer to a suitable type
> annotation is fine, though - that would be a matter of implicitly
> injecting that name into the class namespace
On Fri, Sep 23, 2016 at 5:54 AM Chris Angelico wrote:
> On Fri, Sep 23, 2016 at 12:35 PM, Steven D'Aprano
> wrote:
> > The straight-forward and simple way of writing a recursive spam()
> > function surprises beginners, but they might go years or their entire
> > career without running into a sit
On Fri, Sep 23, 2016 at 6:06 AM Steven D'Aprano wrote:
> On Thu, Sep 22, 2016 at 07:21:18PM +0000, אלעזר wrote:
> > On Thu, Sep 22, 2016 at 9:43 PM Steven D'Aprano
> wrote:
> >
> > > On Thu, Sep 22, 2016 at 05:19:12PM +, אלעזר wrote:
> > > >
On Fri, Sep 23, 2016 at 6:24 AM Nick Coghlan wrote:
> On 23 September 2016 at 13:06, Steven D'Aprano
> wrote:
> > On Thu, Sep 22, 2016 at 07:21:18PM +, אלעזר wrote:
> >> "Expression" is something that you need its value right
> >> now, and "
On Fri, Sep 23, 2016 at 3:11 PM Steven D'Aprano wrote:
> On Fri, Sep 23, 2016 at 10:17:15AM +0000, אלעזר wrote:
> > On Fri, Sep 23, 2016 at 6:06 AM Steven D'Aprano
> wrote:
> > > On Thu, Sep 22, 2016 at 07:21:18PM +, אלעזר wrote:
> > > > On Thu, Se
some way, or otherwise it wasn't visible.
Again, I assume ".__annotations__" access evaluates them in the original
context.
I couldn't find any useful example yet.
Elazar
בתאריך שבת, 24 בספט' 2016, 22:07, מאת Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp&g
xcept when common sense or
documentation says otherwise. Am I wrong?
On Sun, Sep 25, 2016 at 7:07 PM Nick Coghlan wrote:
> On 25 September 2016 at 11:55, אלעזר wrote:
> > Nick, I have read your blog post about the high bar required for
> > compatibility break, and I follow thi
ompatibility break, and I follow this mailing list for a while. So I agree
with the reasoning (from my very, very little experience); I only want to
understand where is this break of compatibility happen, because I can't see
it.
Chris:
On Fri, Sep 23, 2016 at 6:59 PM Chris Angelico w
nation how small the change to fix the
> > second command is, it only matters that it *would* have to change in
> > some way.
>
> This is a bit unfair to אלעזר, although it's been a long thread so I
> can understand why some of his ideas have gone missing. His propos
On Sun, Sep 25, 2016 at 9:28 PM David Mertz wrote:
> On Sep 25, 2016 10:59 AM, "אלעזר" wrote:
> > 2. It is not naturally supported by syntax highlighters and IDEs. They
> can be made to support it, but most will not.
>
> This is a complete red herring. Havin
On Sun, Sep 25, 2016 at 10:14 PM David Mertz wrote:
> All of those might promote changes in tools. But the tools exist to aid
> working with a language, not the other way around.
>
> I can't think of a way to know that this string is code and that string is
an actual string. And figuring out mean
Thank you all. I think this thread is pretty much close by now. I
understand at least most of your concerns and I will take time to shape my
idea.
I wanted to note one last thing, though, regarding my claim that
annotations are not actually standard expressions: Guido had once expressed
his concer
You already know I want this for contracts etc.. Here some things that I
consider important:
1. There should be some way to bind the names to function parameters, as in
@contract
def invert(x: `x != 0`) -> float: return 1 / x
@contract
def invertdiff(x: int, y: `x != y`) -> float
"Bash on Ubuntu on windows" responds to CTRL+D just fine. I don't really
know how it works, but it looks like it is based on the Windows terminal
emulator.
Elazar
בתאריך יום ה׳, 29 בספט' 2016, 06:36, מאת Chris Angelico :
> On Thu, Sep 29, 2016 at 12:04 PM, Steven D'Aprano
> wrote:
> > (Also, i
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
It is a real problem. People are used to write `seq == [1, 2, 3]` and it
passes unnoticed (even with type checkers) that if seq changes to e.g. a
tuple, it will cause subtle bugs. It is inconvenient to write `len(seq) ==
3 and seq == [1, 2, 3]` and people often don't notice the need to write it.
(
On Thu, Oct 6, 2016 at 5:53 PM Sjoerd Job Postmus
wrote:
> On Thu, Oct 06, 2016 at 02:45:11PM +0000, אלעזר wrote:
> > It is a real problem. People are used to write `seq == [1, 2, 3]` and it
> > passes unnoticed (even with type checkers) that if seq changes to e.g. a
> >
The name might be a little confusing; it can be understood as comparing two
sequences, so passing two sequences may seem reasonable to a reviewer.
Elazar
בתאריך יום ה׳, 6 באוק' 2016, 20:15, מאת Filipp Bakanov :
> Seems like itertools recipes already have "all_equal" function. What do
> you thin
I thought about it a lot recently. Specifically on your proposal, and in
general. Unpacking expression can have a much more uniform treatment in the
language, as an expression with special "bare tuple" type - like tuple, but
"without the braces".
It also gives mental explanation for the conditiona
Steve, you only need to allow multiple arguments to append(), then it makes
perfect sense.
בתאריך יום ד׳, 12 באוק' 2016, 18:43, מאת Steven D'Aprano <
st...@pearwood.info>:
> On Tue, Oct 11, 2016 at 02:42:54PM +0200, Martti Kühne wrote:
> > Hello list
> >
> > I love the "new" unpacking generalisa
What is the intuition behind [1, *x, 5]? The starred expression is replaced
with a comma-separated sequence of its elements.
The trailing comma Nick referred to is there, with the rule that [1,, 5] is
the same as [1, 5].
All the examples follow this intuition, IIUC.
Elazar
בתאריך יום ד׳, 12 באו
On Wed, Oct 12, 2016 at 11:26 PM David Mertz wrote:
> On Wed, Oct 12, 2016 at 12:38 PM, אלעזר wrote:
>
> What is the intuition behind [1, *x, 5]? The starred expression is
> replaced with a comma-separated sequence of its elements.
>
> I've never actually used the
On Wed, Oct 12, 2016 at 12:38 PM, אלעזר wrote:
>
> What is the intuition behind [1, *x, 5]? The starred expression is
> replaced with a comma-separated sequence of its elements.
>
> I've never actually used the `[1, *x, 5]` form. And therefore, of course,
> I've never tau
On Thu, Oct 13, 2016 at 2:35 AM Steven D'Aprano wrote:
> On Wed, Oct 12, 2016 at 04:11:55PM +0000, אלעזר wrote:
>
> > Steve, you only need to allow multiple arguments to append(), then it
> makes
> > perfect sense.
>
> I think you're missing a step. What will
On Thu, Oct 13, 2016 at 5:10 PM Steven D'Aprano wrote:
> On Thu, Oct 13, 2016 at 10:37:35AM +0200, Sven R. Kunze wrote:
> > About the list constructor: we construct a list by writing [a,b,c] or by
> > writing [b for b in bs]. The end result is a list
>
> I construct lists using all sorts of ways:
On Thu, Oct 13, 2016 at 6:19 PM Paul Moore wrote:
> On 13 October 2016 at 15:32, Sven R. Kunze wrote:
> > Steven, please. You seemed to struggle to understand the notion of the
> > [*] construct and many people (not just me) here tried their best to
> > explain their intuition to you.
>
> An
On Thu, Oct 13, 2016 at 11:42 PM Paul Moore wrote:
> I remain puzzled.
>
> Given the well-documented and understood transformation:
>
> [fn(x) for x in lst if cond]
>
> translates to
>
> result = []
> for x in lst:
>if cond:
> result.append(fn(x))
>
> please can you explain how to modif
On Thu, Oct 13, 2016 at 11:59 PM Paul Moore wrote:
> On 13 October 2016 at 21:47, אלעזר wrote:
> > if you allow result.append(1, 2, 3) to mean result.extend([1,2,3]) #
> which
> > was discussed before
>
> I don't (for the reasons raised before). But thank y
On Fri, Oct 14, 2016 at 12:06 AM Neil Girdhar wrote:
> Regarding Steven's example, like Sven, I also see it this way:
>
> [*t for t in [(1, 'a'), (2, 'b'), (3, 'c')]]
>
> should mean:
>
>[*(1, 'a'), *(2, 'b'), *(3, 'c')]]
>
> Which coincides with what the OP is asking for.
>
>
>From a C
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
*Semantics:*
(In the following, f(x) must always evaluate to an iterable)
בתאריך יום ו׳, 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 s
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 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 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
> overloa
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 her
But the proposal has explicit syntax that point the reader to the fact that
the invariant doesn't hold. Same as other unpacking occurences:
[x, *y]
The invariant does not hold. And that's explicit.
Elazar
בתאריך יום ב׳, 17 באוק' 2016, 21:16, מאת Brendan Barnwell <
brenb...@brenbarn.net>:
> On
On Mon, Oct 17, 2016 at 9:49 PM David Mertz wrote:
...
> Moreover, this "magical flatten" operator will crash in bad ways that a
> regular flatten() will not. I.e. this is fine (if strange):
>
> >>> three_inf = (count(), count(), count())
> >>> comp = (x for x in flatten(three_inf))
> >>> next(c
On Mon, Oct 17, 2016 at 11:13 PM Paul Moore wrote:
...
> 2. Can someone summarise the *other* arguments for the proposal? I'm
> genuinely struggling to recall what they are (assuming they exist).
My own argument was uniformity: allowing starred expression in other
places, and I claim that the N
On Sat, Nov 12, 2016 at 9:10 PM David Mertz wrote:
>
> dfmi.loc[slice[:,:,['C1','C3']], slice[:,'foo']]
>
>
> I like the change proposed to `str(slice(10))` also... and it would be way
> better if `slice[:10]` were actual "syntax." In fact, in that case it
> could even be the repr().
>
>
Indexin
On Sat, Nov 12, 2016 at 10:08 PM João Matos wrote:
>
> What I would like to propose is the creation of the reverse:
> a =+ c is the same as a = c + a
>
a =+5 already means a becomes 5
> a =- c is the same as a = c - a
>
a =-5 already means a becomes -5
Elazar
I think such proposals are special cases of a general theme: a compiler
pragma, similar to "from __future__", to make Python support
domain-specific syntax in the current file. Whether it's decimal literals
or matrix/vector literals etc.
I think it will be nice to make some tool, external to Pytho
The title is misleading : it should be "nesting function calls"
Elazar
בתאריך שבת, 28 בינו' 2017, 18:38, מאת Ed Kellett :
> On Sat, 28 Jan 2017 at 14:27 zmo via Python-ideas
> wrote:
>
> I agree this would look a bit more elegant. To focus on the feature of
> that operator, instead of how to w
On Wed, Mar 1, 2017 at 9:26 PM Serhiy Storchaka wrote:
> On 28.02.17 23:17, Victor Stinner wrote:
> > My question is: would it make sense to implement this feature in
> > Python directly? If yes, what should be the syntax? Use "/" marker?
> > Use the @positional() decorator?
>
>
> The problem
This suggestion is really problematic IMHO.
"isinstance" is a nominal check. I can't ask "isinstance(x, Callable[int,
int])" because that would imply solving the halting problem. so
"isinstance(x, Y)" does not mean "is it true that x is an element of the
type Y" but rather "is it true that x was c
Here's a proof-of-concept for the decorator. It does not address the issue
of passing aliases to positional arguments to **kwargs - I guess this
requires changes in the CPython's core.
(Sorry about the coloring, that's how it's pasted)
from inspect import signature, Parameter
from functools impor
On Mon, May 15, 2017 at 6:30 PM Guido van Rossum wrote:
> This should be worked into a PEP, instead of living on as a bunch of
python-ideas posts and blogs.
...
> Will someone please write a PEP?
If by "this" you mean adding to stdlib something like
@record
class Point:
x: int
y: int
o
1 - 100 of 120 matches
Mail list logo
