S3. Comprehensions and generator expressions should be interchangeable.
They just look too similar to have different semantics (and the possibly
delayed execution of generator expressions is not an issue -- it's rare,
and closure semantics make it work just fine).
--
--Guido van Rossu
s off he doesn't
want to incur the overhead of evaluating the check. The assert statement
has the latter property, but you have to use -O to turn it off. He
basically wants a macro so that
runtime_assert()
expands to
if and ():
raise AssertionError
In Lisp this would be easy
On Tue, May 8, 2018 at 12:29 AM, Eloi Gaudry wrote:
> On Mon, 2018-05-07 at 10:52 -0700, Guido van Rossum wrote:
> > On Mon, May 7, 2018 at 6:24 AM, Serhiy Storchaka > > wrote:
> > > I just don't understand why you need a new keyword for writing
> > > run
eating a second p in the containing scope -- either way it's
probably a typo anyway.
:= outside a comprehension/genexpr is treated just like any other
assignment (other than in-place assignment), i.e. it creates a local unless
a nonlocal or global declaration exists.
--
--Guido van
ver having to deal with
ambiguities like `a, a+1 for a in range(10)` or `a for a in x, y`.)
Another alternative would be to always require parentheses around `:=`, so
that we would have to write `f((a := 1), 1)`. That's unambiguous, but
otherwise just gets on the nerves.
--
--Guido van Rossum
On Wed, May 9, 2018 at 8:42 PM, Chris Angelico wrote:
> On Thu, May 10, 2018 at 1:33 PM, Guido van Rossum
> wrote:
> > (I vaguely recall this has been brought up before, but I'm too lazy to
> find
> > the subtread. So it goes.)
> >
> > PEP 572 curren
On Thu, May 10, 2018 at 5:17 AM, Nick Coghlan wrote:
> On 9 May 2018 at 03:06, Guido van Rossum wrote:
>
>> So the way I envision it is that *in the absence of a nonlocal or global
>> declaration in the containing scope*, := inside a comprehension or genexpr
>> causes t
an attempting to restrict the construct purely to
> if/elif/while.
>
> Even as a generally available postfix keyword, "given" should still be
> amenable to the treatment where it could be allowed as a variable name in a
> non-operator contex
On Thu, May 10, 2018 at 3:32 AM, Terry Reedy wrote:
> On 5/9/2018 11:33 PM, Guido van Rossum wrote:
>
> I now think that the best way out is to rule `:=` in the top level
>> expression of an expression statement completely
>>
>
> I would like to be able to interactive
end I think they should be called "assignment
expressions" just like in C.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
repeated many
> times in the various email chains. (I preferred it as "as", but that's been
> struck down already) (and if it's between ":=" and not having them at all,
> I would rather just not have them)
>
>
--
--Guido van Rossum (python.org/~guido)
I have to agree with David that this seems too specialized to make room for
in the stdlib.
On Thu, May 10, 2018, 15:16 David Mertz wrote:
> This feels specialized enough to belong in a third party library. If that
> library can behave as transparently as possible interacting with Python
> dateti
Yes.
On Thu, May 10, 2018, 13:18 Alexander Belopolsky <
alexander.belopol...@gmail.com> wrote:
> On Thu, May 10, 2018 at 9:44 AM, Guido van Rossum
> wrote:
> > I'm sorry, but unless there's a sudden landslide of support for 'given'
> in
> > fav
TE6
>> 18 POP_BLOCK
>> 20 LOAD_CONST 0 (None)
22 RETURN_VALUE
But for a generator:
g = (x for x in C())
1 0 LOAD_FAST0 (.0)
>>2 FOR_ITER10 (to 14)
4
Maybe you could propose some kind of syntax using "whereas"? (It can be
used as a preamble.)
On Fri, May 11, 2018 at 3:05 AM, Greg Ewing
wrote:
> Guido van Rossum wrote:
>
>> I'd need well-reasoned explanations
>>
>
> My reasoning is essentially the same a
uage designers could
talk about such topic with as much confidence as they talk about the
efficiency of hash tables.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/
to diagnose.
I should also mention that this was inspired from some messages where Tim
Peters berated the fashion of using "reserved words", waxing nostalgically
about the old days of Fortran (sorry, FORTRAN), which doesn't (didn't?)
have reserved words at all (nor signifi
I hereby withdraw the idea.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
x27;w'):
> of.write(\if.read())
>
> maybe even nicer than if_.
>
> Some examples:
>
> result = \except + 1
>
> result = something.\except
>
> result = \except.\finally
>
>
> --
> Steve
> ___
> Py
nds.
Maybe Python can set a new trend. It's happened before. :-)
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
dable based on hard facts alone, and
hard but incredibly subtle facts related to the rest of the language's
design and implementation (including the state of tooling and the structure
of the compiler used as a reference implementation).
So let's just end
This sounds fine to me. For type hint s we did a similar thing with PEPs
482, 483 and 484. You probably want to make everyone involved a co-author.
On Tue, May 22, 2018, 14:29 Jeroen Demeyer wrote:
> Hello,
>
> Both PEP 573 and PEP 575 deal with built-in functions. Additionally,
> some people (S
Yes. What Steve says at the end. Let's be kind and mention this one on the
release notes. But not all the others.
On Tue, May 29, 2018, 07:57 Steven D'Aprano wrote:
> On Tue, May 29, 2018 at 05:37:06PM +0300, Serhiy Storchaka wrote:
>
> > We have removed over 100 module attributes in 3.6 [2] and
rtunately provides some good precedent there, but it does
> mean this feature would need to be implemented as its own API, rather than
> as an option on shutil.chown.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
>
> _____
gt; On 5/29/2018 12:09 PM, Guido van Rossum wrote:
>
>> Yes. What Steve says at the end. Let's be kind and mention this one on
>> the release notes. But not all the others.
>>
>
> How about adding a general reminder. In Porting to 3.7:
>
> "Imports into
then that would wrongly
> be detected as a non-public import.
>
> But most problematic, it does nothing about this case:
>
> import os
> os.errno
>
> I think this is best left for linters.
>
>
> --
> Steve
> ______
o create the instance
>> before we can decide whether or not the raised
>> exception matches the given exception handler criteria.
>>
>
> Why is this? Doesn't the exception have to be instantiated at some point,
> even if just to print to stderr?
>
Not if it gets
gt; <https://pypi.org/project/generator_tools/> that purports to do this. I
> haven't tried it yet to see if it still works in 2.x and it appears beyond
> my skill level to port to 3.x.
>
> PyPy & Stackless Python apparently support this within certain limits?
>
>
> Thoughts?
>
>
&
>
>>
>> --
>> Steve
>> ___
>> Python-ideas mailing list
>> Python-ideas@python.org
>> https://mail.python.org/mailman/listinfo/python-ideas
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
function. And similar for classmethod.
>
> (Of course calling classmethod instances directly won't work unless you
> provide the class argument. But that's just a simple matter of bound
> versus unbound methods.)
>
>
> --
> Steve
> ___
> Python-ideas ma
On Wed, Jun 20, 2018 at 9:31 AM Serhiy Storchaka
wrote:
> 20.06.18 19:20, Guido van Rossum пише:
> > +1 -- when we introduced these we didn't see the use case so clearly,
> > but it definitely exists.
>
> How would you call a classmethod descriptor in this case?
>
On Wed, Jun 20, 2018 at 10:03 AM Serhiy Storchaka
wrote:
> 20.06.18 19:37, Guido van Rossum пише:
> > On Wed, Jun 20, 2018 at 9:31 AM Serhiy Storchaka
> > > <mailto:storch...@gmail.com>> wrote:
> >
> > 20.06.18 19:20, Guido van Rossum пише:
>
eas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
; And yes I'm a little bit disappointed because it reduces the benefit of
> my idea a lot.
>
Why would you be disappointed? Aren't you happy that you get much of the
benefit without having to do any work?
--
--Guido van Rossum (python.org/~guido)
__
tically flagged to be wiped). Downside:
> You can't say "I'm done with this string, destroy it immediately".
>
> ChrisA
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mai
eedn't either.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
t; neither implicitly nor explicitly ?
>
> I mean, our types are built-in and should be considered as immutable
> across interpreters. And we (as most users I guess) are only running
> one interpreter.
>
> In case several intepreters are used, it would make sense to have a
> non
p://python-security.readthedocs.io/security.html#security-model
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
gt; should be enum members, and cases where nested classes should not be
> members.
>
> Thanks!
>
> --
> ~Ethan~
> ___________
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
r*
> * Lab*Johns Hopkins University, Baltimore, USA.
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
for more
information.
>>>
It makes total sense to add citations/references to this list (and those
should probably print a reference for Python followed by instructions on
how to get references for other packages and how to properly add a
referenc
ent)
>>>
>>
>> Thank you for bringing this up. I've been drafting a proposal for a
>> better grouping / group-by operation for a little while. I'm not quite
>> ready to share it, as I'm still researching use cases.
>>
>> I'm +1 that t
On Fri, Jun 29, 2018 at 3:23 PM Michael Selik wrote:
> On Fri, Jun 29, 2018 at 2:43 PM Guido van Rossum wrote:
>
>> On a quick skim I see nothing particularly objectionable or controversial
>> in your PEP, except I'm unclear why it needs to be a class method on
t; try to persuade you that `grouping` belongs in the built-ins. I revised my
> draft to streamline the examples and make a clearer comparison with
> existing tools.
>
Sorry, I'm not biting. This will not be a builtin nor a method on a
builtin. I'm going to mute this thread be
ou everybody for you valuable feedback! I really appreciate your
> time helping me thinking this through :)
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
cannot
>> c = [6, 7, 8] # cannot
>>
>> Disassemble this or look at f.__code__.co_consts and you'll see (1, 2,
>> 3) as a single constant; but the others have to be built.
>>
>> +1 on set.freeze(); +0 on bytes.to_bytearray().
7;t need a metaclass -- it can be implemented as
__class_getitem__.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
__iadd__ pairwise. But I am not so keen,
because the ambiguity of `a, b, c += x`.
Perhaps someone can do some research and unearth real code that contains
series of += assignments that would become more readable by collapsing them
into a single line using the proposed construct.
--
--Guido van
llow top-level function calls to be written without parentheses,
but it was too hard to make it unambiguous (e.g. would "foo +1" mean
"foo(+1)" or "foo + 1"?)
--
--Guido van Rossum (python.org/~guido)
___
Python-idea
On Fri, Aug 31, 2018 at 4:04 AM, David Mertz wrote:
> On Thu, Aug 30, 2018 at 9:41 PM Guido van Rossum wrote:
>
>> On Fri, Aug 31, 2018 at 3:19 AM, Michael Selik wrote:
>>
>>> On Thu, Aug 30, 2018 at 5:31 PM James Lu wrote:
>>>
>>>> It would
nadian
actress named Samantha Quan.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
elp prospective
authors based on the text they show us.
I have to admit that I've not followed the full context, but I recommend
that you try to see that other posters in this thread are trying to help
with kindness, not judging you or your skills
Gah! You are overthinking it. This idea is only worth it if it's dead
simple, and the version that Eric posted to start this thread, where !d
uses the repr() of the expression, is the only one simple enough to bother
implementing.
--
--Guido van Rossum (python.org/~
to
> the empty coffee pot.
>
> --
> Jonathan
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
_
k
> with YAML or perhaps something even simpler than either one.
>
I feel the same way. (Somebody was requesting extensive TOML support for
mypy and was also waving those PEPs in front of us.)
--
--Guido van Rossum (python.org/~guido)
__
lement new objects (without
> dependency to "Path")
> that are implementing the __fspath__ protocol.
>
> robert
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/pytho
dlock.
Nathaniel, would you be able to elaborate more on the issue of
backpressure? I think a lot of people here are not really familiar with the
concepts and its importance, and it changes how you have to think about
queues and the like.
--
--Guido van Rossum (python.org/~
ause
because there's no trouble with switching between expression-mode and
statement-mode. Also note that syntactically it is clearly a special form
of `def` statement -- it can even be decorated!
So let's review the proposal as a shorthand for defining a function and
immediate
e") the use case is just much narrower.
So unless we find more use cases, or until we can convince ourselves that
we can use `def (args): block` in all expression contexts, I guess it'll
have to remain an idea. Thank you though! It was a fascinating one.
--
--Guido van Rossum (python.org/~guido
ed with static type checking (PEPs 484, 526, 544, 561) it may be
PEP-worthy.
As a compromise, perhaps some discussion can take place in the issue
tracker of the repo (https://github.com/guettli/python-name2type-mapping)
Thomas created? If someone with PEP experience is interested they can guide
T
ns "__subclasses__() -> list of
> immediate subclasses"
>
> To fully figure out what it did, I had to read the source code to Python
> -- which really is not the best way to figure out what a function does;
> hence the request to document it (and indicate it's fut
ed
> with as.
>
> Thanks,
>
> David
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
The two are less connected than you seem to think.
On Thu, Nov 1, 2018 at 7:08 PM Alex Shafer wrote:
> I had actually managed to miss collections.defaultdict!
>
> I'd like to instead propose that a reference to that be added to the
> dict.setdefault docs. I can't imagine I'm the only one that ha
instance is created, while
setdefault() is used when inserting a value.
A major issue IMO with defaultdict is that if you try to *read* a
non-existing key it will be inserted.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Pyt
them, I think other stdlib libraries are
not beholden to that behavior.)
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
dea. After all, we have
`list.extend(x)` ~~ `list += x`. The key conundrum that needs to be solved
is what to do for `d1 + d2` when there are overlapping keys. I propose to
make d2 win in this case, which is what happens in `d1.update(d2)` anyways.
If you want it the oth
x27; + 'a'.
For non-numbers we only require + to be associative, i.e. a + b + c == (a +
b) + c == a + (b + c).
That is satisfied for this proposal.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.
x27;b': 3})
>
> At first I worried that changing base dict would cause confusion for the
> subclass, but Counter seems to share the idea that update and + are
> synonyms.
>
Great, this sounds like a good argument for + over |. The other argument is
that | for sets
erested in
sponsoring the PEP. And I'm not it. Is there a core dev who is interested
in sponsoring or co-authoring this PEP?
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman
x27;t in d2.
>
>
>
> --
> Steven
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (p
On Wed, Feb 27, 2019 at 11:18 PM Serhiy Storchaka
wrote:
> 27.02.19 20:48, Guido van Rossum пише:
> >
> > On Wed, Feb 27, 2019 at 10:42 AM Michael Selik
> > > <mailto:m...@selik.org>> wrote > The dict subclass
> collections.Counter overrides the
e of Conduct: http://python.org/psf/codeofconduct/
> >
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido
is highly non-obvious except if you've already encountered that
pattern before, while d1+d2 is what anybody familiar with other Python
collection types would guess or propose. And the default semantics for
subclasses of dict that don't override these are
d list + list, so this seems an unwarranted worry to me.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
On Mon, Mar 4, 2019 at 12:12 PM Neil Girdhar wrote:
> On Mon, Mar 4, 2019 at 2:26 PM Guido van Rossum wrote:
> >
> > * Dicts are not like sets because the ordering operators (<, <=, >, >=)
> are not defined on dicts, but they implement subset comparisons for s
Honestly I would rather withdraw the subtraction operators than reopen the
discussion about making dict more like set.
On Mon, Mar 4, 2019 at 12:33 PM Neil Girdhar wrote:
> On Mon, Mar 4, 2019 at 3:22 PM Guido van Rossum wrote:
> >
> > On Mon, Mar 4, 2019 at 12:12 PM Neil G
g naming conventions or type annotations.
> Those two points make me uncomfortable with "+=" strictly behaving
> like ".update()".
>
And yet that's how it works for lists. (Note that dict.update() still has
capabilities beyond +=, since you can also invoke it with keyword args.)
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
gs):
> self.update(*argv, **kwargs)
> return self
>
> def copy(self):
> return self.__class__(self)
>
> A DIRTY HACK
> Not tested, using an assignment expression.
>dict_arg = (tmp := defaults.copy(), tmp.update(optio
nted
without hashing, e.g. using a balanced tree, so that it could support
unhashable keys).
If there's doubt about this anywhere, we could add an example to the docs
and to the PEP.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
t as long as they are
*strings* such keys should be allowed.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
rst, none of the other situations I listed
above raises for conflicts. Second, there's the experience of str+unicode
in Python 2, which raises if the str argument contains any non-ASCII bytes.
In fact, we disliked it so much that we changed the language incompatibly
to deal with it.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
y
> > other obvious meaning that + and * could have for sets.
>
> The language SETL (the language of sets) also uses + and * for set
> operations.¹
>
So the secret is out: Python inherits a lot from SETL, through ABC -- ABC
was heavily influenced by SETL.
> ¹ https://www.li
e better.
NOTE: I'm not picking on you specifically Chris! I see this a lot, and I do
it myself too (and regularly regret it).
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/m
recall, in SGML the first value "original" is the one that is
> in effect. This is what happens with the LaTeX command
> \providecommand.
>
> FURTHER LINKS
> [6]
> https://docs.python.org/3/reference/expressions.html#dictionary-displays
> [7] https://cwe.mitre.org/data/definitions/561.html # CWE-561: Dead Code
>
&
ibed)
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
___
> In the spirit of full disclosure:
> Of these, 2 is already implemented and widely used, so we don't need
> to use dict.__add__ for that. I've never seen 4 in the mathematical
> literature (union of relations is not the same thing). 3, however, is
> very common both for mappings with small domain and sparse
> representation of mappings with a default value (possibly computed
> then cached), and "|" is not suitable for expressing that sort of
> addition (I'm willing to say it's "wrong" :-).
>
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
On Fri, Mar 8, 2019 at 3:33 PM Greg Ewing
wrote:
> Guido van Rossum wrote:
> > I guess this explains the behavior of removing results <= 0; it makes
> > sense as multiset subtraction, since in a multiset a negative count
> > makes little sense. (Though the name Counter c
r me this is the default assumption (even at
Dropbox -- our most performance critical code has already been rewritten in
ugly Python or in Go). For the few cases where performance concerns are
paramount, it's easy to transform the operator version to something else --
*once you've confirmed i
On Fri, Mar 15, 2019 at 9:19 PM Inada Naoki wrote:
> On Sat, Mar 16, 2019 at 2:51 AM Guido van Rossum wrote:
> >
> > But I think that the folks who point out "there is already a way to do
> this" are missing the point that it really is easier to grasp the meaning
&
elling, then I think
> this proposal is the best: explicit, unambiguous, immediately
> understandable and easy to remember.
>
I don't find it easy to understand or remember that d1.update(d2) modifies
d1 in place, while d1.merge(d2) first copies d1.
Maybe the name can
not much of a
reason to try and introduce a mechanism to disable type hints. Sorry.
PS. This particular syntax was introduced by PEP 526, and introduced in
Python 3.6.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas
nd
> many more bugs.
>
> SUMMARY
>
> I have argued that Python's core design decisions and coding principles
> can, at least in part, be reduced to a system of AXIOMS that can be useful
> applied. I have argued mainly based on analogy with the Hindu-Arabic
> numeral system, and the life and work of Gauss.
>
>
>
>
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
ategory error.
>
I assume the whole proposal was a pastiche of the proposal to add a +
operator for dictionaries. Jonathan needs to come clean before more people
waste their time discussing this.
--
--Guido van Rossum (python.org/~guido)
___
Pyt
sing as the main candidate that fits this bill.
>>>>
>>>> What do you say?
>>>>
>>>> Thanks!
>>>> Nam
>>>> ___
>>>> Python-ideas mailing list
>>>> Python-ideas@py
Let’s please leave this alone. As Serhiy says run() covers everything.
On Thu, Apr 4, 2019 at 3:03 AM Oleg Broytman wrote:
> On Thu, Apr 04, 2019 at 07:44:29PM +1100, Chris Angelico
> wrote:
> > On Thu, Apr 4, 2019 at 7:12 PM Nathaniel Smith wrote:
> > >
> > > On Thu, Apr 4, 2019 at 12:48 AM G
a list of
comma-separated items for the last comma, a fully-qualified module name for
the last period, and some ad-hoc parsing of other things. The "last
separator" use cases are the most common and here rindex() sounds very
useful.
-
lman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him/his **(why is my pronoun here?)*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
___
irst time posting an idea to python-ideas. So apologies if i
> am not following some conventions that i might not be aware of.
> Vaibhav Karve
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinf
re = data[max(0, index - 1)]
after = data[min(len(data) - 1, index)]
return (before + after) / 2.0
where `data` is a sorted array. Essentially we use the average of the two
values nearest the cutoff point, except for edge cases. (I think we could
do better, but this is the code I found in our
301 - 400 of 910 matches
Mail list logo
