deas.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-ideas@python.org/message/46U433BTSAKCZKCNFUQGYDSC6GV5S35A/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him/his **(why is my pronoun here?)*
<h
n axis
label it could become somewhat ugly.
With all that in mind, and without any promises, I do think it would be
cool if you could code up a prototype and see how it feels. Good luck!
--Guido
On Sat, Jul 13, 2019 at 12:36 PM Nima Hamidi wrote:
> Hello all,
>
>
> I would like to
ch can be interrupted --
IIRC Victor spent a lot of time making this work). There's a workaround
(specify a timeout) but this is still something that would have to be
solved for this to be useful.
--
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him/his **(why is my pronoun here?)*
&l
r a server to return a response which just
isn't ever going to come, but the connection somehow is kept open by the
other side?
--
--Guido van Rossum (python.org/~guido)
Pronouns: he/him/his (why is my pronoun here?)
___
Python-ideas mailing list -
t;
> Symbols CAN be searched for, both in Google and in many documentation
> tools.
>
It's still harder. E.g. the wikipedia article on subtyping does not show in
the search results for "<:", and searching for "<: wikipedia" ignores the
"<:" entire
On Mon, Jun 17, 2019 at 12:54 PM Andrew Barnert wrote:
> On Jun 17, 2019, at 07:47, Guido van Rossum wrote:
>
> On Mon, Jun 17, 2019 at 7:23 AM Rhodri James wrote:
>
>> On 16/06/2019 03:34, Guido van Rossum wrote:
>> > I don't actually know how viable this
On Mon, Jun 17, 2019 at 7:23 AM Rhodri James wrote:
> On 16/06/2019 03:34, Guido van Rossum wrote:
> > I don't actually know how viable this proposal is, but given that it's
> > being debated at some length, I'd like to put in my opinion that *if*
> > we
ed in other languages (e.g.
Scala) and notational systems (https://en.wikipedia.org/wiki/Subtyping).
Overloading '<=' would be easier to implement, but would also cause enough
confusion that I think we should avoid it at all cost.
--
--Guido van Rossum (python.org/~guido)
*Pron
On Mon, May 6, 2019 at 11:14 AM Serhiy Storchaka
wrote:
> 06.05.19 17:49, Guido van Rossum пише:
> > 20-25 years ago this might have been a good idea. Unfortunately there's
> > so much code (including well-publicized example code) that I'm not sure
> > it's a
y-value pairs.
> Uses __iter__() instead of keys() for iterating keys, and can take an
> optional iterable of keys. Equals to {k: m[k] for k in m} or {k: m[k]
> for k in keys}.
> * dict.fromitems() -- accepts only key-value pairs. Equals to {k: v for
> k, v in iterable}.
>
>
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
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
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/>
___
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.
-
function, although I'm not 100% sold on the
> > name "output".
>
>get_output ?
>
> > ChrisA
>
> Oleg.
> --
> Oleg Broytmanhttps://phdru.name/p...@phdru.name
>Programmers don't die, they just GOSUB without RETURN.
> __
sing as the main candidate that fits this bill.
>>>>
>>>> What do you say?
>>>>
>>>> Thanks!
>>>> Nam
>>>> ___
>>>> Python-ideas mailing list
>>>> Python-ideas@py
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
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/
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
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
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
&
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 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
> 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/
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)
___
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
>
&
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
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
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/
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/
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/
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
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/
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
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
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/
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
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
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
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
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;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
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.
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
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/
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
use something that's missing, it'll call that to generate a
>> value.
>>
>> from collections import defaultdict
>> d = defaultdict(list)
>> for category, item in some_stuff:
>> d[category].append(item)
>>
>> Easy way to group things into
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/
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 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
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
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
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/~
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
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)
__
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)
_
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/~
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
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/
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
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
__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
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/
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().
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/
On Mon, Jul 2, 2018 at 12:50 AM Michael Selik wrote:
>
> [Guido]
>
>> You'll never get consensus on anything here, but you have my blessing for
>> this without consensus.
>>
>
> That feels like a success, but I'm going to be a bit more ambitious and
&g
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
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
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
like
this? It would be nice not to have to invent this wheel. Eventually a PEP
and an implementation should be presented, but first the idea needs to be
explored more.
--Guido
On Wed, Jun 27, 2018 at 3:30 PM Andrei Kucharavy
wrote:
> Over the last 10 years, Python has slowly inched towards
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
> 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/
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/
t the response will
also be the same.
--Guido
On Tue, Jun 26, 2018 at 8:00 AM Eloi Gaudry wrote:
> the origin of this feature disappearing for built-in types:
>
> http://bugs.jython.org/issue1058
>
>
> '''
>
> object.__set/delattr__ allow modification of built
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/
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
; 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)
__
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
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 пише:
>
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?
>
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
a Tree you know that
you have a Tree (because it has other unique methods) then there's no
burden for the user to call x.min().
--Guido
On Wed, Jun 20, 2018 at 5:24 AM James Edwards wrote:
> > Are there any builtins or std library classes that offer their own
> min()/max() methods?
&
ust trying to see if the core dev team has spare cycles to
implement this for you?
--Guido
On Tue, Jun 19, 2018 at 3:56 PM Micheál Keane
wrote:
>
> Add a function to generator objects to copy the entire state of it:
>
> Proposed example code:
>
> game1 = complicated_game_type_thi
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
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
> __
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
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
>
> _
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
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
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
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/
x27;w'):
> of.write(\if.read())
>
> maybe even nicer than if_.
>
> Some examples:
>
> result = \except + 1
>
> result = something.\except
>
> result = \except.\finally
>
>
> --
> Steve
> ___
> Py
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/
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
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/
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
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
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
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
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)
501 - 600 of 912 matches
Mail list logo