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/
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
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 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
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
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
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
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
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
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
ectly clear to me
what you are proposing) but for real-world code that would benefit from
this addition to the itemgetter API.
--Guido
On Wed, May 2, 2018 at 1:08 AM, Vincent Maillol
wrote:
> Hi everybody,
>
> Our PEP idea would be to purpose to add a global default value for
> itemge
. But there would
> be some costs here; the trade-off would be a significant
> simplification and increase in usability, because regular users could
> simply stop having to know about 'coroutine objects' and 'awaitables'
> and all that entirely, and we'd be able to take more advantage of
> async/await in existing libraries.
>
> What do you think?
>
> -n
>
> [1] https://mail.python.org/pipermail/async-sig/2018-May/000484.html
> [2] https://mail.python.org/pipermail/async-sig/2018-April/000470.html
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> ___
> 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/
ge in Python's
> >>> life, adding new _reserved_ words "should be" an extremely high bar -
> >>> but adding new non-reserved keywords (like "async") should be a much
> >>> lower bar.
> >
> > [Guido]
> >> Do note that thi
;
shouldn't be exaggerated. Currently you can search for "python operators"
and get tons of sites that list all operators.
I also note that Google seems to be getting smarter about non-alphabetic
searches -- I just searched for "python << operator" and the first hit
h runs into a different
> set of problems related to trying to use "with" for two distinct and
> entirely unrelated purposes).
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
>
> ___
s. If I've learned one thing
from PEP 572 it's that we need to adjust how we discuss and evaluate
proposals. I'll think about this and start a discussion at the Language
Summit about this.
--
--Guido van Rossum (python.org/~guido)
___
On Wed, Apr 25, 2018, 02:13 Jacco van Dorp wrote:
> ... Which is where the auto-completion comes in. ...
>
Designing the language with auto-complete in mind feels wrong to me. It
assumes a very sophisticated IDE and may lead to lazy design compromises.
-
o, the stdlib should not depend on Cython, no matter how great. That would
be a terrible dependency cycle.
--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/
But to the OP, this is not considered a bug.
On Sat, Apr 21, 2018, 07:59 Serhiy Storchaka wrote:
> 21.04.18 17:47, Chris Angelico пише:
> > On Sat, Apr 21, 2018 at 10:29 PM, Serhiy Storchaka
> wrote:
> >> 21.04.18 13:42, Chris Angelico пише:
> >>>
> >>> What you're seeing there is actually the
; `target ? expr` could mean `expr if target else target`. Other proposal for
> null/boolean checking might need `?`, let's preserve `?` character for
> further development.
>
The only acceptable use of ? is formulated in PEP 505.
--
--Guido van Rossum (python.org/~guido)
__
reason I strongly prefer := as inline assignment operator.
> But somehow this PEP does not mean it! And with the current rationale of
> this PEP it's a huge CON for me that `=` and `:=` feel and look the same.
>
Then maybe the PEP needs to be update
bove where I'd pronounce it as "into")
>
> The connection with function declarations would be a little tenuous,
> but could be rationalised as:
>
> Given the function declation:
>
> def f(...) -> Annotation:
> ...
>
> Then in the named subexpre
nd
you can use assignment in expressions too, except there you must use :=
because = would be too easily confused with ==".
Ideally this would allow all forms of = to be replaced with :=, even
extended structure unpacking (a, b, *c := foo()).
--
--Guido van Rossum (py
if (x ;= i) + 1:
>>
>> On the third hand, requiring parentheses all the time would also feel
>> strained:
>>
>> while m := someregexp.match(somestring):
>>
>> is already impossible to misread.
>>
>> Annoying ;-)
>>
>
> ___
> 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() is None else var.method()
>
> Still not bad looking.
>
Though a long way from function()?.method() per PEP 505. :-)
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.pytho
tract class breaks an interface.
>
> We will be able to pass this path (we have already passed it), but we must
> realize how long it is.
>
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/m
)(*c)
>
> _______
> 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/
read and grep.
>
> It allows for creating a flattened dict from an iterable of dicts, too,
> which I've occasionally wanted:
>
> >>> configs = {'a': 'yes'}, {'b': 'no'}, {'c': 3}
> >>> dict(*configs)
> {'a
ht have a different view on that. You
should probably use some kind of schema-guided parser though.)
--
--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/
he average (getting the trend for free)
- to emphasize the sum, draw a histogram -- in my mind I add up the sizes
of the bars
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.or
and because it
would create an ugly discontinuity between (a := f()) and (a := f(),). But
then switching between [a := f(), a] and (a := f(), a) would create a
discontinuity.
For comprehensions and generator expressions there is no such discontinuity
in the new proposal, since these *already* int
:19 AM, Nick Coghlan wrote:
> > On 8 April 2018 at 14:31, Guido van Rossum wrote:
> >> Given that two respected members of the community so strongly disagree
> >> whether accumulate([], start=0) should behave like accumulate([]) or
> like
> >> accumulate([
ng the default value of
> "start" much easier to document (since it would just be zero, the same
> as it is for sum()), and only the length of the input iterable and
> "yield_start" would affect how many partial sums were produced.
>
> Cheers,
> Nick.
&g
gt; This would allow updating variables in a generator (I don't see the need
> for ":=" or "f() as a") but that's another discussion
>
Please join the PEP 572 discussion. The strongest contender currently is `a
:= f()` and for good reasons.
--
--Guid
> close to perfect in ease of learning/comprehension as it gets, from someone
> who studied math before C anyway.
>
> -Mike
>
>
>
> On 2018-03-30 12:04, Nikolaus Rath wrote:
> ___
> Python-ideas mailing list
> Python-ideas@p
mments first.
>
>
> Thanks,
> Jeroen.
> ___
> 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/~g
On Fri, Mar 30, 2018 at 12:04 PM, Nikolaus Rath wrote:
> On Mar 25 2018, Guido van Rossum public.gmane.org> wrote:
> > I gotta say I'm warming up to := in preference over 'as', *if* we're
> going
> > to do this at all (not a foregone conclusion a
___
> 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)
This thread is dead.
On Tue, Mar 27, 2018 at 5:40 PM, Rob Cliffe via Python-ideas <
python-ideas@python.org> wrote:
>
>
> On 28/03/2018 01:19, Steven D'Aprano wrote:
>
>> On Wed, Mar 28, 2018 at 12:08:24AM +0100, Rob Cliffe via Python-ideas
>> wrote:
>>
On Tue, Mar 27, 2018 at 11:51 AM, Ivan Levkivskyi
wrote:
> On 27 March 2018 at 19:43, Ethan Furman wrote:
>
>> On 03/27/2018 11:12 AM, Ivan Levkivskyi wrote:
>>
>>> On 27 March 2018 at 18:19, Guido van Rossum wrote:
>>>
>>
>> Hm, so maybe we sho
On Tue, Mar 27, 2018 at 11:43 AM, Ethan Furman wrote:
> On 03/27/2018 11:12 AM, Ivan Levkivskyi wrote:
>
>> On 27 March 2018 at 18:19, Guido van Rossum wrote:
>>
>
> Hm, so maybe we shouldn't touch lambda, but we can at least fix the scope
>>>
level comprehension references x
assuming it to be the global. So we need to tread carefully even here --
but this case is weird already:
x = 42
class C:
x = [1, 2, 3]
z = [x+y for y in x] # [43, 44, 45]
--
--Guido van Rossum (python.org/~guido)
_
On Tue, Mar 27, 2018 at 7:00 AM, Nick Coghlan wrote:
> On 27 March 2018 at 01:57, Guido van Rossum wrote:
> > On Mon, Mar 26, 2018 at 7:57 AM, Nick Coghlan
> wrote:
> >> By contrast, the sublocals idea strives to keep the *lifecycle* impact
> >> of naming a
On Mon, Mar 26, 2018 at 6:33 AM, Nick Coghlan wrote:
> On 26 March 2018 at 01:50, Guido van Rossum wrote:
> > In the PEP 572 threads there's some grumbling about class scopes.
> >
> > Here's a random brainstorm. How about we change the scoping rules so that
>
On Mon, Mar 26, 2018 at 7:57 AM, Nick Coghlan wrote:
> On 26 March 2018 at 14:34, Guido van Rossum wrote:
> > Not so fast. There's a perfectly reasonable alternative to sublocal
> scopes
> > -- just let it assign to a local variable in the containing scope. That's
On Sun, Mar 25, 2018 at 6:29 PM, Chris Angelico wrote:
> On Mon, Mar 26, 2018 at 12:24 PM, Guido van Rossum
> wrote:
> > The scope question is far from easy though. I find it particularly
> grating
> > that an inline assignment occurs in an 'if' statement, its
the normal comparison operator
> > is ===. It's *still* not uncommon to see a comparison spelled =.
>
> I wonder whether Guido remembers this ;-) In the very, very, VERY
> early days, Python didn't have "==". Plain single "=" was used for
> both as
pe as an
outer scope so they can close over class variables?
Not sure what should happen to nested classes, they should probably be
lumped in with the 'def' scopes.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
change,
> too - instead of creating a function, they just create a sublocal
> scope.
>
> That may be the best way forward. I'm not sure.
>
> ChrisA
>
I don't think the PEP should be split up into two PEPs. The two topics are
too closely related. But you can have sep
pat.match(text)) and check((g = m.group(0))):
print(g)
or
if (pat.match(text) as m) and check((m.group(0) as g)):
print(g)
--
--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/
28 years ago it was the best we could
do, and by the time we realized its problems -- all rare edge cases for
sure, but unintuitive and hard to debug when they strike -- we were tied by
backward compatibility. And we still are. (At the time there
thon 6. It would certainly suit a language that is widely used in
> education to sharpen the distinction between assignment and equality
> operators.
>
> Cheers,
> Christoph
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/m
ut unfortunately you're not going to find TOOWTDI.
>
> -n
>
> --
> Nathaniel J. Smith -- https://vorpus.org
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-
> Brendan Barnwell
> "Do not follow where the path may lead. Go, instead, where there is no
> path, and leave a trail."
>--author unknown
>
> ___
> Python-ideas mailing list
> Python
I use the feature regularly for long error messages, and when combined with
.format() or % it's not so easy to replace it with a + (it would require
adding parentheses).
So I am against formally discouraging it or adding something to PEP 8.
However linters could warn about lists of comma-separate
on.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/
d to a mail/news client.
>
We can kill this topic right now. We'll be moving to MM3, which is a
mailing list for those who like email, and can also be used as a web forum
for those who like that. Personally I'm partial to both, so I think this is
the best of both worlds.
--
--Guido va
ling 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/
code that currently doesn't raise will break, right?
> Summary
> ===
> I find it it not acceptable as a good language design that there is a
> large range of behaviour on slicing in assignment target for the different
> native (and standard library) data type of seemingly similar kind, and that
> users have to figure out for each data type by testing - or at the very
> least remember if documented - how it behaves on slicing in assignment
> targets. There should be a consistent behaviour at the very least, ideally
> even one with a clear user interface as suggested for lists.
>
Fortunately, what *you* find acceptable or good language design is not all
that important. (You can avoid making any mistakes in your own language.
:-) You may by now realize that 100% consistent behavior is hard to obtain.
However we'll gladly consider your feedback.
--
--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 Tue, Feb 20, 2018 at 12:54 PM, Barnstone Worthy
wrote:
I'm pretty sure that's an alias for Barry Warsaw. :-)
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailma
Integral as an alias
for backwards compatibility. I don't think it's a huge problem to fix this
in 3.7b2, if someone wants to do the work.
On Mon, Feb 19, 2018 at 9:53 PM, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> Guido van Rossum writes:
>
> > Hm, p
ke Boolean? Though it's also
possible that it was simply a mistake. In general I don't like adding
aliases for different spellings -- it violates TOOWTDI. If we decide that
this really was a mistake we should go ahead and make Integer the
recommended way and define Integral as an alias for ba
Gesendet von Mail für Windows 10
___
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/
a numpy bool. But maybe
> that’s too much of type checking for the python philosophy ? I’m wondering
> if we’re going too far here…
>
>
>
> Anyway, again, my point is just about consistency: if this is available
> for numbers, why not for simple Booleans?
>
>
>
>
types, not to switch to
numbers.Integral. And the reason is that few people (outside hardcore np
fans) will want to write numbers.Integral instead of int.
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
http
re not dependent on MyPy.
>
>
>
> Sylvain
>
>
>
> *De :* gvanros...@gmail.com [mailto:gvanros...@gmail.com] *De la part de*
> Guido van Rossum
> *Envoyé :* mercredi 14 février 2018 19:47
> *À :* Sylvain MARIE
>
> *Cc :* python-ideas
> *Objet :* Re: [Python-i
schneider-
> electric@python.org] *De la part de* David Mertz
> *Envoyé :* mardi 13 février 2018 07:08
> *À :* Nick Coghlan
> *Cc :* python-ideas
> *Objet :* Re: [Python-ideas] Boolean ABC similar to what's provided in
> the 'numbers' module
>
>
>
>
Can you show some sample code that you have written that shows where this
would be useful?
Note that using the numbers package actually makes static type checking
through e.g. mypy difficult. So I presume you are talking about dynamic
checking?
--Guido
On Feb 14, 2018 12:42 AM, "Sylvain
>
> """~self"""
>
>
>
>
>
> # register bool and numpy bool_ as virtual subclasses
>
> # so that issubclass(bool, Boolean) = issubclass(np.bool_, Boolean) = True
>
> Boolean.register(bool)
>
>
>
> try:
>
> import numpy as np
>
> Boolean.register(n
OK, I am no longer interested in this topic. If you can't reach agreement,
so be it, and then the status quo prevails. I am going to mute this thread.
There's no need to explain to me why I am wrong.
On Wed, Jan 31, 2018 at 9:48 AM, Serhiy Storchaka
wrote:
> 31.01.18 18:36, Gui
On Wed, Jan 31, 2018 at 3:03 AM, Serhiy Storchaka
wrote:
> 19.01.18 05:51, Guido van Rossum пише:
>
>> Can someone explain to me why this is such a controversial issue?
>>
>> It seems reasonable to me to add new encodings to the stdlib that do the
>> roundtripping
> it more), but since it is added I don't see much benefit from removing it.
>
>
> ___
> 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;there's no reason to try to implement this."
>
> On Mon, Jan 29, 2018 at 11:05 AM Guido van Rossum
> wrote:
>
>> I think that settles it -- there's no reason to try to implement this.
>>
>> On Mon, Jan 29, 2018 at 10:51 AM, George Leslie-Waksman <
efault value or factory. Attribute in question: Attribute(name='b',
> default=NOTHING, validator=None, repr=True, cmp=True, hash=None, init=True,
> metadata=mappingproxy({}), type=None, converter=None)
>
>
> On Fri, Jan 26, 2018 at 1:44 PM Guido van Rossum wrote:
>
xisting internal flag is an implementation detail that
should not show in the API.
--
--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; 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/
>
--
--Guido van Rossum (python.org/~guido)
___
>> > I understand that this is a limitation of positional arguments
>> > because the effective __init__ signature is:
>> >
>> > def __init__(self, some_default: dict = ,
>> > other_field: int):
>> >
>&
can use them for this” example was provided.
>
> -dancollins34
>
> Sent from my iPhone
>
> On Jan 26, 2018, at 1:05 PM, Guido van Rossum wrote:
>
> On Fri, Jan 26, 2018 at 9:20 AM, Daniel Collins
> wrote:
>
>> @Guido As an aside, my understanding was librari
On Fri, Jan 26, 2018 at 9:20 AM, Daniel Collins
wrote:
> @Guido As an aside, my understanding was libraries that fall back to c
> (Numpy as an example) release the GIL for load heavy operations. But I
> believe the explanation would hold in the general case if you replace
> thread
) for each b operation. Then you could
> call this like
>
> b_fut = a_fut.then(b)
>
> for i in range(3):
> b_fut.then(c)
>
> And the execution would look like this:
>
> ExecutorThread:
> Worker1: a*5 b*5 c*15
> Worker2: a*5 b*5 c*15
>
> Which would be
; ref: https://github.com/python/cpython/blob/e76daebc0c8afa3981a4c5a8b54537
> f756e805de/Lib/ipaddress.py#L491-L494
>
> If str has str.isascii() method, it can be simpler:
>
> `if s.isascii() and s.isdigit():`
>
> I want to add it in Python 3.7 if there are no opposite opinions.
&g
.Future.
> Thoughts?
>
> -dancollins34
>
> Github PR #5335
> bugs.python.org issue #32672
>
> ___
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: htt
On Sun, Jan 21, 2018 at 2:43 AM, Steven D'Aprano
wrote:
> On Fri, Jan 19, 2018 at 06:35:30PM +, Rob Speer wrote:
> > Guido had some very sensible feedback just a moment ago. I am wondering
> now
> > if we lost Guido because I broke python-ideas etiquette (is a pull
>
nts these mappings as
> new encodings that work just like the other ones.
>
> On Fri, 19 Jan 2018 at 11:54 M.-A. Lemburg wrote:
>
>> On 19.01.2018 17:20, Guido van Rossum wrote:
>> > On Fri, Jan 19, 2018 at 5:30 AM, M.-A. Lemburg > > <mailto:m...@egenix.com>> wrote
would hide the
site-packages/test directory.
--
--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, Jan 19, 2018 at 5:30 AM, M.-A. Lemburg wrote:
> On 19.01.2018 05:38, Nathaniel Smith wrote:
> > On Thu, Jan 18, 2018 at 7:51 PM, Guido van Rossum
> wrote:
> >> Can someone explain to me why this is such a controversial issue?
> >
> > I guess pra
@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/
ion for (b), getting past (a) isn't so easy.
So don't get nerd-sniped by the solution for (b) alone.)
--
--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/
(Modifying existing encodings seems wrong -- did the feature request
somehow transmogrify into that?)
--
--Guido van Rossum (python.org/~guido)
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code
e
> builtins namespace?
>
That would violate the very definition of the builtins module.
PS. There are probably many more of these. E.g. NoneType, dict_keys, etc.
--Guido
On 12Jan2018 0941, Victor Stinner wrote:
>
>> I like the idea of having a fully qualified name that "w
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/
On Wed, Jan 3, 2018 at 8:24 AM, Random832 wrote:
> On Sun, Dec 31, 2017, at 00:33, Guido van Rossum wrote:
> > I'm not keen on this recommendation. An argument that takes a Set[Foo]
> > would mean that in order to specify:
> > - no flags: you'd have to pass set() -
__
> 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)
__
s for this).
> >
> >In the C version the caches/registry will be simpler and will not use
> WeakSet (instead they will be thin C wrappers around normal sets).
>
> Ok, no problem.
>
> Found out myself why the registry's empty:
> every iterator passed to Iterator.register(
ors in the cache should've been in the registry instead, should'nt
> they?
> _______
> Python-ideas mailing list
> Python-ideas@python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/ps
rd example). When using IntFlag, you just use 0.
On Sat, Dec 30, 2017 at 9:33 PM, Guido van Rossum wrote:
> On Sat, Dec 30, 2017 at 8:50 PM, Franklin? Lee <
> leewangzhong+pyt...@gmail.com> wrote:
>>
>> Paddy might want something like this:
>> - For existing APIs whi
#x27;d have to pass set() -- you can't use {} since that's an
empty dict, not an empty set
- one flag: you'd have to pass {Foo.BAR} rather than just Foo.BAR
- two flags: you'd have to pass {Foo.BAR, Foo.BAZ} rather than Foo.BAR |
Foo.BAZ
I think for each of these the proposal would b
elements = ', '.join(map(repr, self))
> File "/usr/lib/python3.6/_collections_abc.py", line 764, in __iter__
> yield self._mapping[key]
> TypeError: list indices must be integers or slices, not str
>
>
> It's because __init__ in MappingView treat the passed argument -- wich is
>
This sounds like a good observation. I recommend opening a bug and
preparing a PR if you can (a PR would also help finding if there are any
problems with the idea).
On Dec 29, 2017 9:50 AM, "Yahya Abou 'Imran via Python-ideas" <
python-ideas@python.org> wrote:
> After I generate an UML diagram fr
601 - 700 of 912 matches
Mail list logo
