So secrets.py needs an upgrade; it currently uses random.SysRandom.
On Thursday, June 9, 2016, Tim Peters wrote:
> [Nikolaus Rath]
> >> Aeh, what the tin says is "return random bytes".
>
> [Larry Hastings]
> > What the tin says is "urandom", which has local man pages that dictate
> > exactly how
ly vary on how insecure the fallback bits really are, how
likely you are to find yourself in that situation, and how probable an
exploit would be.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.
, Jun 09, 2016 at 07:52:31PM -0700, Nikolaus Rath wrote:
> > On Jun 09 2016, Guido van Rossum >
> wrote:
> > > I don't think we should add a new function. I think we should convince
> > > ourselves that there is not enough of a risk of an exploit even if
> > &
we've
passed that station.
On Sat, Jun 11, 2016 at 10:15 AM, Donald Stufft wrote:
>
> On Jun 11, 2016, at 11:34 AM, Guido van Rossum wrote:
>
> In terms of API design, I'd prefer a flag to os.urandom() indicating a
> preference for
> - blocking
> - raising an e
You can add me to the list of people who feel like disappearing.
On Sat, Jun 11, 2016 at 10:28 AM, Terry Reedy wrote:
> On 6/11/2016 11:34 AM, Guido van Rossum wrote:
>
>> In terms of API design, I'd prefer a flag to os.urandom() indicating a
>> preference for
>&g
On Sat, Jun 11, 2016 at 11:30 AM, Donald Stufft wrote:
>
> On Jun 11, 2016, at 1:39 PM, Guido van Rossum wrote:
>
> Is the feature detection desire about being able to write code that runs
> on older Python versions or for platforms that just don't have getrandom()?
>
&
luck.
So I still don't see why we need os.getrandom() -- it has nothing to
recommend it over the secrets module (since both won't happen before 3.6).
So what should the secrets module use? Let's make that part an extension
module.
--
--Guido van Rossum (python.org/~guido)
___
On Sat, Jun 11, 2016 at 1:48 PM, Donald Stufft wrote:
>
> On Jun 11, 2016, at 3:40 PM, Guido van Rossum wrote:
>
> Yeah, but we've already established that there's a lot more upset,
> rhetoric and worry than warranted by the situation.
>
>
> Have we? There are
On Sat, Jun 11, 2016 at 2:16 PM, Donald Stufft wrote:
>
> On Jun 11, 2016, at 4:48 PM, Guido van Rossum wrote:
>
> But I find an os.getrandom() that only exists on those (few?) platforms
> that support it a nuisance too -- this just encourages cargo cult code
> that's un
Fortunately, 3.6 feature freeze isn't until September, so we can all cool
off and figure out the best way forward. I'm going on vacation for a week,
and after sending this I'm going to mute the thread so I won't be pulled
into it while I'm supposed to be relaxing
Can someone block Franklin until his mailer stops resending this message?
--Guido (mobile)
On Jun 13, 2016 2:26 PM, "Franklin? Lee"
wrote:
> I am. I was just wondering if there was an in-progress effort I should be
> looking at, because I am interested in extensions to it.
>
> P.S.: If anyone is
es them. If the WHERE
> clause doesn't match anything, nothing gets deleted. So your code is
> working exactly as I would expect.
>
> Paul
> _______
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/ma
>
> --> ''[h]
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: __index__ returned non-int (type bytes)
>
> --> bool(h)
> Traceback (most recent call last):
> File "", line 1, in
> TypeError: __bool__ should return bool, returned s
OK, so let's add a check on the return of __fspath__() and keep the check
on path-like or string/bytes.
--Guido (mobile)
On Jun 15, 2016 11:29 AM, "Nick Coghlan" wrote:
> On 15 June 2016 at 10:59, Brett Cannon wrote:
> >
> >
> > On Wed, 15 Jun 2
both the product and community
> grow and succeed even more. That, in fact, is why I'm choosing to write
> this message first rather than simply unsubscribe.
>
> Kevin
>
> ___
> Python-Dev mailing list
> Python-Dev@python.org
More likely your post was too long... :-(
On Thu, Jun 16, 2016 at 7:00 PM, Kevin Ollivier <
kevin-li...@theolliviers.com> wrote:
> Hi Guido,
>
> From: on behalf of Guido van Rossum <
> gu...@python.org>
> Reply-To:
> Date: Thursday, June 16, 2016 at 5:27 PM
>
of
> discussion or else we are going to burn out regularly any time security
> comes up; we can't keep holding security discussions like this or else
> we're going to end up in a bad place when everyone burns out and stops
> caring.
>
> ___
>
e don't have to take as long, but
we'll use a similar process: a small committee run by a dedicated volunteer
will compare alternatives and pick a strategy. If you're interested in
serving on this committee, send me email off-list. If you want to head the
committee, ditto. If
zation was made that all that was truly needed was the
>> opportunity to provide a trampoline function to handle execution of
>> Python code that had been JIT-compiled and a way to attach that
>> compiled machine code along with other critical data to the
>> corresponding Py
uld just be
security-sig. (The sensitive-issues people are usually paranoid enough to
check before they post; the script kiddies reporting python.org "issues"
probably will get a faster and more appropriate response from the
security-sig.)
So let's just do it.
--
--
On Sun, Jun 19, 2016 at 6:29 PM, Brett Cannon wrote:
>
>
> On Sat, 18 Jun 2016 at 21:49 Guido van Rossum wrote:
>
>> Hi Brett,
>>
>> I've got a few questions about the specific design. Probably you know the
>> answers, it would be nice to have them in
il.com | Brisbane, Australia
> ___
> 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
>
-
purposes so we will never be able to
get rid of it.
Note: I'm neither accepting nor rejecting the PEP; I'm merely inviting more
contemplation.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://ma
s -- often such
things end up being code the author is ashamed of. Perhaps they should stay
in the shadows? Or could we do something to make it so you won't have to be
ashamed of it?
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev ma
aybe we should ask for feedback from the Jython developers?
(PyPy already has this IIUC, and IronPython
<https://github.com/IronLanguages/main> seems moribund?)
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@pytho
work? Or is it important to be able to import a lot of code and
then later import+install the JIT and have it benefit the code you already
imported?
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.
sitions from JIT -> Function Call -> JIT
> and get
> rid of those hash table lookups entirely. And if we can't succeed at
> inlining then
> I suspect the JIT won't end up offering the performance we'd hope for.
>
>
> _____
ct nobody would have considered
asking for __definition_order__.
--
--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
ly it would update tp_as_number->nb_add. If you could modify the
dict object directly it would be more difficult to arrange for this side
effect.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.p
On Thu, Jun 23, 2016 at 8:01 AM, Random832 wrote:
> On Wed, Jun 22, 2016, at 11:11, Guido van Rossum wrote:
> > This is done in order to force all mutations of the class dict to go
> > through attribute assignments on the class. The latter takes care of
> > updating the clas
"Er, among our chief weapons are fear, surprise, ctypes, gc, and fanatical
devotion to the Pope!"
On Thu, Jun 23, 2016 at 1:03 PM, Devin Jeanpierre
wrote:
> On Thu, Jun 23, 2016 at 8:19 AM, Guido van Rossum
> wrote:
>>
>> It was a long time when I wrote this,
; ___
> 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.
I think this is an interesting idea and quite in line with the meaning of
EOFError.
--Guido (mobile)
On Jun 26, 2016 5:02 AM, "André Malo" wrote:
> * Serhiy Storchaka wrote:
>
> > On 22.06.16 19:22, André Malo wrote:
> > > I often concatenate multiple pickles into one file. When reading them,
>
ance, right? I worry
a lot about MI being imposed on classes that weren't written with MI in
mind, but I've never particularly worried about the special case of
metaclasses.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
o mandate this from a confirming implementation.
- I don't think there's much of a use case for setting __definition_order__
(to a tuple) for builtin classes. However I do think extension modules
should be allowed to set it, in case they are substituting for a previous
Python-level class who
2016 at 5:22 PM, Rob Cliffe
wrote:
> So how about an EmptyFileError (or similar name) as a subclass of EOFError?
>
> On 26/06/2016 21:42, Guido van Rossum wrote:
>
> I think this is an interesting idea and quite in line with the meaning of
> EOFError.
>
> --Guido (mobi
> 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)
__
On Tue, Jun 28, 2016 at 10:30 AM, Eric Snow wrote:
> On Sun, Jun 26, 2016 at 5:55 PM, Guido van Rossum wrote:
>>> On Fri, Jun 24, 2016 at 4:37 PM, Nick Coghlan wrote:
>>> > This version looks fine to me.
>>
>> Same to me, mostly.
>
> I've update
Awesome. That addresses my last concerns. PEP 520 is now accepted.
Congratulations!
On Tue, Jun 28, 2016 at 1:43 PM, Eric Snow wrote:
> On Tue, Jun 28, 2016 at 11:43 AM, Guido van Rossum wrote:
>> On Tue, Jun 28, 2016 at 10:30 AM, Eric Snow
>> wrote:
>>> I suppos
r compatibility with C stuff where a
> specific value is needed I don't think users need to mess that up by having
> the automatic numbering not work how they would expect).
>
> _______
> Python-Dev mailing list
> Python-Dev@python.org
> h
es, but it could make the
bug fix releases *less* of a deal, for everyone.
[1]
http://cacm.acm.org/magazines/2016/7/204027-the-small-batches-principle/abstract
(sadly requires login)
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Py
t; This general proposal is not a new idea (it was first suggested for
> inclusion in the language definition `more than 10 years ago`_, and a
> similar mechanism has long been supported by `Zope's ExtensionClass`_),
> but the situation has changed sufficiently in recent years that
OK, I see this point now. Still looking for time to review the rest of your
PEP!
--Guido (mobile)
On Jul 3, 2016 3:29 PM, "Martin Teichmann" wrote:
> Hi Guido,
>
> sorry I missed your post...
>
> >> One of the big issues that makes library authors reluctant to use
> >> metaclasses
> >> (even whe
cogh...@gmail.com | Brisbane, Australia
> ___
> 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
__init__`` method, meaning that it returned a class instead of
> modifying one. This allows a bit more flexibility, but at the cost
> of much harder implementation and undesired side effects.
>
> Adding a class attribute with the attribute order
>
FWIW I copied the version you posted into the peps repo already, since
it provides a significant update to the last version there.
On Wed, Jul 13, 2016 at 2:02 PM, Guido van Rossum wrote:
> I'm reviewing this now.
>
> Martin, can you please submit the new version of your PEP as a
sent
> another mail to this list where he goes a bit more into the details,
> I'll respond to that about this topic.
>
> Greetings
>
> Martin
>
> P.S.: I just realized that my changes to the PEP were accepted by
> someone else than Guido. I am a bit surprised abou
ior of the interpreter, but we are
> talking about undocumented behavior.
>
> The changes necessary to make super() work earlier are store in
> http://bugs.python.org/issue23722
>
> Greetings
>
> Martin
> ___
> Python-D
complete example may look like::
>
> HKEY_CURRENT_USER\Software\Python\ExampleCorp\6C465E66\Help
> Python\
> (Default) = "C:\ExampleDistro30\python36.chm"
> DisplayName = "Python Documentation"
> Extras\
> (D
Yup! Paul is now officially the BDFL-delegate for PEP 514.
On Sat, Jul 16, 2016 at 2:44 AM, Paul Moore wrote:
> On 15 July 2016 at 23:39, Steve Dower wrote:
>> On 15Jul2016 1526, Guido van Rossum wrote:
>>>
>>> I was going to delegate to our resident Win
added some words about backwards
> compatibility as hinted by Nick.
>
> Greetings
>
> Martin
>
> 2016-07-14 17:47 GMT+02:00 Guido van Rossum :
>> I just reviewed the changes you made, I like __set_name__(). I'll just
>> wait for your next update, incorporating Nic
e some context on my issue
> (http://bugs.python.org/issue23722). Hope that helps.
>
> Greetings
>
> Martin
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsu
Whoa. That's not how I read it.
--Guido (mobile)
___
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
onest research (also Python leaves Ruby in the dust :-):
http://www.viva64.com/en/b/0414/
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
wn)')
>
> try:
> ip_key = winreg.OpenKey(company_key, tag + '\\InstallPath')
> except FileNotFoundError:
> pass
> else:
> with ip_key:
> ip = get_value(ip_key, None)
> exe = get_value(ip_key, 'ExecutablePath') or
> os.path.join(ip, 'python.exe')
> exew = get_value(ip_key, 'WindowedExecutablePath') or
> os.path.join(ip, 'python.exe')
> print('InstallPath:', ip)
> print('ExecutablePath:', exe)
> print('WindowedExecutablePath:', exew)
> print()
>
> This example shows a subset of the registration that will be created by a
> just-for-me install of 64-bit Python 3.6.0. Other keys may also be created::
>
> HKEY_CURRENT_USER\Software\Python\PythonCore
> (Default) = (value not set)
> DisplayName = "Python Software Foundation"
> SupportUrl = "http://www.python.org/";
>
> HKEY_CURRENT_USER\Software\Python\PythonCore\3.6
> (Default) = (value not set)
> DisplayName = "Python 3.6 (64-bit)"
> SupportUrl = "http://www.python.org/";
> Version = "3.6.0"
> SysVersion = "3.6"
> SysArchitecture = "64bit"
>
> HKEY_CURRENT_USER\Software\Python\PythonCore\3.6\Help\Main Python
> Documentation
> (Default) =
> "C:\Users\Me\AppData\Local\Programs\Python\Python36\Doc\python360.chm"
> DisplayName = "Python 3.6.0 Documentation"
>
> HKEY_CURRENT_USER\Software\Python\PythonCore\3.6\InstallPath
> (Default) = "C:\Users\Me\AppData\Local\Programs\Python\Python36\"
> ExecutablePath =
> "C:\Users\Me\AppData\Local\Programs\Python\Python36\python.exe"
> WindowedExecutablePath =
> "C:\Users\Me\AppData\Local\Programs\Python\Python36\pythonw.exe"
>
> References
> ==
>
> .. [1] Registry Redirector (Windows)
>(https://msdn.microsoft.com/en-us/library/windows/desktop/aa384232.aspx)
>
> Copyright
> =
>
> This document has been placed in the public domain.
>
> ___
> 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
I am very much against this. The two are not at all like each other. Also,
what's the use case?
On Sunday, July 24, 2016, Martin Teichmann wrote:
> Hi list, Hi Nick,
>
> Sorry for my delayed response, it is summer here...
>
> > However, phrasing it that way suggest that it's possible we *did* mi
Yes.
--Guido (mobile)
On Jul 24, 2016 9:34 AM, "Ethan Furman" wrote:
> On 07/24/2016 08:20 AM, Guido van Rossum wrote:
>
> I am very much against this. The two are not at all like each other. Also,
>> what's the use case?
>>
>
> To be clear:
.com/NuxiNL/cloudlibc
> - https://github.com/NuxiNL/cloudabi-ports
> - https://github.com/NuxiNL/cloudabi-ports/tree/master/packages/python
> - #cloudabi on Efnet IRC
>
> Regards, Alex
> --
> Alex Willmer
> ___
> Python-Dev mailing
rg/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
y a CDN so e.g. sendfile() is not interesting to us either.)
On Wed, Aug 3, 2016 at 11:16 AM, Marcos Dione wrote:
> On Wed, Aug 03, 2016 at 10:46:13AM -0700, Guido van Rossum wrote:
>> I wonder if the issue isn't that there are so many Linux syscalls that
>> we probably should hav
>> Note: I tried -pedantic, GCC emits a lot of warnings on code which
>> looks valid and/or is protected with #ifdef for features specific to
>> GCC like computed goto.
>>
>> Victor
>>
>> 2016-06-07 21:45 GMT+02:00 Guido van Rossum :
>> > We shoul
I want it to list specific versions that are known to be good right
now, so we can point fingers appropriately when a regression happens.
If you have to ask Steve what version he used, ask!
On Fri, Aug 5, 2016 at 3:15 PM, Brett Cannon wrote:
>
>
> On Fri, 5 Aug 2016 at 15:07 Guido v
I think if we want to revisit this in the future it should be an
explicit change.
On Fri, Aug 5, 2016 at 3:27 PM, Brett Cannon wrote:
>
>
> On Fri, 5 Aug 2016 at 15:17 Guido van Rossum wrote:
>>
>> I want it to list specific versions that are known to be good right
&g
t particular C99 features? Should
>> there be a 4th clause that says "- must compile and run on all stable
>> buildbots"?
>
> [Nick's reply above arrived just as I was getting ready to send my own
> response below which covers some of the same territory.]
>
>
bbornness to the level of stupidity. Either they install Xcode or they
> don't get to build anything.
This feels close to a code of conduct violation. This kind of language
may be okay on the Linux kernel list, but I don't see the point of it
here.
--
--Guido van
> 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)
ser to the
platform (in their case I'm guessing C# or the CLR :-).
Is this perhaps something that could wait until the Core devs sprint in a
few weeks? (I presume you're coming?!)
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mail
don't follow
up to python-dev.
--
--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
for 3.6, could someone please review the
> latest patch and check that everything is OK?
>
> --
> Ivan
>
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/lis
Committed. Someone please watch the buildbots.
On Thu, Aug 18, 2016 at 8:12 AM, Guido van Rossum wrote:
> Looking...
>
> On Thu, Aug 18, 2016 at 1:16 AM, Ivan Levkivskyi
> wrote:
>
>> I have unsuccessfully tried to ping the issue
>> http://bugs.python.org/issue2595
Wouldn't
setsockopt(socket.SOL_ALG, socket.ALG_SET_AEAD_AUTHSIZE, None, taglen)
be more consistent?
--Guido (mobile)
On Aug 21, 2016 5:40 AM, "Christian Heimes" wrote:
> Hi,
>
> the socket.setsockopt(level, optname, value) method has two calling
> variants. When it is called with a buffer-lik
the error comes out unhandled you can print the
error (in both cases actually).
It's probably to specify all this behavior using some kind of default
finalizer (though you don't have to implement it that way).
Hopefully there will be other discussion as well, otherwise I'll have
_
> 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/guido%40python.org
--
--Guido van Rossum (python.org/~guido)
__
ibe:
> 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
Is this thread something I need to follow closely?
--
--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
: TYPE = VALUE
Note that there's an extensive list of rejected ideas in the PEP;
please be so kind to read it before posting here:
https://www.python.org/dev/peps/pep-0526/#rejected-proposals-and-things-left-out-for-now
--
--Guido van Rossum (python.org/~guido)
On Tue, Aug 30, 2016 at 6:00 PM, Steven D'Aprano wrote:
> On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote:
>> I'm happy to present PEP 526 for your collective review:
>
> Are you hoping to get this in before 3.6 beta? Because I'm not sure I
> ca
will for false comfort.
> But again, I'm +0 on this specific proposal because we have already gone
> down the garden path.
As long as you run mypy the comfort shouldn't be false. (But your
starting with C++ before Python explains a lot. :-)
> -Jack
--
--Guido van Rossum (python
On Tuesday, August 30, 2016, Nick Coghlan wrote:
> On 31 August 2016 at 13:37, Jack Diederich > wrote:
> > On Tue, Aug 30, 2016 at 11:03 PM, Guido van Rossum > wrote:
> >> But myfunc.__annotations__ already exists -- PEP 3107 puts the
> >> signature an
ould also be a simple decorator like
> @slotted_attributes that automatically generates "__slots__" from the
> annotations.
This I like, or something like it. It can be a follow-up design. (I.e.
a separate PEP, once we have experiece with PEP 526.)
--
--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 Thu, Sep 1, 2016 at 10:30 AM, Steven D'Aprano wrote:
> On Tue, Aug 30, 2016 at 02:20:26PM -0700, Guido van Rossum wrote:
>
>> - Whether (given PEP 484's relative success) it's worth adding syntax
>> for variable/attribute annotations.
>
> The PEP mak
On Thu, Sep 1, 2016 at 10:01 AM, Koos Zevenhoven wrote:
> On Thu, Sep 1, 2016 at 5:46 PM, Guido van Rossum wrote:
>> IOW, PEP 3157 is not dead yet. Indeed.
>>
>
> PEP 3157? Is that a typo or is there such a thing somewhere?
Sorry, 3107 (the original Function Annotations PE
se it would mean "NAME has type
NoneType" (remember that PEP 484 defines None as a shortcut for
NoneType == type(None)). But that's not a very useful type for a
variable...
But I'm not in a hurry for that -- I'm only hoping to get the basic
syntax accep
ype comments, but they are always
> annotations on assignment statements and were primarily intended for use
in
> stub files.
That is a mis-characterization of the intent of type comments in PEP 484;
they are not primarily meant for stubs (the only think I find tying the two
together is the use of
point where we won't have to
change it again for many versions, since it's much harder to change
the syntax than it is to change the behavior of type checkers (which
have fewer backwards compatibility constraints, a faster release
cycle, and narrower user bases than core Python itself).
--
ion as to why they are not, or they actually are and we
> ought to be more sure that it's the direction we want the language to go.
At runtime the variable annotations are ignored. And a type checker
will only ask for them when it cannot infer the type. So I think we'll
be fine.
--
--Gu
does *not* claim that you have to use variable annotations --
in fact we'd prefer that they were unnecessary, but the prevalence of
type comments in code we've annotated so far makes it clear that there
are plenty of uses for them, and we'd rather have a clean syntax for
them that to
Won't you ll agree that this thread belongs on python-ideas?
--
--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
I* wanted a type annotation was here:
expected: V = Ohm(100k)*input
because I haven't had a need to use Ohm's law in a long time, so I
could personally use the hint that Ohm times Amps makes Volts (but
again, given suitable class definitions, mypy wouldn't have needed
that anno
Brett, I have not followed everything here but I have no problem with
tweaks at this level as long as you are happy with it.
--Guido (mobile)
On Sep 3, 2016 5:39 PM, "Brett Cannon" wrote:
>
>
> On Sat, 3 Sep 2016 at 17:27 Yury Selivanov
> wrote:
>
>>
>> On 2016-09-03 5:19 PM, Brett Cannon wrot
freeze.
--
--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 Mon, Sep 5, 2016 at 7:19 AM, Mark Shannon wrote:
> On 04/09/16 21:16, Guido van Rossum wrote:
>>
>> Everybody please stop panicking. PEP 526 does not make a stand on the
>> behavior of type checkers (other than deferring to PEP 484). If you
>> want to start a discuss
ves (passing invalid code).
So a Python type checker that is to gain acceptance of users must be
much smarter than that, and neither PEP 484 not PEP 526 is meant to
require a type checker to complain about `return x` in the above
example.
I'm not sure how to change the language of the PEP thou
d it will be
a quality of implementation issue as to how useful a type checker will
be in practice. But that's not the topic of PEP 526.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyth
wrote:
> On 6 September 2016 at 04:15, Guido van Rossum wrote:
>> On Mon, Sep 5, 2016 at 10:24 AM, Ethan Furman wrote:
>>> On 09/05/2016 06:46 AM, Nick Coghlan wrote:
>>>
>>> [an easy to understand explanation for those of us who aren't type-inferring
&g
On Tue, Sep 6, 2016 at 9:00 AM, Nick Coghlan wrote:
> On 6 September 2016 at 14:04, Guido van Rossum wrote:
>> I'm sorry, but we're not going to invent new syntax this late in the
>> game. The syntax proposed by the PEP has been on my mind ever since
>> PEP 48
s://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com
>
>
>
> _______
> Python-Dev mailing list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/m
loop.close()
>
> -
> Yury
> ___
> 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
r can prove that in the expression `f(x)`, the
type of the *expression* `x` will be compatible with the argument type
expected by f, isn't that good enough? Why would the type given for
the *variable* `x` have to be the only input to the type check for
that expression?
--
--Guido va
1901 - 2000 of 6462 matches
Mail list logo
