On Mon, Sep 11, 2017 at 6:04 PM, Larry Hastings wrote:
>
>
> On 09/11/2017 08:44 AM, Guido van Rossum wrote:
>
> I worry that in the end @property isn't general enough and the major use
> cases end up still having to use __class__ assignment, and then we'd have a
>
On Mon, Sep 11, 2017 at 8:21 PM, Barry Warsaw wrote:
> On Sep 11, 2017, at 19:16, Guido van Rossum wrote:
> >
> > Or we could just have two arguments, eq= and order=, and
> some rule so that you only need to specify one or the other but not both.
> (E.g. order=True implies
nic that some people dislike "data classes" because these are
regular classes, not just for data, while others are proposing alternative
names that emphasize the data container aspect. So "data classes" splits
the difference, by referring to both data and
7;d rather
> leave it "list()", but could be swayed. Perhaps it would be enough
> for the PEP to not mention any relationship to "threading"?
>
Really, you're going to change it from a name conflict with a builtin
function to a
but
you only need a little bit of code in module.c to check for __getattr__ and
call it when you'd otherwise raise AttributeError.
--
--Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
___
Python-Dev mailing list
Python-Dev@py
oint there's no way I am going
to read all the discussions.
--
--Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/pyth
On Wed, Sep 13, 2017 at 2:00 PM, Nathaniel Smith wrote:
> On Wed, Sep 13, 2017 at 11:49 AM, Guido van Rossum
> wrote:
> > > Why not adding both? Properties do have their uses as does
> __getattr__.
> >
> > In that case I would just add __getattr__ to module.c, and
t which are too slow *in practice* to bother? And if yes, is __getattr__
fast enough? @property?
IMO we're still looking for applications.
--
--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
Let's all please take a time out from the naming discussion.
On Sep 14, 2017 11:15 AM, "Stefan Krah" wrote:
> On Thu, Sep 14, 2017 at 11:06:15AM -0700, Mike Miller wrote:
> > On 2017-09-14 10:45, Stefan Krah wrote:
> > >I'd expect something like a C struct or an ML record.
> >
> > Struct is take
It was and is all very intentional. I don't want to encourage line noise,
which the at-sign already resembles. But namespacing and some form of
parametrization (i.e. calls) are essential. So that's what we got.
On Sep 16, 2017 11:30 AM, "Skip Montanaro" wrote:
> > Indeed, I can’t remember a sing
object because
there was (originally) no cycle GC. In Python GC we changed the awkward
interface to something more useful, because we could depend on GC. Why are
we now trying to roll back this feature? We should just improve GC. (Or
perhaps you shouldn't be raising so many exceptions. :-)
-
iling list (python-dev).
Congratulations Benjamin. Gotta love those tristate options!
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
be to stop using a local
stack and instead use explicit addressing.
--
--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/ma
lman/options/python-dev/
>> robertomartinezp%40gmail.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/
>
It's Friday!
There have been no further comments. PEP 550 is now accepted.
Congrats, Benjamin! Go ahead and send your implementation for review.
--Guido
On Tue, Sep 26, 2017 at 1:47 PM, Guido van Rossum wrote:
> I've read the current version of PEP 552 over and I think eve
Let me try that again.
There have been no further comments. PEP 552 is now accepted.
Congrats, Benjamin! Go ahead and send your implementation for review.Oops.
Let me try that again.
PS. PEP 550 is still unaccepted, awaiting a new revision from Yury and
Elvis.
--
--Guido van Rossum
Your PEP is currently incomplete. If you don't finish it, it is not even a
contender. But TBH it's not my favorite anyway, so you could also just
withdraw it.
On Oct 1, 2017 9:13 AM, "Koos Zevenhoven" wrote:
> On Sep 29, 2017 18:21, "Guido van Rossum"
On Sun, Oct 1, 2017 at 1:52 PM, Koos Zevenhoven wrote:
> On Oct 1, 2017 19:26, "Guido van Rossum" wrote:
>
> Your PEP is currently incomplete. If you don't finish it, it is not even a
> contender. But TBH it's not my favorite anyway, so you could also just
> w
One more thing. I would really appreciate it if you properly wrapped lines
in your PEP around column 72 instead of using a single line per paragraph.
This is the standard convention, see the template in PEP 12.
On Sun, Oct 1, 2017 at 8:42 PM, Guido van Rossum wrote:
> On Sun, Oct 1, 2017 a
t see the point of calling `pdb.pm()` at breakpoint time. But it
could be done using the PEP with `import pdb; sys.breakpointhook = pdb.pm`
right? So this hardly deserves an open issue.
- I haven't read the actual implementation in the PR. A PEP should not
depend on the actual proposed im
On Sun, Oct 1, 2017 at 11:15 PM, Terry Reedy wrote:
> On 10/2/2017 12:44 AM, Guido van Rossum wrote:
>
> - There's no rationale for the *args, **kwds part of the breakpoint()
>> signature. (I vaguely recall someone on the mailing list asking for it but
>> it
; On Mon, Oct 2, 2017 at 6:42 AM, Guido van Rossum wrote:
>
> On Sun, Oct 1, 2017 at 1:52 PM, Koos Zevenhoven wrote:
>
> On Oct 1, 2017 19:26, "Guido van Rossum" wrote:
>
> Your PEP is currently incomplete. If you don't finish it, it is not even a
> contende
On Mon, Oct 2, 2017 at 11:02 AM, Barry Warsaw wrote:
> Thanks for the review Guido! The PEP and implementation have been updated
> to address your comments, but let me briefly respond here.
>
> > On Oct 2, 2017, at 00:44, Guido van Rossum wrote:
>
> > - There's a
t; protocol would have gained __suspend__ and __resume__ in PEP521).
>
Since you seem to have a good grasp on this issue, does PEP 550 suffer from
the same problem? (Or PEP 555, for that matter? :-)
--
--Guido van Rossum (python.org/~guido)
___
Python-De
On Mon, Oct 2, 2017 at 3:03 PM, Barry Warsaw wrote:
> On Oct 2, 2017, at 17:36, Guido van Rossum wrote:
>
> > I've seen your updates and it is now acceptable, except for *one* nit:
> in builtins.breakpoint() the pseudo code raises RuntimeError if
> sys.breakpointhook i
It's really not that hard. You just check the magic number and if it's the
new one, skip 4 words. No need to understand the internals of the header.
On Oct 3, 2017 08:06, "Barry Warsaw" wrote:
> Guido van Rossum wrote:
> > There have been no further comm
017 08:15:04 -0700
> Guido van Rossum wrote:
> > It's really not that hard. You just check the magic number and if it's
> the
> > new one, skip 4 words. No need to understand the internals of the header.
>
> Still, I agree with Barry that an API would be nice.
>
On Oct 3, 2017 9:55 AM, "Serhiy Storchaka" wrote:
While PEP 552 is accepted, I would want to see some changes.
1. Increase the size of the constant part of the signature to at least 32
bits. Currently only the third and forth bytes are constant, and they are
'\r\n', that is often occurred in tex
re, on the PR,
> or on the bug tracker.
>
> Cheers,
> -Barry
>
>
> ___
> 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
>
>
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
Yarko, there's one thing I don't understand. Maybe you can enlighten me.
Why would you prefer
breakpoint(x >= 1000)
over
if x >= 1000: breakpoint()
?
The latter seems unambiguous and requires thinking all around. Is there
something in iPython that makes this impractical?
nfo/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
I am still firmly convinced that @dataclass is the right name for the
decorator (and `dataclasses` for the module).
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo
___
> 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/~guid
es__, class.__dict__)
>
> So I am personally more and more leaning towards a metaclass-free future.
>
> Cheers
>
> Martin
> _______
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
&g
context variables.
>
It shouldn't be formally undefined. It should have the semantics it
acquires when you combine the existing (well-defined) formal semantics of
generators with the (to be defined) formal semantics of context variables.
--
--Guido van Rossum (python.org/~guido)
_
ext" that's a per-thread MutableMapping with ContextVar
keys. Maybe there's not much more to it apart from naming the APIs for
getting and setting it? To be clear, I am fine with this being a specific
subtype of MutableMapping. But I don't see much benefit in making it more
ab
On Sun, Oct 15, 2017 at 10:26 PM, Nathaniel Smith wrote:
> On Sun, Oct 15, 2017 at 10:10 PM, Guido van Rossum
> wrote:
> > Yes, that's what I meant by "ignoring generators". And I'd like there to
> be
> > a "current context" that's a per
it might want to use the most precise
clock available, which is perf_counter(). But if perf_counter()'s epoch is
the start of the process, after 104 days it can no longer report ns
precision due to float rounding (even though the internal counter does not
lose
On Mon, Oct 16, 2017 at 9:11 AM, Yury Selivanov
wrote:
> On Mon, Oct 16, 2017 at 11:49 AM, Guido van Rossum
> wrote:
> > On Sun, Oct 15, 2017 at 10:26 PM, Nathaniel Smith wrote:
> >> We don't need it to be abstract (it's fine to have a single concrete
>
ll have to support this as the default behavior, and to get
other behavior the generator will have to be marked or wrapped somehow.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman
programming.
On Mon, Oct 16, 2017 at 5:57 PM, Nathaniel Smith wrote:
> On Mon, Oct 16, 2017 at 8:49 AM, Guido van Rossum
> wrote:
> > On Sun, Oct 15, 2017 at 10:26 PM, Nathaniel Smith wrote:
> >>
> >> On Sun, Oct 15, 2017 at 10:10 PM, Guido van Rossum
> &g
those. __delitem__ must also be a primitive, as must __iter__ and
__len__ -- but those don't need to be as speedy (however __delitem__ must
really work!).
On Mon, Oct 16, 2017 at 9:09 PM, Nick Coghlan wrote:
> On 17 October 2017 at 03:00, Guido van Rossum wrote:
>
>> On Mon, O
On Mon, Oct 16, 2017 at 10:02 PM, Nick Coghlan wrote:
> On 17 October 2017 at 14:31, Guido van Rossum wrote:
>
>> No, that version just defers to magic in ContextVar.get/set, whereas what
>> I'd like to see is that the latter are just implemented in terms of
>> mani
eople understand what they can do with
context variables, and I really want to go back to a model that is *much*
closer to understanding how instance variables are just self.__dict__.
(Even though there are possible complications due to __slots__ and
@property.)
In short, I
Also, IMO this is all the interface we should need to explain to users
(even framework authors):
https://github.com/gvanrossum/pep550/blob/master/simpler.py
On Tue, Oct 17, 2017 at 11:25 AM, Guido van Rossum wrote:
> On Tue, Oct 17, 2017 at 8:54 AM, Yury Selivanov
> wrote:
>
>>
On Tue, Oct 17, 2017 at 12:51 PM, Nathaniel Smith wrote:
> On Oct 17, 2017 11:25 AM, "Guido van Rossum" wrote:
>
>
> In short, I really don't think there's a need for context variables to be
> faster than instance variables.
>
>
> There really is: cur
Victor
> ___
> 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
e value to store in
> > th .pyc. If you are running the code as the script, __compiled__
> > just returns its argument unchanged.
> >
> > Cheers,
> >
> > Neil
> >
> > ___
> > Python-Dev mailing lis
, "contextvars.set_ctx" would need various wrappers to handle
> correctly reverting the context change, and would hence be prone to
> "changed the active context without changing it back" bugs (which can be
> especially fun when you're dealing with a shared pool of worker
ame it _set_ctx() and
add a similar note as we have for sys._getframe(), basically keeping the
door open for future changes that may render it non-functional without
worries about backward compatibility (and without invoking the notion of
"provisional" API).
There's no problem with get
Actually after recent debate <https://bugs.python.org/issue31742> I think
this PEP should *not* be provisional.
On Wed, Oct 18, 2017 at 11:45 AM, Yury Selivanov
wrote:
> On Wed, Oct 18, 2017 at 2:21 PM, Guido van Rossum
> wrote:
> > On Wed, Oct 18, 2017 at 10:50
gt; Thanks,
> --francis
> ___
> 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
&
I think this ship has long sailed. Sorry Alexander, but I see a new class
method in your future.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
I think python-ideas does count here. Many PEPs evolve mostly there.
On Oct 26, 2017 4:59 PM, "Oleg Broytman" wrote:
> On Thu, Oct 26, 2017 at 04:48:23PM -0700, Mariatta Wijaya <
> mariatta.wij...@gmail.com> wrote:
> > >
> > > Not sure if postings to python-ideas count,
> >
> > PEP 1 says:
> >
>
Heh, you're right that was the reasoning. But I think python-list is much
less valuable than python-ideas for PEP authors. So let's change it.
On Thu, Oct 26, 2017 at 6:38 PM, Barry Warsaw wrote:
> On Oct 26, 2017, at 20:03, Guido van Rossum wrote:
> >
> > I think pyt
> _______
> 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.
Great!
On Fri, Oct 27, 2017 at 8:27 AM, Barry Warsaw wrote:
> On Oct 27, 2017, at 00:12, Guido van Rossum wrote:
> >
> > Heh, you're right that was the reasoning. But I think python-list is
> much less valuable than python-ideas for PEP authors. So let's change
> that it hasn't been folded into the core ;-)
>
> [nothing new below]
>
> On Fri, Oct 27, 2017 at 10:35 AM, Guido van Rossum
> wrote:
> > The "why" question is not very interesting -- it probably wasn't in PCRE
> and
> > nobody was familiar with i
On Sat, Oct 28, 2017 at 12:09 AM, Nick Coghlan wrote:
> On 28 October 2017 at 01:57, Guido van Rossum wrote:
>
>> Oh. Yes, that is being discussed about once a year two. It seems Matthew
>> isn't very interested in helping out with the port, and there are some
>
tps://mail.python.org/mailman/options/python-dev/
>> brett%40python.org
>>
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/ma
On Sun, Oct 29, 2017 at 10:41 AM, Raymond Hettinger <
raymond.hettin...@gmail.com> wrote:
>
> > On Oct 29, 2017, at 10:04 AM, Guido van Rossum wrote:
> >
> > Without an answer to these questions I think it's better to admit defeat
> and return a dict instanc
>
> ___
> 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 (py
I have read PEP 564 and (mostly) followed the discussion in this thread,
and I am happy with the PEP. I am hereby approving PEP 564. Congratulations
Victor!
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
On Tue, Oct 31, 2017 at 3:12 AM, Serhiy Storchaka
wrote:
> 29.10.17 19:04, Guido van Rossum пише:
>
>> It's somewhat problematic. If I subclass dict with a different
>> constructor, but I don't overload copy(), how can the dict.copy() method
>> construct a corr
Is there a bug in the documentation or in the implementation?
>
> [1] https://docs.python.org/3/library/string.html#format-string-syntax
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/
subscribe: 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
up. :-)
On Wed, Nov 1, 2017 at 7:54 PM, Barry Warsaw wrote:
> On Nov 1, 2017, at 19:42, Guido van Rossum wrote:
> >
> > Maybe we should try it on some other list too? I know it works "in
> principle" and I'd love for all Python mailing lists to migrate, but I'
63888
>
> Don't do that at home, it's just for educational purpose only! ;-)
>
> Victor
>
> 2017-10-30 18:18 GMT+01:00 Guido van Rossum :
> > I have read PEP 564 and (mostly) followed the discussion in this thread,
> and
> > I am happy with the PEP.
Maybe we should remove typing from the stdlib?
https://github.com/python/typing/issues/495
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe
shing function
> annotations into implicit lambda expressions will be easier to explain
> to people than converting them into strings, and then having to
> explain an entirely new complex set of name resolution rules.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan
eads typing.pyi from typeshed, but what's there is ignored in many cases
too.)
On Fri, Nov 3, 2017 at 10:00 AM, Steve Dower wrote:
> On 03Nov2017 0915, Victor Stinner wrote:
>
>> Hi,
>>
>> 2017-11-03 15:36 GMT+01:00 Guido van Rossum :
>>
>>> Maybe we s
I'm very worried about trying to come up with a robust implementation of
this in under 12 weeks. By contrast, the stringification that Łukasz is
proposing feels eminently doable.
On Sat, Nov 4, 2017 at 6:51 AM, Nick Coghlan wrote:
> On 4 November 2017 at 00:40, Guido van Rossum wrote:
tinfo/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
t put this into the language spec at 3.7.
On Sun, Nov 5, 2017 at 9:37 AM, Barry Warsaw wrote:
> On Nov 4, 2017, at 11:35, Guido van Rossum wrote:
> >
> > This sounds reasonable -- I think when we introduced this in 3.6 we were
> worried that other implementations (e.g. Jython) wo
rs but off for end users?
--
--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
n be close to the current default.
>
Yes, this or a close a variant sounds like a decent option.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
U
n 8 November 2017 at 06:32, Guido van Rossum wrote:
> > On Mon, Nov 6, 2017 at 7:23 PM, Terry Reedy wrote:
> >>
> >> On 11/6/2017 9:47 PM, Nick Coghlan wrote:
> >> [...]
> >>>
> >>> - "only show me legacy calls in *my* code" (th
Let me just cut this short. typing.py will stay, and it will stay
provisional.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https
On Tue, Nov 7, 2017 at 5:35 PM, Nick Coghlan wrote:
> On 8 November 2017 at 10:03, Guido van Rossum wrote:
> > OK, so let's come up with a set of heuristics that does the right thing
> for
> > those cases specifically. I'd say whenever you're executing code fro
ding to https://www.python.org/dev/
> peps/pep-0479/#transition-plan but looking at Objects/genobject.c that
> hasn't been implemented yet. Is this as simple as removing the `else`
> clause here?
>
> https://github.com/python/cpython/blob/master/Objects/
> genobject.c#L277-L298
>
> -
To cut this thread short, I say we should use Nick's proposal to turn these
warnings on for __main__ but off elsewhere. (See
https://mail.python.org/pipermail/python-dev/2017-November/150364.html.)
--
--Guido van Rossum (python.org/~guido)
___
P
What does "RFE" mean? I don't recall hearing that term before on the Python
bug tracker. Request For E-what? (I presume it's a RedHat internal term?)
On Tue, Nov 7, 2017 at 6:57 PM, Nick Coghlan wrote:
> On 8 November 2017 at 11:46, Guido van Rossum wrote:
> > O
er deletions
doesn't matter are also arguing that deletions are uncommon? Surely there
should be no speed penalty if you never delete anything from a dict, so if
you believe deletions are rare anyway, why would you care about paying a
bit extra for them?
--
--Guido van
the
OrderedDict API, not should other API changes to dict be considered.
--
--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.o
I'd call that a feature request. :-)
On Tue, Nov 7, 2017 at 9:28 PM, Nick Coghlan wrote:
> On 8 November 2017 at 14:58, Guido van Rossum wrote:
> > What does "RFE" mean? I don't recall hearing that term before on the
> Python
> > bug tracker. Reques
ted out a thunk *also* takes up more space than
a string.)
Nick, please don't try to save the thunk proposal by carefully dissecting
every one of my objections. That will just prolong its demise.
--
--Guido van Rossum (python.org/~guido)
___
Py
Besides, quite some of the problems people mention would only be fixed by
> turning them on in general, not with the compromise.
>
> So I don’t think we need a compromise, right?
>
> Best, Philipp
>
> Guido van Rossum schrieb am Mi., 8. Nov. 2017 um
> 03:46 Uhr:
>
>>
I hadn't seen that, but it requires too much cooperation of library owners.
On Wed, Nov 8, 2017 at 10:56 AM, Barry Warsaw wrote:
> On Nov 8, 2017, at 08:47, Guido van Rossum wrote:
> >
> > You seem to have missed Nick's posts where he clearly accepts that a
> mid
On Wed, Nov 8, 2017 at 5:49 PM, Nick Coghlan wrote:
> On 8 November 2017 at 16:24, Guido van Rossum wrote:
> > I also don't like the idea that there's nothing you can do with a thunk
> > besides calling it -- you can't meaningfully introspect it (not without
__
> 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)
__
So... Łukasz?
On Thu, Nov 9, 2017 at 6:11 PM, Nick Coghlan wrote:
> On 10 November 2017 at 05:51, Guido van Rossum wrote:
> > If we have to change the name I'd vote for string_annotations -- "lazy"
> has
> > too many other connotations (e.g. it might cause pe
uot; (or
> "string_annotations" ¯\_(ツ)_/¯ ) will be the longest __future__ name so
> far. That was my main motivation behind using the shorter name. And a bit
> of megalomania I guess.
>
I don't mind the long name. Of all the options so
On Fri, Nov 10, 2017 at 9:50 AM, Ethan Furman wrote:
> On 11/10/2017 07:48 AM, Guido van Rossum wrote:
>
> I don't mind the long name. Of all the options so far I really only like
>> 'string_annotations' so let's go with that.
>>
>
> As someone e
should at least be a way to
turn them off (e.g. when checking Python 2 code that's never going to be
ported). Running mypy in the above way is awkward; mypy would likely have
to grow a new flag to control this.
--
--Guido van Rossum (python.org/~guido)
On Fri, Nov 10, 2017 at 11:02 PM, Nick Coghlan wrote:
> On 11 November 2017 at 01:48, Guido van Rossum wrote:
> > I don't mind the long name. Of all the options so far I really only like
> > 'string_annotations' so let's go with that.
>
> +1 from me.
>
nt tools, but AFAIK at Dropbox the
*deployment* of e.g. Go binaries is managed through utilities written in
Python. The Go developers couldn't care less about that.)
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev
etter to disallow this syntax for
> reasons mentioned above.
>
> [1] https://www.python.org/dev/peps/pep-0289/
> [2] https://docs.python.org/2.5/whatsnew/whatsnew25.html
> [3] https://docs.python.org/3.5/whatsnew/3.5.html#changes-in-pyt
> hon-behavior
> [4] https://bugs.pytho
d
> verbatim.
--
--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
It's hard to keep those two in sync, since the actual Grammar file is
constrained by being strictly LL(1)... Can you get someone else to review
the implementation?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/
301 - 400 of 6462 matches
Mail list logo
