Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[Nathaniel Smith]

On Apr 3, 2015 5:50 PM, "Donald Stufft"  wrote:
>
>
> > On Apr 3, 2015, at 6:38 PM, M.-A. Lemburg  wrote:
> >
> > On 04.04.2015 00:14, Steve Dower wrote:
> >> The thing is, that's exactly the same goodness as Authenticode gives,
except everyone gets that for free and meanwhile you're the only one who
has admitted to using GPG on Windows :)
> >>
> >> Basically, what I want to hear is that GPG sigs provide significantly
better protection than hashes (and I can provide better than MD5 for all
files if it's useful), taking into consideration that (I assume) I'd have
to obtain a signing key for GPG and unless there's a CA involved like there
is for Authenticode, there's no existing trust in that key.
> >
> > Hashes only provide checks against file corruption (and then
> > only if you can trust the hash values). GPG provides all the
> > benefits of public key encryption on arbitrary files (not just
> > code).
> >
> > The main benefit in case of downloadable installers is to
> > be able to make sure that the files are authentic, meaning that
> > they were created and signed by the people listed as packagers.
> >
> > There is no CA infrastructure involved as for SSL certificates
> > or Authenticode, but it's easy to get the keys from key servers
> > given the key signatures available from python.org's download
> > pages.
>
> FTR if we’re relying on people to get the GPG keys from the download
> pages then there’s no additional benefit over just using a hash
> published on the same page.
>
> In order to get additional benefit we’d need to get Steve’s key
> signed by enough people to get him into the strong set.

I don't think that's true -- e.g. people who download the key for checking
3.5.0 will still have it when 3.5.1 is released, and notice if something
silently changes. In general distributing a key id widely on webpages /
mailing lists / using it consistently over multiple releases all increase
security, even if they fall short of perfect. Even the web of trust isn't
particularly trustworthy, it's just useful because it's harder to attack
two targets (the webserver and the WoT) than it is to attack one.

In any case, getting his key into the strong set ought to be trivial given
that pycon is next week.

-n
___
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

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[Donald Stufft]

> On Apr 3, 2015, at 6:38 PM, M.-A. Lemburg  wrote:
> 
> On 04.04.2015 00:14, Steve Dower wrote:
>> The thing is, that's exactly the same goodness as Authenticode gives, except 
>> everyone gets that for free and meanwhile you're the only one who has 
>> admitted to using GPG on Windows :)
>> 
>> Basically, what I want to hear is that GPG sigs provide significantly better 
>> protection than hashes (and I can provide better than MD5 for all files if 
>> it's useful), taking into consideration that (I assume) I'd have to obtain a 
>> signing key for GPG and unless there's a CA involved like there is for 
>> Authenticode, there's no existing trust in that key.
> 
> Hashes only provide checks against file corruption (and then
> only if you can trust the hash values). GPG provides all the
> benefits of public key encryption on arbitrary files (not just
> code).
> 
> The main benefit in case of downloadable installers is to
> be able to make sure that the files are authentic, meaning that
> they were created and signed by the people listed as packagers.
> 
> There is no CA infrastructure involved as for SSL certificates
> or Authenticode, but it's easy to get the keys from key servers
> given the key signatures available from python.org's download
> pages.

FTR if we’re relying on people to get the GPG keys from the download
pages then there’s no additional benefit over just using a hash
published on the same page.

In order to get additional benefit we’d need to get Steve’s key
signed by enough people to get him into the strong set.

> 
> If you want to sign a package file using GPG, you will need
> to create your own key, upload it to the key servers and then
> place the signature up on the download page.
> 
> Relying only on Authenticode for Windows installers would
> result in a break in technology w/r to the downloads we
> make available for Python, since all other files are (usually)
> GPG signed:
> 
> https://www.python.org/ftp/python/3.4.3/
> 
> Cheers,
> --
> Marc-Andre Lemburg
> eGenix.com
> 
> Professional Python Services directly from the Source
 Python/Zope Consulting and Support ...http://www.egenix.com/
 mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
 mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
> 
> 
> ::: Try our new mxODBC.Connect Python Database Interface for free ! 
> 
> 
>   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>   Registered at Amtsgericht Duesseldorf: HRB 46611
>   http://www.egenix.com/company/contact/
> 
> 
>> Cheers,
>> Steve
>> 
>> Top-posted from my Windows Phone
>> 
>> From: M.-A. Lemburg
>> Sent: ‎4/‎3/‎2015 10:55
>> To: Steve Dower; Larry 
>> Hastings; Python 
>> Dev; 
>> python-committers
>> Subject: Re: [python-committers] [Python-Dev] Do we need to sign Windows 
>> files with GnuPG?
>> 
>> On 03.04.2015 19:35, Steve Dower wrote:
 My Windows development days are firmly behind me. So I don't really have an
 opinion here. So I put it to you, Windows Python developers: do you care 
 about
 GnuPG signatures on Windows-specific files? Or do you not care?
>>> 
>>> The later replies seem to suggest that they are general goodness that 
>>> nobody on Windows will use. If someone convinces me (or steamrolls me, 
>>> that's fine too) that the goodness of GPG is better than a hash then I'll 
>>> look into adding it into the process. Otherwise I'll happily add hash 
>>> generation into the upload process (which I'm going to do anyway for the 
>>> ones displayed on the download page).
>> 
>> FWIW: I regularly check the GPG sigs on all important downloaded
>> files, regardless of which platform they target, including the
>> Windows installers for Python or any other Windows installers
>> I use which provide such sigs.
>> 
>> The reason is simple:
>> The signature is a proof of authenticity which is not bound to
>> a particular file format or platform and before running .exes
>> it's good to know that they were built by the right people and
>> not manipulated by trojans, viruses or malicious proxies.
>> 
>> Is that a good enough reason to continue providing the GPG
>> sigs or do you need more proof of goodness ? ;-)
>> 
>> --
>> Marc-Andre Lemburg
>> eGenix.com
>> 
>> Professional Python Services directly from the Source
> Python/Zope Consulting and Support ...http://www.egenix.com/
> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
>> 
>> 
>> ::: Try our new mxO

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[M.-A. Lemburg]

On 04.04.2015 00:14, Steve Dower wrote:
> The thing is, that's exactly the same goodness as Authenticode gives, except 
> everyone gets that for free and meanwhile you're the only one who has 
> admitted to using GPG on Windows :)
> 
> Basically, what I want to hear is that GPG sigs provide significantly better 
> protection than hashes (and I can provide better than MD5 for all files if 
> it's useful), taking into consideration that (I assume) I'd have to obtain a 
> signing key for GPG and unless there's a CA involved like there is for 
> Authenticode, there's no existing trust in that key.

Hashes only provide checks against file corruption (and then
only if you can trust the hash values). GPG provides all the
benefits of public key encryption on arbitrary files (not just
code).

The main benefit in case of downloadable installers is to
be able to make sure that the files are authentic, meaning that
they were created and signed by the people listed as packagers.

There is no CA infrastructure involved as for SSL certificates
or Authenticode, but it's easy to get the keys from key servers
given the key signatures available from python.org's download
pages.

If you want to sign a package file using GPG, you will need
to create your own key, upload it to the key servers and then
place the signature up on the download page.

Relying only on Authenticode for Windows installers would
result in a break in technology w/r to the downloads we
make available for Python, since all other files are (usually)
GPG signed:

https://www.python.org/ftp/python/3.4.3/

Cheers,
-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/


> Cheers,
> Steve
> 
> Top-posted from my Windows Phone
> 
> From: M.-A. Lemburg
> Sent: ‎4/‎3/‎2015 10:55
> To: Steve Dower; Larry 
> Hastings; Python 
> Dev; 
> python-committers
> Subject: Re: [python-committers] [Python-Dev] Do we need to sign Windows 
> files with GnuPG?
> 
> On 03.04.2015 19:35, Steve Dower wrote:
>>> My Windows development days are firmly behind me. So I don't really have an
>>> opinion here. So I put it to you, Windows Python developers: do you care 
>>> about
>>> GnuPG signatures on Windows-specific files? Or do you not care?
>>
>> The later replies seem to suggest that they are general goodness that nobody 
>> on Windows will use. If someone convinces me (or steamrolls me, that's fine 
>> too) that the goodness of GPG is better than a hash then I'll look into 
>> adding it into the process. Otherwise I'll happily add hash generation into 
>> the upload process (which I'm going to do anyway for the ones displayed on 
>> the download page).
> 
> FWIW: I regularly check the GPG sigs on all important downloaded
> files, regardless of which platform they target, including the
> Windows installers for Python or any other Windows installers
> I use which provide such sigs.
> 
> The reason is simple:
> The signature is a proof of authenticity which is not bound to
> a particular file format or platform and before running .exes
> it's good to know that they were built by the right people and
> not manipulated by trojans, viruses or malicious proxies.
> 
> Is that a good enough reason to continue providing the GPG
> sigs or do you need more proof of goodness ? ;-)
> 
> --
> Marc-Andre Lemburg
> eGenix.com
> 
> Professional Python Services directly from the Source
 Python/Zope Consulting and Support ...http://www.egenix.com/
 mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
 mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/
> 
> 
> ::: Try our new mxODBC.Connect Python Database Interface for free ! 
> 
> 
>eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>Registered at Amtsgericht Duesseldorf: HRB 46611
>http://www.egenix.com/company/contact/
> 

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[Steve Dower]

The thing is, that's exactly the same goodness as Authenticode gives, except 
everyone gets that for free and meanwhile you're the only one who has admitted 
to using GPG on Windows :)

Basically, what I want to hear is that GPG sigs provide significantly better 
protection than hashes (and I can provide better than MD5 for all files if it's 
useful), taking into consideration that (I assume) I'd have to obtain a signing 
key for GPG and unless there's a CA involved like there is for Authenticode, 
there's no existing trust in that key.

Cheers,
Steve

Top-posted from my Windows Phone

From: M.-A. Lemburg
Sent: ‎4/‎3/‎2015 10:55
To: Steve Dower; Larry 
Hastings; Python Dev; 
python-committers
Subject: Re: [python-committers] [Python-Dev] Do we need to sign Windows files 
with GnuPG?

On 03.04.2015 19:35, Steve Dower wrote:
>> My Windows development days are firmly behind me. So I don't really have an
>> opinion here. So I put it to you, Windows Python developers: do you care 
>> about
>> GnuPG signatures on Windows-specific files? Or do you not care?
>
> The later replies seem to suggest that they are general goodness that nobody 
> on Windows will use. If someone convinces me (or steamrolls me, that's fine 
> too) that the goodness of GPG is better than a hash then I'll look into 
> adding it into the process. Otherwise I'll happily add hash generation into 
> the upload process (which I'm going to do anyway for the ones displayed on 
> the download page).

FWIW: I regularly check the GPG sigs on all important downloaded
files, regardless of which platform they target, including the
Windows installers for Python or any other Windows installers
I use which provide such sigs.

The reason is simple:
The signature is a proof of authenticity which is not bound to
a particular file format or platform and before running .exes
it's good to know that they were built by the right people and
not manipulated by trojans, viruses or malicious proxies.

Is that a good enough reason to continue providing the GPG
sigs or do you need more proof of goodness ? ;-)

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

[PJ Eby]

On Fri, Apr 3, 2015 at 4:21 AM, Nick Coghlan  wrote:
> That means I'm now OK with monkeypatching __build_class__ being the
> only way to get dynamic hooking of the class currently being defined
> from the class body - folks that really want that behaviour can
> monkeypatch it in, while folks that think it's a bad idea don't need
> to worry about.

I'd still prefer to only do that as an emulation of an agreed-upon
descriptor notification protocol, such that it's a backport of an
approved PEP, so I hope we can work that out.  But I guess if not,
then whatever works.  I just wish you'd been okay with it in 2012, as
there was more than once in the last few years where I had some
downtime and thought about trying to do some porting work.  :-(

And in the meantime, the only alternative Python implementation I know
of that's made *any* headway on Python 3 in the last few years (i.e.,
PyPy 3) *includes* a compatibly monkeypatchable __build_class__.  It
appears that the *other* obstacles to making a compatible Python 3
implementation are a lot tougher for implementers to get over than
compatibility with __build_class__.  ;-)


> Neither PEP 422 nor 487 are designed to eliminate metaclass conflicts
> in general, they're primarily designed to let base classes run
> arbitrary code after the namespace has been executed in a subclass
> definition *without* needing a custom metaclass.

And yet the argument was being made that the lack of custom metaclass
was a feature because it avoided conflict.  I'm just trying to point
out that if avoiding conflict is desirable, building *every possible
metaclass feature* into the Python core isn't a scalable solution.  At
this point, co-operative inheritance is a well-understood model in
Python, so providing an API to automatically mix metaclasses
(explicitly, at first) seems like a good step towards solving the
metaclass conflict problem in general.

When Guido introduced the new MRO scheme in Python 2.2, he noted that
the source he'd gotten that scheme from had explained that it could be
extended to automatically mixing metaclasses, but he (Guido) didn't
want to do that in Python until more experience was had with the new
MRO scheme in general.  And I think we have enough experience with
that *now*, to be able to take a step forward, by providing a
stdlib-blessed metaclass mixer.  It not only makes the prototype,
PyPI-based version of PEP 487 more usable immediately, it will also
encourage people to develop metaclasses as *mixins* rather than
one-size-fits-all monoliths.

For example, there's no reason that both of PEP 487''s features need
to live in the *same* metaclass, if you could trivially mix
metaclasses at the point where you inherit from bases with different
metaclasses.  (And eventually, a future version of Python could do the
mixing automatically, without the `noconflict` function.  The theory
was well-understood for other languages, after all, before Python 2.2
even came out.)


> No, you can't do it currently without risking a backwards
> incompatibility through the introduction of a custom metaclass.

Right...  which is precisely why I'm suggesting  the `noconflict()`
metaclass factory function as a *general* solution for providing
useful metaclasses, and why I think that PEP 487 should break the
namespacing and subclass init features into separate metaclasses, and
add that noconflict feature.  It will then become a good example for
people moving forward writing metaclasses.

Basically, as long as you don't have the pointless conflict errors,
you can write co-operative metaclass mixins as easily as you can write
regular co-operative mixins.  I was missing this point myself because
I've been too steeped in Python 2's complexities: writing a usable
version of `noconflict()` is a lot more complex and its invocation far
more obscure.  In Python 2, there's classic classes, class- and
module-level __metaclass__, ExtensionClass, and all sorts of other
headaches for automatic mixing.  In Python 3, though, all that stuff
goes out the window, and even my 90-line version that's almost half
comments is probably still overengineered compared to what's actually
needed to do the mixing.


>> Further, if the claim is that metaclass conflict potential makes PEP
>> 487 worthy of a language change, then by the same logic method
>> decorators are just as worthy of a language change, since any mixin
>> required to use a method decorator would be *just as susceptible* to
>> metaclass conflicts as SubclassInit.
>
> There wouldn't be a custom metaclass involved in the native
> implementation of PEP 487, only in the backport.

Right...  and if there were a native implementation of PEP 422, that
would also be the case for PEP 422.  The point is that if the PEP 487
can justify a *language* change to avoid needing a metaclass, then
arguably PEP 422 has an even *better* justification, because its need
to avoid needing a metaclass is at least as strong.  Indeed, you said
the same yourself as recent

Re: [Python-Dev] Installing Python from the source code on Windows

[Terry Reedy]

On 4/3/2015 5:51 AM, Narsu wrote:

Hi Python
I'm working on a game project,using c++ as main
language, and using python as script.I've built
the Python from the source code on Windows, and when I
invoked method Py_Initialize my program exited. After some tests
I realized  as long as I move the Python-2.7.9/Lib file
to my program file, it works fine.
Please help me out .


Py-dev is for developing *future* versions of python.  Questions about 
using *current* versions of python should usually go to python-list.

PS: consider using 3.x for scripting.

--
Terry Jan Reedy

___
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

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

[PJ Eby]

On Fri, Apr 3, 2015 at 11:04 AM, Nick Coghlan  wrote:
> Extending the descriptor protocol to include a per-descriptor hook that's
> called at class definition time sounds like a potentially nice way to go to
> me. While you *could* still use it to arbitrarily mutate the class object,
> it's much clearer that's not the intended purpose, so I don't see it as a
> major problem.

Just to be clear, mutating the class object was never the point for my
main use case that needs the PEP 422 feature; it was for method
overloads that are called remotely and need to be registered
elsewhere.  For some of my other use cases, adding metadata to the
class is a convenient way to do things, but classes are generally
weak-referenceable so the add-on data can be (and often is) stored in
a weak-key dictionary rather than placed directly on the class.
___
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

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[M.-A. Lemburg]

On 03.04.2015 19:35, Steve Dower wrote:
>> My Windows development days are firmly behind me. So I don't really have an
>> opinion here. So I put it to you, Windows Python developers: do you care 
>> about
>> GnuPG signatures on Windows-specific files? Or do you not care?
> 
> The later replies seem to suggest that they are general goodness that nobody 
> on Windows will use. If someone convinces me (or steamrolls me, that's fine 
> too) that the goodness of GPG is better than a hash then I'll look into 
> adding it into the process. Otherwise I'll happily add hash generation into 
> the upload process (which I'm going to do anyway for the ones displayed on 
> the download page).

FWIW: I regularly check the GPG sigs on all important downloaded
files, regardless of which platform they target, including the
Windows installers for Python or any other Windows installers
I use which provide such sigs.

The reason is simple:
The signature is a proof of authenticity which is not bound to
a particular file format or platform and before running .exes
it's good to know that they were built by the right people and
not manipulated by trojans, viruses or malicious proxies.

Is that a good enough reason to continue providing the GPG
sigs or do you need more proof of goodness ? ;-)

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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

Re: [Python-Dev] Do we need to sign Windows files with GnuPG?

[Steve Dower]

Larry Hastings wrote:
> Steve's also changed the authentication process. His new installers rely on a
> Windows digital signature technology called Authenticode where the signature 
> is
> built right into the .exe file. Windows platforms will automatically
> authenticate executables signed with Authenticode, so this is both secure and
> convenient.
> 
> Martin's build process also digitally signed the files he built, but not using
> Authenticode (or at least I don't think so). Like the Mac and source code
> releases, his automation used GnuPG to produce separate ".asc" files 
> containing
> digital signatures. This meant authentication was a manual process.

Martin previously only signed the installer with Authenticode, and generated a 
signature with GnuPG for the installer. My change now signs every binary and 
MSI in the entire installation with Authenticode, and for now I've stopped 
creating a GPG signature for the installers. I'm still providing sizes and MD5 
hashes for the user-visible downloads (except for the last alpha release, 
thanks Larry for covering for me).

With the installer also being a downloader, there are now actually 30+ files 
uploaded for each Windows release. Most of these are never seen by users unless 
they run the installer with /layout (sorry for not having changed this to 
/download yet... it's not as easily customizable as I'd hoped, but /layout is 
the standard name for this command), and if they're being downloaded by the 
installer then both hashes (embedded in the installer) and Authenticode 
signatures (embedded in each file) are being checked and will be blocked if 
they don't match. So verifying the EXE installer should always be sufficient to 
trust the rest of the installable files.

> The Authenticode approach sounds great. But there are advantages to the GnuPG
> approach too:

For reference, the main advantage of Authenticode signing is shown at 
https://technet.microsoft.com/en-us/library/dd835561(v=ws.10).aspx - about 
halfway down there are screenshots of the various dialogs that are displayed 
when you run signed vs. unsigned vs. blocked applications.

It also helps bypass SmartScreen, which will block downloaded files until 
they've developed a minimum level of trust. Simply having an Authenticode 
signature on the initial download meets this level.

(The summary of my opinion is that these two checks are sufficient for the 
initial EXE download, and the embedded hashes and signatures are sufficient for 
the rest. Having python.exe et al signed is a bonus that we've never done in 
the past.)

> * Using GnuPG means we can authenticate the files from any platform, not just
> Windows. If there were a security breach on the Python content delivery 
> network,
> any developer could get GnuPG for their platform and authenticate that the
> installers are unmodified. If we use Authenitcode,

There are tools out there for validating Authenticode on Linux, though none of 
them seem to be as complete as on Windows (it really needs the OS certificate 
store to be completely reliable), so I can certainly see the value in being 
able to verify these against a signature. My only question is whether/how this 
is better with GPG compared to say a SHA hash? I don't currently have a GPG key 
(to my knowledge), so it's not like there's any preexisting trust to build from 
- or am I misunderstanding how GPG works here?

> * GnuPG is agnostic about the data it digitally signs. So, for example, 
> Martin's
> build process digitally signs the Windows help file--the ".chm" file--produced
> by his build process. The help file Steve builds is currently completely
> unsigned; Steve says he can try signing it but he's not sure it'll work. Note
> that .chm files actually can contain live code, so this is at least a 
> plausible
> vector for attack.

Authenticode is not supported for CHM files, unfortunately. If this is the only 
file that we decide needs GPG, I'd vote to stop offering the download apart 
from the interpreter :) (Among other things, I'm not supposed to use GPG 
without specific permission from the lawyers at work because of the license...)

> My Windows development days are firmly behind me. So I don't really have an
> opinion here. So I put it to you, Windows Python developers: do you care about
> GnuPG signatures on Windows-specific files? Or do you not care?

The later replies seem to suggest that they are general goodness that nobody on 
Windows will use. If someone convinces me (or steamrolls me, that's fine too) 
that the goodness of GPG is better than a hash then I'll look into adding it 
into the process. Otherwise I'll happily add hash generation into the upload 
process (which I'm going to do anyway for the ones displayed on the download 
page).

Cheers,
Steve
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/pyth

[Python-Dev] Summary of Python tracker Issues

[Python tracker]

ACTIVITY SUMMARY (2015-03-27 - 2015-04-03)
Python tracker at http://bugs.python.org/

To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.

Issues counts and deltas:
  open4838 (+19)
  closed 30782 (+50)
  total  35620 (+69)

Open issues with patches: 2252 


Issues opened (52)
==

#23466: PEP 461: Inconsistency between str and bytes formatting of int
http://bugs.python.org/issue23466  reopened by ethan.furman

#23752: Cleanup io.FileIO
http://bugs.python.org/issue23752  reopened by haypo

#23791: Identify Moved Lines with difflib
http://bugs.python.org/issue23791  opened by bkiefer

#23794: http package should support HTTP/2
http://bugs.python.org/issue23794  opened by alex

#23795: argparse -- incorrect usage for mutually exclusive
http://bugs.python.org/issue23795  opened by jotomicron

#23796: BufferedReader.peek() crashes if closed
http://bugs.python.org/issue23796  opened by vadmium

#23797: Mac OS X locale setup in thread happens sometime after run() i
http://bugs.python.org/issue23797  opened by barry-scott

#23799: Join started threads in tests
http://bugs.python.org/issue23799  opened by serhiy.storchaka

#23800: Support POSIX uselocale interface for thread-specific locale s
http://bugs.python.org/issue23800  opened by ned.deily

#23802: patch: __deepcopy__ memo dict argument usage
http://bugs.python.org/issue23802  opened by danielsh

#23804: SSLSocket.recv(0) receives up to 1024 bytes
http://bugs.python.org/issue23804  opened by vadmium

#23805: _hashlib compile error?
http://bugs.python.org/issue23805  opened by SinusAlpha

#23806: documentation for no_proxy is missing from the python3 urllib 
http://bugs.python.org/issue23806  opened by r.david.murray

#23807: Improved test coverage for calendar.py command line
http://bugs.python.org/issue23807  opened by Thana Annis

#23808: Symlink to directory on Windows 8
http://bugs.python.org/issue23808  opened by serhiy.storchaka

#23809: RFE: emit a warning when a module in a traceback shadows a std
http://bugs.python.org/issue23809  opened by ncoghlan

#23810: Suboptimal stacklevel of deprecation warnings for formatter an
http://bugs.python.org/issue23810  opened by Arfrever

#23811: Python py_compile error message inconsistent and missing newli
http://bugs.python.org/issue23811  opened by akshetp

#23812: asyncio.Queue.put_nowait(), followed get() task cancellation l
http://bugs.python.org/issue23812  opened by gustavo

#23813: RSS and Atom feeds of buildbot results are broken
http://bugs.python.org/issue23813  opened by serhiy.storchaka

#23814: argparse: Parser level defaults do not always override argumen
http://bugs.python.org/issue23814  opened by kop

#23815: Segmentation fault when create _tkinter objects
http://bugs.python.org/issue23815  opened by serhiy.storchaka

#23816: struct.unpack returns null pascal strings - [first] bug report
http://bugs.python.org/issue23816  opened by jonheiner

#23817: Consider FreeBSD like any other OS in SOVERSION
http://bugs.python.org/issue23817  opened by bapt

#23819: test_asyncio fails when run under -O
http://bugs.python.org/issue23819  opened by brett.cannon

#23820: test_importlib fails under -O
http://bugs.python.org/issue23820  opened by brett.cannon

#23822: test_py_compile fails under -O
http://bugs.python.org/issue23822  opened by brett.cannon

#23825: test_idle fails under -OO
http://bugs.python.org/issue23825  opened by brett.cannon

#23826: test_enum fails under -OO
http://bugs.python.org/issue23826  opened by brett.cannon

#23828: test_socket testCmsgTruncLen0 gets "received malformed or impr
http://bugs.python.org/issue23828  opened by brett.cannon

#23830: Add AF_IUCV support to sockets
http://bugs.python.org/issue23830  opened by neale

#23831: tkinter canvas lacks of moveto method.
http://bugs.python.org/issue23831  opened by mps

#23832: pdb's `longlist` shows only decorator if that one contains a l
http://bugs.python.org/issue23832  opened by Gerrit.Holl

#23833: email.header.Header folding modifies headers that include semi
http://bugs.python.org/issue23833  opened by dseg

#23835: configparser does not convert defaults to strings
http://bugs.python.org/issue23835  opened by aragilar

#23837: read pipe transport tries to resume reading after loop is gone
http://bugs.python.org/issue23837  opened by mwf

#23839: Clear caches after every test
http://bugs.python.org/issue23839  opened by serhiy.storchaka

#23840: tokenize.open() leaks an open binary file on TextIOWrapper err
http://bugs.python.org/issue23840  opened by haypo

#23841: py34 OrderedDict is using weakref for root reference
http://bugs.python.org/issue23841  opened by sorin

#23842: SystemError: ../Objects/longobject.c:998: bad argument to inte
http://bugs.python.org/issue23842  opened by doko

#23843: ssl.wrap_socket doesn't handle virtual TLS hosts
http://bugs.python.org/issue23843  opened by nagle

#23845: test_ssl: fails on recent libressl with SSLV3_

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

[PJ Eby]

On Fri, Apr 3, 2015 at 8:44 AM, Martin Teichmann
 wrote:
> This proposal can actually be seen as an extension to the __class__
> and super() mechanism of normal methods: methods currently have the
> priviledge to know which classes they are defined in, while descriptors
> don't. So we could unify all this by giving functions a __post_process__
> method which sets the __class__ in the function body. This is about the
> same as what happened when functions got a __get__ method to turn
> them into object methods.
>
> While this all is in the making, PJ could monkey-patch __build_class__
> to do the steps described above, until it gets accepted into cpython.
> So I pose the question to PJ: would such an approach solve the
> problems you have?

Universal member post-processing actually works *better* for the
motivating use case than the metaclass or class level hooks, so yes.

In practice, there is one potential hiccup, and that's that decorators
which aren't aware of __post_process__ will end up masking it.  But
that's not an insurmountable obstacle.
___
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

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

[Nick Coghlan]

On 4 Apr 2015 00:29, "Martin Teichmann"  wrote:
>
> > When I first wrote PEP 422 I was of the view that "Python 2 allows
> > class definition postprocessing injection, we should allow it in
> > Python 3 as well". I've since changed my view to "Having to declare
> > post-processing of a class definition up front as a decorator, base
> > class or metaclass is a good thing for readability, as otherwise
> > there's nothing obvious when reading a class definition that tells you
> > whether or not postprocessing may happen, so you have to assume its
> > possible for *every* class definition".
>
> Nick, I couldn't agree more with you, yet I think PJ actually brought
> up a very interesting point. Post-processing is a very common thing
> these days, and has been re-written so many times that I think it is
> about time that something like it should be in the standard library.
>
> I'm less thinking about decorated methods, more about descriptors.
> They always have the problem that they don't know which attribute they
> belong to, so every author of a framework that defines descriptors
> writes a metaclass which goes through all the descriptors and tells
> them their attribute name.

Extending the descriptor protocol to include a per-descriptor hook that's
called at class definition time sounds like a potentially nice way to go to
me. While you *could* still use it to arbitrarily mutate the class object,
it's much clearer that's not the intended purpose, so I don't see it as a
major problem.

Cheers,
Nick.
___
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] Installing Python from the source code on Windows

[Narsu]

Hi Python 
I'm working on a game project,using c++ as main
language, and using python as script.I've built
the Python from the source code on Windows, and when I
invoked method Py_Initialize my program exited. After some tests
I realized  as long as I move the Python-2.7.9/Lib file
to my program file, it works fine. 
Please help me out . 
Thank you for your time.
Narsu‍___
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

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

[Martin Teichmann]

> When I first wrote PEP 422 I was of the view that "Python 2 allows
> class definition postprocessing injection, we should allow it in
> Python 3 as well". I've since changed my view to "Having to declare
> post-processing of a class definition up front as a decorator, base
> class or metaclass is a good thing for readability, as otherwise
> there's nothing obvious when reading a class definition that tells you
> whether or not postprocessing may happen, so you have to assume its
> possible for *every* class definition".

Nick, I couldn't agree more with you, yet I think PJ actually brought
up a very interesting point. Post-processing is a very common thing
these days, and has been re-written so many times that I think it is
about time that something like it should be in the standard library.

I'm less thinking about decorated methods, more about descriptors.
They always have the problem that they don't know which attribute they
belong to, so every author of a framework that defines descriptors
writes a metaclass which goes through all the descriptors and tells
them their attribute name.

I propose to have some metaclass in the standard library that does
that. I think it would fit nicely in my metaclass module proposed in
PEP 487.

It would basically do the following:

class Metaclass(type):
def __init__(self, name, bases, dict):
super().__init__(name, bases, dict)
for k, v in dict.items():
if hasattr(v, "__post_process__"):
v.__post_process__(k, self)

So each descriptor could define a __post_process__ hook that tells
it the attribute name and also the class it belongs to. This would for
sure also work for decorated methods.

This should mature on PyPI, then introduced into the standard library,
and if demand is really that high, maybe even be introduced into
type.__init__. It should be noted that this can also be easily written
as a PEP 487 class using __subclass_init__, I just used the classical
metaclass notion as I guess people are more used to that.

This proposal can actually be seen as an extension to the __class__
and super() mechanism of normal methods: methods currently have the
priviledge to know which classes they are defined in, while descriptors
don't. So we could unify all this by giving functions a __post_process__
method which sets the __class__ in the function body. This is about the
same as what happened when functions got a __get__ method to turn
them into object methods.

While this all is in the making, PJ could monkey-patch __build_class__
to do the steps described above, until it gets accepted into cpython.
So I pose the question to PJ: would such an approach solve the
problems you have?

Greetings

Martin
___
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

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[Brian Curtin]

On Fri, Apr 3, 2015 at 7:25 AM, Paul Moore  wrote:
> On 3 April 2015 at 10:56, Larry Hastings  wrote:
>> My Windows development days are firmly behind me.  So I don't really have an
>> opinion here.  So I put it to you, Windows Python developers: do you care
>> about GnuPG signatures on Windows-specific files?  Or do you not care?
>
> I don't have a very strong security background, so take my views with
> a pinch of saly, but I see Authenticode as a way of being sure that
> what I *run* is "OK". Whereas a GPG signature lets me check that the
> content of a file is as intended. So there are benefits to both, and I
> thing we should continue to provide GPG signatures. (Disclaimer: I've
> never in my life actually *checked* a GPG signature for a file...)

I haven't been on Windows in a bit, but this is my
understanding/expectation as well.
___
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

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[Barry Warsaw]

On Apr 03, 2015, at 02:56 AM, Larry Hastings wrote:

>My Windows development days are firmly behind me.  So I don't really have an
>opinion here.  So I put it to you, Windows Python developers: do you care
>about GnuPG signatures on Windows-specific files?  Or do you not care?

They're not mutually exclusive, so why not do both?

I think the advantage of being able to verify the files on any platform is
useful.

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/archive%40mail-archive.com

Re: [Python-Dev] Do we need to sign Windows files with GnuPG?

[Paul Moore]

On 3 April 2015 at 10:56, Larry Hastings  wrote:
> My Windows development days are firmly behind me.  So I don't really have an
> opinion here.  So I put it to you, Windows Python developers: do you care
> about GnuPG signatures on Windows-specific files?  Or do you not care?

I don't have a very strong security background, so take my views with
a pinch of saly, but I see Authenticode as a way of being sure that
what I *run* is "OK". Whereas a GPG signature lets me check that the
content of a file is as intended. So there are benefits to both, and I
thing we should continue to provide GPG signatures. (Disclaimer: I've
never in my life actually *checked* a GPG signature for a file...)

Paul
___
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

Re: [Python-Dev] Socket timeout: reset timeout at each successful syscall?

[Victor Stinner]

Oh, I forgot to explain that the problem is even more important in the
SSL module. In SSL, a single "recv()" may require to *send* data. The
SSL protocol is more complex and may require multiple OpenSSL calls
which imply multiple send/recv syscalls.

I wrote a patch for the ssl module to implement the PEP 475: to
recompute the timeout if the method (ex: select()) is interrupted by a
signal.
https://bugs.python.org/issue23853

My patch uses a global timeout, it doesn't reset the timeout at each
successful OpenSSL function call. And so it changes the behaviour
compared to Python 3.4. If we want to keep the same behaviour, we can
always reset the timeout except if a function was interrupted by
signal.

I opened the issue because the handshake() hangs if I send a singal
every millisecond, because the timeout is not recomputed. So select()
is called in a loop, always with the same timeout, and it always fail
with EINTR.

Victor

2015-04-03 13:56 GMT+02:00 Victor Stinner :
> Hi,
>
> I reworked the socket and ssl modules to better handle signals (to
> implement the PEP 475, retry on EINTR). These changes require to
> recompute timeout because syscalls are calling in a loop until it
> doesn't with EINTR (or EWOULDBLOCK or EGAIN). Most socket methods exit
> when the underlying syscall succeed.
>
> The problem is that the socket.sendall() method may require multiple
> syscalls. In this case, does the timeout count for the total time or
> only for a single syscall? Asked differently: should we reset the
> timeout each time a syscall succeed?
>
> Let's say that a server limits the bandwidth to 10 MB per second per
> client (or per connection). If I want to send 1000 MB, the request
> will take 100 seconds. Do you expect a timeout exception on calling
> call sendall() with a timeout of 60 seconds? Each call to send() may
> succeed in less than 60 seconds, for example each send() may send 1 MB
> in one second.
>
> In the socket documentation, I understand that the socket timeout is
> the total duration of an operation, not the maximum duration of a
> single syscall:
>
> https://docs.python.org/dev/library/socket.html#socket-timeouts
> "In timeout mode, operations fail if they cannot be completed within
> the timeout specified for the socket (they raise a timeout exception)
> or if the system returns an error."
>
> In Python 2.7, 3.4 and 3.5, socket.sendall() resets the timeout after
> each send() success.
>
> We had similar questions in the asyncio module, especially for
> StreamReader methods which can require multiple reads. I propose a
> patch to add a timeout parameter to StreamReader: it resets the
> timeout after each successful read. It's already possible to put a
> global timeout on any asyncio operationg. StreamReader timeout patch:
> https://bugs.python.org/issue23236
>
> Note: there is also an open issue to add a socket.recvall() method
> which would open similar question on timeout:
> https://bugs.python.org/issue1103213
>
> 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/archive%40mail-archive.com

[Python-Dev] Socket timeout: reset timeout at each successful syscall?

[Victor Stinner]

Hi,

I reworked the socket and ssl modules to better handle signals (to
implement the PEP 475, retry on EINTR). These changes require to
recompute timeout because syscalls are calling in a loop until it
doesn't with EINTR (or EWOULDBLOCK or EGAIN). Most socket methods exit
when the underlying syscall succeed.

The problem is that the socket.sendall() method may require multiple
syscalls. In this case, does the timeout count for the total time or
only for a single syscall? Asked differently: should we reset the
timeout each time a syscall succeed?

Let's say that a server limits the bandwidth to 10 MB per second per
client (or per connection). If I want to send 1000 MB, the request
will take 100 seconds. Do you expect a timeout exception on calling
call sendall() with a timeout of 60 seconds? Each call to send() may
succeed in less than 60 seconds, for example each send() may send 1 MB
in one second.

In the socket documentation, I understand that the socket timeout is
the total duration of an operation, not the maximum duration of a
single syscall:

https://docs.python.org/dev/library/socket.html#socket-timeouts
"In timeout mode, operations fail if they cannot be completed within
the timeout specified for the socket (they raise a timeout exception)
or if the system returns an error."

In Python 2.7, 3.4 and 3.5, socket.sendall() resets the timeout after
each send() success.

We had similar questions in the asyncio module, especially for
StreamReader methods which can require multiple reads. I propose a
patch to add a timeout parameter to StreamReader: it resets the
timeout after each successful read. It's already possible to put a
global timeout on any asyncio operationg. StreamReader timeout patch:
https://bugs.python.org/issue23236

Note: there is also an open issue to add a socket.recvall() method
which would open similar question on timeout:
https://bugs.python.org/issue1103213

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/archive%40mail-archive.com

Re: [Python-Dev] Do we need to sign Windows files with GnuPG?

[Martin Dengler]

On Fri, Apr 03, 2015 at 02:56:53AM -0700, Larry Hastings wrote:
> So I put it to you, Windows Python developers: do you care
> about GnuPG signatures on Windows-specific files?  Or do you not care?

Developer using python on windows here. I care, yes.

It's valuable and significant to be able to authenticate the files on different
platforms (your GnuPG advantage #1), and using the same tools.  It's also
useful to have a very mature tool to do that.  And valuable that all files can
be so validated, not just the .exes.

> //arry/

Martin


pgpOa9fc_5Nny.pgp
Description: PGP signature
___
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

Re: [Python-Dev] [python-committers] Do we need to sign Windows files with GnuPG?

[M.-A. Lemburg]

On 03.04.2015 11:56, Larry Hastings wrote:
> My Windows development days are firmly behind me.  So I don't really have an 
> opinion here.  So I put
> it to you, Windows Python developers: do you care about GnuPG signatures on 
> Windows-specific files? 
> Or do you not care?

Regardless of target platform, I firmly believe we should (continue to)
GPG sign all distribution files as well as provide hash files/values
for them.

This is very useful to detect corrupted downloads or files which
were not created by the original packagers.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source
>>> Python/Zope Consulting and Support ...http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/


::: Try our new mxODBC.Connect Python Database Interface for free ! 


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
___
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] Do we need to sign Windows files with GnuPG?

[Larry Hastings]

As of Python 3.5 Steve Dower has taken over the Windows builds of Python 
from Martin van Loewis.  He's also taken over for 2.7--though Martin's 
still doing builds for 3.4.


For both versions, Steve is using all-new tooling for the build 
process.  The output is different, too; he's producing .exe installers 
instead of .msi installers, and he has snazzy new "web-based" installers 
where the initial download is small, then it downloads the rest dynamically.


Steve's also changed the authentication process.  His new installers 
rely on a Windows digital signature technology called Authenticode where 
the signature is built right into the .exe file.  Windows platforms will 
automatically authenticate executables signed with Authenticode, so this 
is both secure and convenient.


Martin's build process also digitally signed the files he built, but not 
using Authenticode (or at least I don't think so).  Like the Mac and 
source code releases, his automation used GnuPG to produce separate 
".asc" files containing digital signatures.  This meant authentication 
was a manual process.


The Authenticode approach sounds great.  But there are advantages to the 
GnuPG approach too:


 * Using GnuPG means we can authenticate the files from any platform,
   not just Windows.  If there were a security breach on the Python
   content delivery network, any developer could get GnuPG for their
   platform and authenticate that the installers are unmodified.  If we
   use Authenitcode,
 * GnuPG is agnostic about the data it digitally signs.  So, for
   example, Martin's build process digitally signs the Windows help
   file--the ".chm" file--produced by his build process.  The help file
   Steve builds is currently completely unsigned; Steve says he can try
   signing it but he's not sure it'll work.  Note that .chm files
   actually /can/ contain live code, so this is at least a plausible
   vector for attack.


My Windows development days are firmly behind me.  So I don't really 
have an opinion here.  So I put it to you, Windows Python developers: do 
you care about GnuPG signatures on Windows-specific files?  Or do you 
not care?



//arry/

p.s. And, of course, my thanks to both Steve and Martin for their past 
and continuing service to the Python community!  It's a pleasure working 
with each of them.  (Both of them?  I forget how English works.)
___
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

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

[Nick Coghlan]

On 3 April 2015 at 18:21, Nick Coghlan  wrote:
> That means I'm now OK with monkeypatching __build_class__ being the
> only way to get dynamic hooking of the class currently being defined
> from the class body - folks that really want that behaviour can
> monkeypatch it in, while folks that think it's a bad idea don't need
> to worry about.

[snip]

> PEP 422 has never been approved - it's only ever been Draft or
> Deferred (and now Withdrawn). If you would like to take it over and
> champion it as a competitor to PEP 487, I'd be fine with that, I just
> no longer think it's a good idea myself.

[snip]

> Given my change of heart, I believe that at this point, if you were
> willing to champion a revived PEP 422 that implemented the behaviour
> you're after, that would be ideal, with monkeypatching the desired
> behaviour in as a fallback plan if the PEP is still ultimately
> rejected. Alternatively, you could go the monkeypatching path first,
> and then potentially seek standardisation later after you've had some
> practical experience with it - I now consider it an orthogonal
> capability to the feature in PEP 487, so the acceptance of the latter
> wouldn't necessarily preclude acceptance of a hook for class
> postprocessing injection.

Heh, editing fail. Writing out this post in full made me realise the
last of these options was a potentially reasonable path forward, but I
didn't go back and correct the earlier sections where I was viewing
the situation differently. So if the post reads a self-contradictory,
that's because it is, but the last one is the one that best reflects
my current thinking :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@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/archive%40mail-archive.com

Re: [Python-Dev] PEP 487 vs 422 (dynamic class decoration)

[Nick Coghlan]

On 3 April 2015 at 11:32, PJ Eby  wrote:
> On Thu, Apr 2, 2015 at 6:24 PM, Martin Teichmann
>  wrote:
>> The whole point of PEP 487 was to reduce PEP 422 so much that
>> it can be written in python and back-ported.
>
> As I said earlier, it's a fine feature and should be in the stdlib for
> Python 3.  (But it should have a `noconflict` feature added, and it
> doesn't need a language change.)
>
> However, since my specific use case was the one PEP 422 was originally
> written to solve, and PEP 487 does not address that use case, it is
> not a suitable substitute *for PEP 422*.
>
> This is also not your fault; you didn't force Nick to withdraw it,
> after all.  ;-)
>
> My main concern in this thread, however, is ensuring that either the
> use case behind PEP 422 doesn't get dropped, or that Nick is now okay
> with me implementing that feature by monkeypatching __build_class__.
> Since he practically begged me not to do that in 2012, and IIRC
> *specifically created* PEP 422 to provide an alternative way for me to
> accomplish this *specific* use case, I wanted to see what his current
> take was.  (That is, did he forget the history of the PEP, or does he
> no longer care about userspace code hooking __build_class__?  Is there
> some other proposal that would be a viable alternative? etc.)

It's actually both - I'd forgotten the origins of PEP 422, *and* I've
come around to the view that this level of implicit behaviour is a bad
idea because it's inherently confusing. The various incarnations of
PEP 422 ended up remaining at least somewhat confusing for *me* and I
wrote it. The "what happens when?" story in PEP 487 is much simpler.

That means I'm now OK with monkeypatching __build_class__ being the
only way to get dynamic hooking of the class currently being defined
from the class body - folks that really want that behaviour can
monkeypatch it in, while folks that think it's a bad idea don't need
to worry about.

>> Now you want to be able to write decorators whose details
>> are filled in at class creation time.
>
> Not "now"; it's been possible to do this in Python 2 for over a
> decade, and code that does so is in current use by other packages.
> The package providing this feature (DecoratorTools) was downloaded 145
> times today, and 3274 times in the past month, so there is active,
> current use of it by other Python 2 packages.  (Though I don't know
> how many of them depend directly or indirectly upon this particular
> feature.)
>
> Currently, however, it is not possible to port this feature of
> DecoratorTools (or any other package that uses that feature,
> recursively) to Python 3, due to the removal of __metaclass__ and the
> lack of any suitable substitute hook.

Right, any post-namespace-execution modification of class definitions
in Python 3 currently has to be declared in the class definition
header, either as an explicit decorator, as a metaclass declaration,
or through inheritance from a particular base class.

PEP 487 doesn't change that, it just adds a way for the last case to
work without needing a custom metaclass in the picture.

PEP 422 *did* change that, by providing a way for the namespace itself
to register a post-execution hook, akin to one of the way's
__metaclass__ could be used in Python 2.

What's changed since I first wrote PEP 422 is that I've come to view
the requirement to be explicit in Python 3 as a gain for readability,
rather than as a limitation to be eliminated - there will always be
*some* hint in the class header that post-namespace-execution
modifications may be happening, even if it's just having a declared
base class other than object.

>> Your point is that you want to be able to use your decorators
>> without having to ask users to also inherit a specific class.
>> I personally don't think that's desirable.  Many frameworks out
>> there have such kind of decorators and mandatory base classes
>> and that works fine.
>
> The intended use case is for generic method decorators that have
> nothing to do with the base class per se, so inheriting from a
> specific base-class is an anti-feature in this case.

If that's the use case, it would be preferable to explore enhancing
the type based dispatch capabilities in functools as a follow-up to
Guido's work on type hinting enhacements.

>> The only problem remains once you need to
>> inherit more than one of those classes, as their metaclasses
>> most likely clash. This is what PEP 487 fixes.
>
> No, it addresses the issue for certain *specific* metaclass use cases.
> It does not solve the problem of metaclass conflict in general; for
> that you need something like the sample `noconflict` code I posted,
> which works for Python 3.1+ and doesn't require a language change.

Neither PEP 422 nor 487 are designed to eliminate metaclass conflicts
in general, they're primarily designed to let base classes run
arbitrary code after the namespace has been executed in a subclass
definition *without* needing a custom metaclass. They