t since you asked specifically for my
opinion: I don't care for the idiom; it's never occurred to me before, and
it smells of cleverness. If I saw it in a code review I would probably ask
for a regular for-loop to make the code more maintainable.
But if you say
it?
>
> -CHB
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
--
--Guido van Rossu
There are useful things you can only do with comprehensions if the second
for-loop can use the variable in the first for-loop. E.g.
[(i, j) for i in range(10) for j in range(i)]
On Fri, Feb 23, 2018 at 10:16 AM, Chris Barker
wrote:
> On Fri, Feb 23, 2018 at 9:51 AM, Guido van Rossum
>
base?
>
> Mariatta Wijaya
>
> ᐧ
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>
--
--Guido van Rossum (python.org/~gui
On Sun, Feb 25, 2018 at 6:36 AM, Serhiy Storchaka
wrote:
> 23.02.18 19:30, Guido van Rossum пише:
>
>> I'm not saying anything new here, but since you asked specifically for my
>> opinion: I don't care for the idiom; it's never occurred to me before, and
>&g
x)
satisfy that constraint. Sometimes a for-loop is just better.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailm
On Mon, Feb 26, 2018 at 4:30 PM, Rob Cliffe via Python-Dev <
python-dev@python.org> wrote:
> On 26/02/2018 19:08, Guido van Rossum wrote:
>
> I would like to remind all wannabe language designers that grammar design
> is not just solving puzzles. It's also about keeping th
_
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%
> 40python.org
>
--
--Guido van Rossum (python.org/~guido)
an awkward and error-prone API that
> requires double parenthesis for the valid use case: url.endswith(('.html',
> '.css')).
>
> It doesn't look that awkward to me.
>
> Regards
>
> Antoine.
>
>
>
>
> ________
On Mon, Mar 12, 2018 at 1:03 PM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
> > On Mar 12, 2018, at 12:15 PM, Guido van Rossum wrote:
> >
> > There's a reason why adding this to int feels right to me. In mypy we
> treat int as a sub*type* of floa
re generally useful than just a weird method only datetime
> uses ;-)
>
Ironically, the various Fraction constructors *calls* as_integer_ratio()
for floats and Decimals. From which follows IMO that the float and Decimal
classes are the right place to encapsulate the knowledge on how to do it
27;s jarring that int.as_integer_ratio() doesn't exist - for
> the same reason it's jarring int.hex() doesn't exist.
>
> If Mark or I wanted to use float._as_integer_ratio() directly too,
> that's fine: we're numeric grownups and won't throw a hissy fit if
OK, please make it so.
On Tue, Mar 13, 2018 at 11:39 AM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
>
> > On Mar 13, 2018, at 10:43 AM, Guido van Rossum wrote:
> >
> > So let's make as_integer_ratio() the standard protocol for "how t
ov
>
> _______
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>
--
--Guido van Rossum (python.org/~guido)
__
python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%
> 40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python
e use case for
> namespace packages? Is this a good idea?
>
> Best regards,
> Roberto
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://m
hon-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@
a whole number".
I would probably have tried "x%1 == 0" which is terrible. I like to have an
API that doesn't have the pitfalls of any of the "obvious" solutions that
numerically naive people would come up with, and x.is_integer() is it.
Let's keep it.
--
--Guido v
On Wed, Mar 21, 2018 at 6:48 PM, Chris Barker wrote:
> On Wed, Mar 21, 2018 at 4:12 PM, Guido van Rossum
> wrote:
>
>> Thank you! As you may or may not have noticed in a different thread,
>> we're going through a small existential crisis regarding the usefulness of
ciation is much higher bar
> than
> > not-adding-it-in-the-first-place.
>
> I would not have added it as a method to begin with - but I agree with
> Guido that it doesn't reach the bar for deprecation. The only
> examples of "bad" uses we saw were from people still so naive about
> floating-point behavior that they&#
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>
--
--Guido v
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%
> 40python.org
>
--
--Guido van Rossum (python.o
Yes, #3, and what Tim says.
On Wed, Mar 28, 2018, 11:44 Serhiy Storchaka wrote:
> 28.03.18 19:20, Guido van Rossum пише:
>
> > Hm, without thinking too much about it I'd say it's okay to change the
> > evaluation order.
>
> Do you mean the option 3, right? T
hon.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%
> 40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/m
\\\]*((.|"(?!""))[^"]*)*(""")?|(?i:\\br|u|f|fr|rf|b|br|rb)?\'[^\'\\n]*(.[^\'\\n]*)*\'?|(?i:\\br|u|f|fr|rf|b|br|rb)?"[^"\\n]*(.[^"\\n]*)*"?)|(?P\\n)'
>>>
On Mon, Apr 2, 2018 at 11:32
> statements turned on for version N then N+1 should work for you without
> modification (sans relying on buggy semantics). That approach would deal
> with the above issues cleanly while dropping what our current major number
> semantics which some people view as a fallacy and are
__
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%
> 40python.org
>
--
--Guido van Rossum (python.org/~guido)
_
thon-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%
> 40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Pyth
n is appropriate.
>
> Hence my questions now on deciding what the behavior /should/ be, and
> whether practicality has a log to stand on in this case. ;)
>
>
> --
> ~Ethan~
> ___
> Python-Dev mailing list
> Python-Dev@
ment.
Another observation would be that (AFAICT) PEP 384 strictly forbids
signature changes, but is mostly silent on semantics.
On Wed, Apr 4, 2018 at 10:34 PM, Jeroen Demeyer wrote:
> On 2018-04-04 17:56, Guido van Rossum wrote:
>
>> It would be helpful if you explained the context of
s a rule in the language reference that says that
all __dunder__ names are reserved for the implementation and they should
only be used according to the documentation. So, indeed, it's not illegal,
but you are not guaranteed that anything works, either.
--
--Guido van Rossum (python.org/~g
on, it doesn't look so bad:
>
> https://github.com/jdemeyer/cpython/commit/c404a8f1b7d9525dd
> 2842712fe183a051a4b5094
>
> For example, I would need to update the code in random._randbelow().
>>
>
> For the record, there are no test failur
he
fewest corner cases, and the easiest restriction to explain.
(I was thinking there would be a use case for basic tuple unpacking, like
seen a lot in for-loop, but the only examples I tried to come up with were
pretty sub-optimal, so I don't worry about that any more.)
--
--Guido van Ross
change its
meaning.
However we won't have to break that. Suppose the code is (perversely)
t = range(3)
a = [t for t in t if t]
If we translate this to
t = range(3)
def listcomp(t=t):
a = []
for t in t:
if t:
a.append(t)
return a
a = listcomp()
Then i
On Wed, Apr 18, 2018 at 7:35 AM, Chris Angelico wrote:
> On Wed, Apr 18, 2018 at 11:58 PM, Guido van Rossum
> wrote:
> > I can't tell from this what the PEP actually says should happen in that
> > example. When I first saw it I thought "Gaah! What a horrible piec
On Wed, Apr 18, 2018 at 11:17 AM, Chris Angelico wrote:
> On Thu, Apr 19, 2018 at 2:18 AM, Guido van Rossum
> wrote:
> > On Wed, Apr 18, 2018 at 7:35 AM, Chris Angelico
> wrote:
> >>
> >> On Wed, Apr 18, 2018 at 11:58 PM, Guido van Rossum
> >> wrote:
ge(1/0)) # ZeroDivisionError
> >
> >def ():
> >for x in rage(10):
> >yield x
> >gen = () # No exception yet
> >tng = next(gen) # NameError
> >
> >
> > Open questions
> > ==
>
r
> loop, but if so, you should also be able to do it on a while loop or
> anything. Or, of course, you can just annotate the variable before the
> loop, if you want to.
>
> ChrisA
> ___
> Python-Dev mailing list
> Python-Dev
al binding instead (so either local or global depending on where
> the expression occurred).
>
> --
> ~Ethan~
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%
> 40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http
On Fri, Apr 20, 2018 at 2:04 PM, Chris Angelico wrote:
> On Sat, Apr 21, 2018 at 6:59 AM, Guido van Rossum
> wrote:
> > Does the PEP currently propose to *allow* that horrible example? I
> thought
> > Tim Peters successfully pleaded to *only* allow a single "NAME :=
To me the if-elif-elif portion of the example is very much a
separate motivation, since being able to put the assignment in the elif
clause avoids runaway indentation. I've regretted not being able to use
elif in this kind of situation many times, whereas
-- e.g. we
could have
elif line is not None and (m := re.match('(.*):(.*)', line)) and
m.group(1) == m.group(2):
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman
A
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
st annoying ;-)
>>
>
> "as" does something slightly different in each of its current
> incantations, but the one thing that they all have in common is taking some
> thing on the left and giving it the name on the right:
>
> - imports -> thing on left gets name
t least annoying ;-)
>
> Prior art: COBOL uses "GIVING", as in:
>
>ADD x, y GIVING z
>
> No need to re-invent the wheel ;)
>
> --
> Ned Deily
> n...@python.org -- []
>
> ___
> Python-Dev mailing l
ntoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
--
--Guido va
's the restriction to single names as targets that makes it possible
> to impose such a strong assertion about what the syntax means.
>
Can you elaborate? I don't understand what you mean by this.
--
--Guido van Rossum (python.org/~guido)
_
On Wed, Apr 25, 2018 at 2:27 AM, Steve Holden wrote:
> On Wed, Apr 25, 2018 at 6:16 AM, Steven D'Aprano
> wrote:
>
>> On Tue, Apr 24, 2018 at 03:54:30PM -0700, Guido van Rossum wrote:
>>
>> > We should really take this back to python-ideas at this point.
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>
--
--Guido van Ross
On Wed, Apr 25, 2018 at 1:55 PM, Łukasz Langa wrote:
>
> > On 25 Apr, 2018, at 1:28 PM, Guido van Rossum wrote:
> >
> > You don't seem to grasp the usability improvements this will give. I
> hear you but at this point appeals to Python's "Zen" don&#x
rule stating that the arguments are evaluated before
the function is called -- and before you laugh, in Algol-60 that wasn't
always the case).
This argument applies regardless of which syntactic form you use, and no
matter what we choose, the PEP
Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.
Maybe the order for d[k] = v should also be reconsidered?
On Thu, Apr 26, 2018, 08:23 Chris Angelico wrote:
> On Fri, Apr 27, 2018 at 1:07 AM, Guido van Rossum
> wrote:
> > Just as I feared. While currently fixing this is just fixing a bug
> (nobody's
> > code is goi
Also see my talk at PyCascades and Victor's upcoming talk at PyCon.
On Thu, Apr 26, 2018, 12:02 Brett Cannon wrote:
>
>
> On Thu, 26 Apr 2018 at 10:19 Barry Warsaw wrote:
>
>> On Apr 26, 2018, at 09:28, Eric Snow wrote:
>> >
>> > On Thu, Apr 26, 2018 at 10:25 AM, Eric Snow <
>> ericsnowcurren.
e that on Windows, `py` always refers specifically to the launcher
> (it doesn't get shadowed in virtual environments), but the launcher itself
> is virtual environment aware (see https://www.python.org/dev/
> peps/pep-0486/ for details).
>
> --
> Nick Coghlan | ncogh...@gm
out whether it accurately represents the
historic truth though.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
stly, I'm willing to trust Guido's
> intuition.
>
> Paul
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailma
.org/mailman/listinfo/python-dev
> > Unsubscribe: https://mail.python.org/mailman/options/python-dev/tritium-
> > list%40sdamon.com
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/list
s,
> Ivan
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%
> 40python.org
>
--
--Guido v
rces you to a wholesale redesign). Producing a detailed analysis and a
> PR is more than most people will ever do.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.pytho
EVENTUALLY WE'LL ALL BE SHOUTING ALL THE TIME. Sad.
On Thu, May 3, 2018, 11:57 Brian Curtin wrote:
> On Thu, May 3, 2018 at 2:45 PM Ivan Pozdeev via Python-Dev <
> python-dev@python.org> wrote:
>
>> On 03.05.2018 21:31, Brett Cannon wrote:
>>
>>
>>
>> On Thu, 3 May 2018 at 01:27 Paul Moore wrot
it a little while before
> firing off an angry email. But the same applies to us: we too can afford
> to wait a little while before raising the threat of the CoC over a minor
> social faux pas. This community isn't so fragile that we have to jump
> down the throat of a newcomer lest the co
___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>
--
--Guido van Rossum (python.org/~guido)
cannot fork).
> >
> > > -CHB
> > > Sent from my iPhone
> >
> > Oleg.
>
>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> U
On Fri, May 11, 2018 at 11:57 PM, Barry Warsaw wrote:
> On May 11, 2018, at 12:23, Guido van Rossum wrote:
> >
> > Indeed, we have an implementation of this specific to mypy.
>
> Is there anything in mypy’s implementation that can be generalized into a
> library?
>
he token text to the ast?
>
> >>> ast.literal_eval('"\u1234"')
> 'ሴ'
>
> Eric
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/pyt
place via GitHub,
> > rather than the mailing list, but I thought I would follow the
> conventional
> > route for now.
>
> Previously, we required to add the full text of the PEP inside the
> email to be able to reply inline by email.
>
> I know that Guido van Rossum st
On Tue, May 22, 2018 at 10:07 AM, Steve Dower
wrote:
> On 22May2018 0741, Guido van Rossum wrote:
>
>> ISTR there are plenty of PEPs that never get posted to python-ideas
>> because they are discussed on a separate list.
>>
>
> There are often better venues for t
We should take the discussion about how and where PEP discussions should be
hosted off this thread and list.
On Wed, May 23, 2018 at 6:59 AM, Nick Coghlan wrote:
> On 23 May 2018 at 05:47, Guido van Rossum wrote:
>
>> On Tue, May 22, 2018 at 10:07 AM, Steve Dower
>> wrote:
&
t; Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
__
(Also this probably belongs in python-ideas, unless there's already a
bugs.python.org issue for it -- but you didn't mention that so I assume
it's just an idea? How did you reach the line count estimates?)
On Fri, May 25, 2018 at 8:46 AM, Guido van Rossum wrote:
> Please go fi
upported so that people won't be tempted to implement an ugly workaround
> using popitem() calls followed by reinsertions.
>
>
> Raymond
>
> .
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail
__
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
on the
> PyXML project as well.
>
> --
> Jeremy Kloth
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido
colour to the debate about
> moving issues to Github.
>
I don't see how this *increases* the uncertainty. Surely if GitHub had
remained independent there would have been be similar concerns about how it
would make enough money to stay in business.
--
--Guido van Rossum (python.org/~gui
. Otherwise, there is a risk of leaking open file or not flushing
> data on disk, for example.
>
> Victor
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Uns
Unsubscribe: https://mail.python.org/mailman/options/python-dev/
> guido%40python.org
>
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubs
> > Jake Edge - LWN - j...@lwn.net - http://lwn.net
> > ___
> > Python-Dev mailing list
> > Python-Dev@python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe: https://mail.python.org/mailman/
wice-yearly X.0.0
> releases in 2017, but were doing twice yearly X.Y releases for some time
> before that)
> [6] https://pypi.org/project/SIP/
>
>
> --
> Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
>
> _______
&
Like Inada-san, I would like to see the implementation first.
On Mon, Jun 18, 2018, 07:33 Jeroen Demeyer wrote:
> On 2018-06-18 15:09, Victor Stinner wrote:
> > 2) we implemented a lot of other optimizations which made calls faster
> > without having to touch tp_call nor tp_fastcall.
>
> And tha
e last two commits are new since the last posting: support for
partial packages and a bunch of small textual tweaks I found today while
reviewing. There wasn't a lot of feedback then so I don't expect a flamewar
today, but better late than never. ;-)
--
--Guido van Rossu
I'm with Serhiy here, for mutable values I don't think the methods should
compare equal, even when the values do. For immutables I don't care either
way, it's an implementation detail.
On Thu, Jun 21, 2018, 12:55 Serhiy Storchaka wrote:
> 21.06.18 14:25, Jeroen Demeyer пише:
> > Currently, we ha
22.06.18 00:04, Ivan Pozdeev via Python-Dev пише:
> > On 21.06.2018 23:40, Guido van Rossum wrote:
> >> I'm with Serhiy here, for mutable values I don't think the methods
> >> should compare equal, even when the values do. For immutables I don't
> >> car
That sounds like you're supporting PEP 561 as is, right? Excuse my
ignorance, but where are API testing stub interfaces described or used?
--Guido
On Fri, Jun 22, 2018 at 6:10 AM Nick Coghlan wrote:
> On 21 June 2018 at 07:06, Guido van Rossum wrote:
> > Only the last two c
On Fri, Jun 22, 2018 at 9:43 AM Steven D'Aprano wrote:
> On Fri, Jun 22, 2018 at 08:13:44AM -0700, Guido van Rossum wrote:
>
> > Honestly it looks to me like the status quo is perfect.
>
> Does this example work for you?
>
> py> (17.1).hex == (17.1).hex
> Tru
On Fri, Jun 22, 2018 at 6:52 PM Steven D'Aprano wrote:
> On Fri, Jun 22, 2018 at 11:44:07AM -0700, Guido van Rossum wrote:
> [...]
> > > I know why it happens -- at the REPL, the interpreter uses the same
> > > object for both 17.1 instances when they're part of
Let's make it so.
On Sat, Jun 23, 2018, 08:53 Terry Reedy wrote:
> On 6/23/2018 4:54 AM, Serhiy Storchaka wrote:
> > 23.06.18 10:27, Jeroen Demeyer пише:
> >> On 2018-06-23 03:50, Steven D'Aprano wrote:
> >>> I think it is more important that builtin methods and Python methods
> >>> behave the s
t call last):
> File "", line 1, in
> TypeError: issubclass() arg 1 must be a class
> >>>
>
> And so with all types of "typing" module.
> This breaks down many libraries that use annotations as part of the
> functionality if we now can
-ideas, IIRC a bit before PyCon; and the main text of the
PEP gives a strong motivation (
https://www.python.org/dev/peps/pep-0572/#scope-of-the-target).
Nevertheless, maybe we should compromise and drop (b)?
--
--Guido van Rossum (python.org/~guido
t would be
> sublocal (comprehension scope); that should make Nick happier :-)
>
It's more special syntax. Just taking part (a) of PEP 572 would make most
people happy enough.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
eople (again,
due to my point about Python's scope rules). I'd wager that the people who
might be most horrified about it would be people who feel strongly that the
change to the comprehension scope rules in Python 3 is a big improvement,
and who are familiar with the difference in impl
s able to send information *in*.
>
But this "horrifies" me for a slightly different reason: it effectively
introduces a new case of dynamic scoping, which Python used to do
everywhere but has long switched away from, with the exception of class
scopes (whose difference with function s
t; On the contrary, I believe that "easy for beginners" should be a major
> concern. Ease of use has been and is a, or even the main reason for
> Python's success. When some other language becomes a better teaching
> language, it will eventually take over in busine
variant in some iteration or PEP 572, after sublocal
scopes were already eliminated -- a change to comprehensions that would
evaluate the innermost iterable in the implicit function. This would make
the explanation of inline assignment in comprehensions consistent again
(they were always local to the c
OK, last call! I'll accept the current draft tomorrow unless someone pushes
back.
On Fri, Jun 22, 2018 at 8:37 AM Nick Coghlan wrote:
> On 23 June 2018 at 01:16, Guido van Rossum wrote:
> > That sounds like you're supporting PEP 561 as is, right?
>
> Aye, I'm p
_
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
__
[This is my one response today]
On Mon, Jun 25, 2018 at 12:40 PM Terry Reedy wrote:
> On 6/24/2018 7:25 PM, Guido van Rossum wrote:
> > I'd wager that the people who might be most horrified about it
>
> the (b) scoping rule change
>
> > would be people who feel st
ot;outermost iterable".
Does this help at all, or did I miss something?
--Guido
On Wed, Jun 27, 2018 at 5:27 AM Nick Coghlan wrote:
> On 26 June 2018 at 02:27, Guido van Rossum wrote:
> > [This is my one reply in this thread today. I am trying to limit the
> amount
> > o
601 - 700 of 6462 matches
Mail list logo
