Re: [Python-Dev] Coding practice for context managers
On 21 Oct 2013 12:44, "Raymond Hettinger" wrote: > > Two of the new context managers in contextlib are now wrapped in pass-through factory functions. The intent is to make the help() look cleaner. This practice does have downsides however. > > The usual way to detect whether something is usable with a with-statement is to check the presence of the __enter__ and __exit__ methods. Wrapping the CM in a pass-through function defeats this and other forms of introspection. > > Also, the help() output itself is worse-off. When you run help on a CM(), you're trying to find-out what happens on entry and what happens on exit. If those methods had docstrings, the question would be answered directly. The wrapper (intentionally) hides how it works. > > Since I teach intermediate and advanced python classes to experienced Python users, I've become more sensitive to problems this practice will create. Defeating introspection can make the help look nicer, but it isn't a clean coding practice and is something I hope doesn't catch on. > > To the extent there is a problem with the output of help(), I think efforts should be directed at making help() better. A lot of work needs to be done on that end -- for example abstract base classes also don't look great in help(). > > There are a couple of other minor issues as well. One is that the wrapper function hides the class, making it harder to do type checks such as "isinstance(x, suppress)". The other issue is that wrappers cause extra jumping around for people who are tracing code through a debugger or using a visualization tool such as pythontutor. These aren't terribly important issues, but it does support the notion that usually the cleanest code is the best code. > > In short, I recommend that efforts be directed at improving help() rather than limiting introspection by way of less clean coding practices. That's a fair point, but I *really* dislike exposing implementations that don't match their documentation, and both of these are currently documented as factory functions. There's also the fact that I prefer the current lower case names, but strongly dislike using lower case names for classes (despite the fact closing was included in the original contextlib with a non PEP 8 compliant class name). (And yes, I now realise I completely failed to mention either of those points in the comments giving the rationale for the wrapper functions). Exposing the full object oriented API is certainly a reasonable option, but the docs should be updated accordingly, with suitable public attributes being defined (providing access to the exception tuple for suppress and the target stream for redirect_stdio). Cheers, Nick. > > > Raymond > > > current code for suppress() > > class _SuppressExceptions: > """Helper for suppress.""" > def __init__(self, *exceptions): > self._exceptions = exceptions > > def __enter__(self): > pass > > def __exit__(self, exctype, excinst, exctb): > return exctype is not None and issubclass(exctype, self._exceptions) > > # Use a wrapper function since we don't care about supporting inheritance > # and a function gives much cleaner output in help() > def suppress(*exceptions): > """Context manager to suppress specified exceptions > > After the exception is suppressed, execution proceeds with the next > statement following the with statement. > > with suppress(FileNotFoundError): > os.remove(somefile) > # Execution still resumes here if the file was already removed > """ > return _SuppressExceptions(*exceptions) > > > current help() output for suppress() > > Help on function suppress in module contextlib: > > suppress(*exceptions) > Context manager to suppress specified exceptions > > After the exception is suppressed, execution proceeds with the next > statement following the with statement. > > with suppress(FileNotFoundError): > os.remove(somefile) > # Execution still resumes here if the file was already removed > > current help() output for closing() with does not have a function wrapper > > Help on class closing in module contextlib: > > class closing(builtins.object) > | Context to automatically close something at the end of a block. > | > | Code like this: > | > | with closing(.open()) as f: > | > | > | is equivalent to this: > | > | f = .open() > | try: > | > | finally: > | f.close() > | > | Methods defined here: > | > | __enter__(self) > | > | __exit__(self, *exc_info) > | > | __init__(self, thing) > | > | -- > | Data descriptors defined here: > | > | __dict__ > | dictionary for instance variables (if defined) > | > | __weakref__ > | list of weak references to the object (if defined)
Re: [Python-Dev] Coding practice for context managers
On Sun, 20 Oct 2013 19:49:24 -0700, Ethan Furman wrote: > On 10/20/2013 07:42 PM, Raymond Hettinger wrote: > > > > In short, I recommend that efforts be directed at improving help() rather > > than limiting introspection by way of less clean coding practices. > > +1 I'm also +1 on improving help instead of using wrapper classes. > We also have the option of adding a custom __dir__ to change what help() > displays. I think you'd want to be careful about __dir__ also interfering with introspection if it is used *just* to make the help cleaner. --David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coding practice for context managers
On 21 October 2013 11:59, R. David Murray wrote: > On Sun, 20 Oct 2013 19:49:24 -0700, Ethan Furman wrote: >> On 10/20/2013 07:42 PM, Raymond Hettinger wrote: >> > >> > In short, I recommend that efforts be directed at improving help() rather >> > than limiting introspection by way of less clean coding practices. >> >> +1 > > I'm also +1 on improving help instead of using wrapper classes. Agreed. A wrapper function whose purpose is solely to tidy up help seems like a bad idea in general. I'm somewhat more sympathetic to Nick's point that the name the user types should be all-lowercase and a class would be mixed case, but on that I think it's actually the naming convention that should change (name classes/functions based on usage, not implementation). The rule to me is that changing the underlying implementation shouldn't affect the user interface. Paul ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coding practice for context managers
On Mon, 21 Oct 2013 12:11:57 +0100, Paul Moore wrote: > On 21 October 2013 11:59, R. David Murray wrote: > > On Sun, 20 Oct 2013 19:49:24 -0700, Ethan Furman wrote: > >> On 10/20/2013 07:42 PM, Raymond Hettinger wrote: > >> > > >> > In short, I recommend that efforts be directed at improving help() > >> > rather than limiting introspection by way of less clean coding practices. > >> > >> +1 > > > > I'm also +1 on improving help instead of using wrapper classes. > > Agreed. A wrapper function whose purpose is solely to tidy up help > seems like a bad idea in general. > > I'm somewhat more sympathetic to Nick's point that the name the user > types should be all-lowercase and a class would be mixed case, but on > that I think it's actually the naming convention that should change > (name classes/functions based on usage, not implementation). The rule > to me is that changing the underlying implementation shouldn't affect > the user interface. +1. I've run into this tension between the naming convention and wanting to change the underlying API before, and I think the naming convention gets in the way. --David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coding practice for context managers
On Mon, 21 Oct 2013 07:21:11 -0400, "R. David Murray" wrote: > On Mon, 21 Oct 2013 12:11:57 +0100, Paul Moore wrote: > > On 21 October 2013 11:59, R. David Murray wrote: > > > On Sun, 20 Oct 2013 19:49:24 -0700, Ethan Furman > > > wrote: > > >> On 10/20/2013 07:42 PM, Raymond Hettinger wrote: > > >> > > > >> > In short, I recommend that efforts be directed at improving help() > > >> > rather than limiting introspection by way of less clean coding > > >> > practices. > > >> > > >> +1 > > > > > > I'm also +1 on improving help instead of using wrapper classes. > > > > Agreed. A wrapper function whose purpose is solely to tidy up help > > seems like a bad idea in general. > > > > I'm somewhat more sympathetic to Nick's point that the name the user > > types should be all-lowercase and a class would be mixed case, but on > > that I think it's actually the naming convention that should change > > (name classes/functions based on usage, not implementation). The rule > > to me is that changing the underlying implementation shouldn't affect > > the user interface. > > +1. I've run into this tension between the naming convention and > wanting to change the underlying API before, and I think the > naming convention gets in the way. Grr. The underlying *implementation*. This specifically came up in the case of whether a factory function was a function or a class. A class is a perfectly good factory function, but API-wise is often seems more natural to document it and name it as a function. --David ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coding practice for context managers
On 21 Oct 2013 21:22, "R. David Murray" wrote: > > On Mon, 21 Oct 2013 12:11:57 +0100, Paul Moore wrote: > > On 21 October 2013 11:59, R. David Murray wrote: > > > On Sun, 20 Oct 2013 19:49:24 -0700, Ethan Furman wrote: > > >> On 10/20/2013 07:42 PM, Raymond Hettinger wrote: > > >> > > > >> > In short, I recommend that efforts be directed at improving help() rather than limiting introspection by way of less clean coding practices. > > >> > > >> +1 > > > > > > I'm also +1 on improving help instead of using wrapper classes. > > > > Agreed. A wrapper function whose purpose is solely to tidy up help > > seems like a bad idea in general. > > > > I'm somewhat more sympathetic to Nick's point that the name the user > > types should be all-lowercase and a class would be mixed case, but on > > that I think it's actually the naming convention that should change > > (name classes/functions based on usage, not implementation). The rule > > to me is that changing the underlying implementation shouldn't affect > > the user interface. > > +1. I've run into this tension between the naming convention and > wanting to change the underlying API before, and I think the > naming convention gets in the way. Right, I think we may want to reconsider that guideline, because I just realised it helped nudge me into introducing an outright bug: using wrapper functions as I did means help() on instances will pick up the private helper class which is definitely *not* what we want. (Perhaps we could relax the rule to require initial capitals for abstract types, but allow it to be skipped for concrete classes? That would better match what we actually do in the builtins and stdlib). Regardless, lesson learned, I'll create an issue and put a patch on the tracker to create a public OO API for these as described in my previous message (but using the current names). Cheers, Nick. > > --David > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coding practice for context managers
Le Mon, 21 Oct 2013 20:46:39 +1000, Nick Coghlan a écrit : > On 21 Oct 2013 12:44, "Raymond Hettinger" > wrote: > > > > Two of the new context managers in contextlib are now wrapped in > pass-through factory functions. The intent is to make the help() look > cleaner. This practice does have downsides however. > > > > The usual way to detect whether something is usable with a > > with-statement > is to check the presence of the __enter__ and __exit__ methods. > Wrapping the CM in a pass-through function defeats this and other > forms of introspection. > > > > Also, the help() output itself is worse-off. When you run help on a > CM(), you're trying to find-out what happens on entry and what > happens on exit. If those methods had docstrings, the question would > be answered directly. The wrapper (intentionally) hides how it > works. > > > > Since I teach intermediate and advanced python classes to > > experienced > Python users, I've become more sensitive to problems this practice > will create. Defeating introspection can make the help look nicer, > but it isn't a clean coding practice and is something I hope doesn't > catch on. > > > > To the extent there is a problem with the output of help(), I think > efforts should be directed at making help() better. A lot of work > needs to be done on that end -- for example abstract base classes > also don't look great in help(). > > > > There are a couple of other minor issues as well. One is that the > wrapper function hides the class, making it harder to do type checks > such as "isinstance(x, suppress)". The other issue is that wrappers > cause extra jumping around for people who are tracing code through a > debugger or using a visualization tool such as pythontutor. These > aren't terribly important issues, but it does support the notion that > usually the cleanest code is the best code. > > > > In short, I recommend that efforts be directed at improving help() > > rather > than limiting introspection by way of less clean coding practices. > > That's a fair point, but I *really* dislike exposing implementations > that don't match their documentation, and both of these are currently > documented as factory functions. Let's call them callables instead? > Exposing the full object oriented API is certainly a reasonable > option, but the docs should be updated accordingly, with suitable > public attributes being defined (providing access to the exception > tuple for suppress and the target stream for redirect_stdio). I don't get why adding public attributes should be related to the proposed change. Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coding practice for context managers
On 21 Oct 2013 22:10, "Antoine Pitrou" wrote: > > Le Mon, 21 Oct 2013 20:46:39 +1000, > Nick Coghlan a écrit : > > On 21 Oct 2013 12:44, "Raymond Hettinger" > > wrote: > > > > > > Two of the new context managers in contextlib are now wrapped in > > pass-through factory functions. The intent is to make the help() look > > cleaner. This practice does have downsides however. > > > > > > The usual way to detect whether something is usable with a > > > with-statement > > is to check the presence of the __enter__ and __exit__ methods. > > Wrapping the CM in a pass-through function defeats this and other > > forms of introspection. > > > > > > Also, the help() output itself is worse-off. When you run help on a > > CM(), you're trying to find-out what happens on entry and what > > happens on exit. If those methods had docstrings, the question would > > be answered directly. The wrapper (intentionally) hides how it > > works. > > > > > > Since I teach intermediate and advanced python classes to > > > experienced > > Python users, I've become more sensitive to problems this practice > > will create. Defeating introspection can make the help look nicer, > > but it isn't a clean coding practice and is something I hope doesn't > > catch on. > > > > > > To the extent there is a problem with the output of help(), I think > > efforts should be directed at making help() better. A lot of work > > needs to be done on that end -- for example abstract base classes > > also don't look great in help(). > > > > > > There are a couple of other minor issues as well. One is that the > > wrapper function hides the class, making it harder to do type checks > > such as "isinstance(x, suppress)". The other issue is that wrappers > > cause extra jumping around for people who are tracing code through a > > debugger or using a visualization tool such as pythontutor. These > > aren't terribly important issues, but it does support the notion that > > usually the cleanest code is the best code. > > > > > > In short, I recommend that efforts be directed at improving help() > > > rather > > than limiting introspection by way of less clean coding practices. > > > > That's a fair point, but I *really* dislike exposing implementations > > that don't match their documentation, and both of these are currently > > documented as factory functions. > > Let's call them callables instead? > > > Exposing the full object oriented API is certainly a reasonable > > option, but the docs should be updated accordingly, with suitable > > public attributes being defined (providing access to the exception > > tuple for suppress and the target stream for redirect_stdio). > > I don't get why adding public attributes should be related to the > proposed change. Because redirect_stdout previously had undocumented attributes without an underscore prefix, and it was after I had already renamed those and was deciding whether or not to make suppress.exceptions public (and return self from suppress.__enter__) that I had my ill-advised brainwave about postponing dealing with all those questions by hiding the implementation of both of them behind factory functions. Postponing the questions didn't work, so I may as well address them instead. Cheers, Nick. > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coding practice for context managers
Le Mon, 21 Oct 2013 23:12:40 +1000, Nick Coghlan a écrit : > On 21 Oct 2013 22:10, "Antoine Pitrou" wrote: > > > > Le Mon, 21 Oct 2013 20:46:39 +1000, > > Nick Coghlan a écrit : > > > On 21 Oct 2013 12:44, "Raymond Hettinger" > > > wrote: > > > > > > > > Two of the new context managers in contextlib are now wrapped in > > > pass-through factory functions. The intent is to make the help() > > > look cleaner. This practice does have downsides however. > > > > > > > > The usual way to detect whether something is usable with a > > > > with-statement > > > is to check the presence of the __enter__ and __exit__ methods. > > > Wrapping the CM in a pass-through function defeats this and other > > > forms of introspection. > > > > > > > > Also, the help() output itself is worse-off. When you run help > > > > on a > > > CM(), you're trying to find-out what happens on entry and what > > > happens on exit. If those methods had docstrings, the question > > > would be answered directly. The wrapper (intentionally) hides > > > how it works. > > > > > > > > Since I teach intermediate and advanced python classes to > > > > experienced > > > Python users, I've become more sensitive to problems this practice > > > will create. Defeating introspection can make the help look > > > nicer, but it isn't a clean coding practice and is something I > > > hope doesn't catch on. > > > > > > > > To the extent there is a problem with the output of help(), I > > > > think > > > efforts should be directed at making help() better. A lot of > > > work needs to be done on that end -- for example abstract base > > > classes also don't look great in help(). > > > > > > > > There are a couple of other minor issues as well. One is that > > > > the > > > wrapper function hides the class, making it harder to do type > > > checks such as "isinstance(x, suppress)". The other issue is > > > that wrappers cause extra jumping around for people who are > > > tracing code through a debugger or using a visualization tool > > > such as pythontutor. These aren't terribly important issues, > > > but it does support the notion that usually the cleanest code is > > > the best code. > > > > > > > > In short, I recommend that efforts be directed at improving > > > > help() rather > > > than limiting introspection by way of less clean coding practices. > > > > > > That's a fair point, but I *really* dislike exposing > > > implementations that don't match their documentation, and both of > > > these are currently documented as factory functions. > > > > Let's call them callables instead? > > > > > Exposing the full object oriented API is certainly a reasonable > > > option, but the docs should be updated accordingly, with suitable > > > public attributes being defined (providing access to the exception > > > tuple for suppress and the target stream for redirect_stdio). > > > > I don't get why adding public attributes should be related to the > > proposed change. > > Because redirect_stdout previously had undocumented attributes > without an underscore prefix, and it was after I had already renamed > those and was deciding whether or not to make suppress.exceptions > public (and return self from suppress.__enter__) that I had my > ill-advised brainwave about postponing dealing with all those > questions by hiding the implementation of both of them behind factory > functions. So how about simply adding an underscore to all those attributes? Regards Antoine. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coding practice for context managers
On Oct 21, 2013, at 08:46 PM, Nick Coghlan wrote: >There's also the fact that I prefer the current lower case names, but >strongly dislike using lower case names for classes (despite the fact >closing was included in the original contextlib with a non PEP 8 compliant >class name). Ha! The only thing I don't much like about ExitStack is its capword name. ;) I don't have a problem breaking PEP 8 rules for cases like this. -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coding practice for context managers
On Oct 21, 2013, at 08:46 PM, Nick Coghlan wrote: >There's also the fact that I prefer the current lower case names, but >strongly dislike using lower case names for classes (despite the fact >closing was included in the original contextlib with a non PEP 8 compliant >class name). I think PEP 8 needs to be slightly revised. If you have suggestions for better wording, please comment here: http://bugs.python.org/issue19331 (But *please* let's not bikeshed this on python-dev.) -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 2.6.9 final final due out 28 October 2013
This is a reminder that Python 2.6.9 final - and by that I mean *really* final as it will be the last supported version of Python 2.6 - is scheduled for release one week from today, on October 28, 2013. All known showstopper security bugs have been applied to the branch. If you know of anything that should go into Python 2.6 but has not yet, please contact me asap. Please test rc1 on your platforms and code, and let me know if you have any problems. Barring any showstoppers, I will likely cut the release AM my local time. Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Coding practice for context managers
On 21 Oct 2013 23:54, "Antoine Pitrou" wrote: > > Le Mon, 21 Oct 2013 23:12:40 +1000, > Nick Coghlan a écrit : > > On 21 Oct 2013 22:10, "Antoine Pitrou" wrote: > > > > > > Le Mon, 21 Oct 2013 20:46:39 +1000, > > > Nick Coghlan a écrit : > > > > On 21 Oct 2013 12:44, "Raymond Hettinger" > > > > wrote: > > > > > > > > > > Two of the new context managers in contextlib are now wrapped in > > > > pass-through factory functions. The intent is to make the help() > > > > look cleaner. This practice does have downsides however. > > > > > > > > > > The usual way to detect whether something is usable with a > > > > > with-statement > > > > is to check the presence of the __enter__ and __exit__ methods. > > > > Wrapping the CM in a pass-through function defeats this and other > > > > forms of introspection. > > > > > > > > > > Also, the help() output itself is worse-off. When you run help > > > > > on a > > > > CM(), you're trying to find-out what happens on entry and what > > > > happens on exit. If those methods had docstrings, the question > > > > would be answered directly. The wrapper (intentionally) hides > > > > how it works. > > > > > > > > > > Since I teach intermediate and advanced python classes to > > > > > experienced > > > > Python users, I've become more sensitive to problems this practice > > > > will create. Defeating introspection can make the help look > > > > nicer, but it isn't a clean coding practice and is something I > > > > hope doesn't catch on. > > > > > > > > > > To the extent there is a problem with the output of help(), I > > > > > think > > > > efforts should be directed at making help() better. A lot of > > > > work needs to be done on that end -- for example abstract base > > > > classes also don't look great in help(). > > > > > > > > > > There are a couple of other minor issues as well. One is that > > > > > the > > > > wrapper function hides the class, making it harder to do type > > > > checks such as "isinstance(x, suppress)". The other issue is > > > > that wrappers cause extra jumping around for people who are > > > > tracing code through a debugger or using a visualization tool > > > > such as pythontutor. These aren't terribly important issues, > > > > but it does support the notion that usually the cleanest code is > > > > the best code. > > > > > > > > > > In short, I recommend that efforts be directed at improving > > > > > help() rather > > > > than limiting introspection by way of less clean coding practices. > > > > > > > > That's a fair point, but I *really* dislike exposing > > > > implementations that don't match their documentation, and both of > > > > these are currently documented as factory functions. > > > > > > Let's call them callables instead? > > > > > > > Exposing the full object oriented API is certainly a reasonable > > > > option, but the docs should be updated accordingly, with suitable > > > > public attributes being defined (providing access to the exception > > > > tuple for suppress and the target stream for redirect_stdio). > > > > > > I don't get why adding public attributes should be related to the > > > proposed change. > > > > Because redirect_stdout previously had undocumented attributes > > without an underscore prefix, and it was after I had already renamed > > those and was deciding whether or not to make suppress.exceptions > > public (and return self from suppress.__enter__) that I had my > > ill-advised brainwave about postponing dealing with all those > > questions by hiding the implementation of both of them behind factory > > functions. > > So how about simply adding an underscore to all those attributes? Certainly an option, but they both have sensible public attributes to offer. Bug is at http://bugs.python.org/issue19330 I'll probably let it sit for a week or so, though, since I'm apparently still too annoyed about the bikeshedding megathread to think entirely clearly about the module API at this point. Cheers, Nick. > > Regards > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Hashes on same site as download?
I may be missing something, but it seems the Python tarballs and hashes are on the same host, and this is not an entirely good thing for security. The way things are now, an attacker breaks into one host, doctors up a tarball, changes the hashes in the same host, and people download without noticing, even if they verify hashes. If you put the hashes on a different host from the tarballs, the attacker has to break into two machines. In this scenario, the hashes add more strength. ISTR I first learned of this issue from an article by Bruce Schneier, though I don't think it was in the context of Python. ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hashes on same site as download?
On Oct 21, 2013, at 06:21 PM, Dan Stromberg wrote: >I may be missing something, but it seems the Python tarballs and hashes are >on the same host, and this is not an entirely good thing for security. All the tarballs are signed with the GPG keys of the release managers. The hashes are just a quick verification that your download succeeded. For extra confidence, check the signatures. Our keys should be independently verifiable. -Barry ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hashes on same site as download?
On 22 October 2013 12:21, Dan Stromberg wrote: > > I may be missing something, but it seems the Python tarballs and hashes > are on the same host, and this is not an entirely good thing for security. > > The way things are now, an attacker breaks into one host, doctors up a > tarball, changes the hashes in the same host, and people download without > noticing, even if they verify hashes. > > If you put the hashes on a different host from the tarballs, the attacker > has to break into two machines. In this scenario, the hashes add more > strength. > I'm not a security expert, but I can't see how that gives any more security than the current system (I tried to find whatever article you're talking about, but failed). It doesn't matter if you provide downloads in one place and direct people to get the hashes from elsewhere. An attacker has no need to compromise the server where the hashes are stored - they only need to compromise the server that tells you where to get the downloads and hashes. Then the attacker can simply change the download page to direct you to the malicious downloads, hashes and keys (which they can place on the same server, so everything looks legit). Off the top of my head, one way that would give more security would be to store a hash of the download page itself elsewhere (preferably multiple places) and periodically compare that with the live version. Any changes to the live page would be noticed (eventually) unless the attacker also compromised all those other machines. Tim Delaney ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Hashes on same site as download?
On Mon, Oct 21, 2013 at 6:47 PM, Tim Delaney wrote: > On 22 October 2013 12:21, Dan Stromberg wrote: > >> >> I may be missing something, but it seems the Python tarballs and hashes >> are on the same host, and this is not an entirely good thing for security. >> > I was missing the gpg signing. That's probably more effective than md5 anyway - at least, I hope we're not using gpg with md5 :) Looking at the download pages in rapid-skim-mode, I saw the hashes and ignored the text describing the use of gpg. FWIW, I'm guessing a lot of people do that. The way things are now, an attacker breaks into one host, doctors up a >> tarball, changes the hashes in the same host, and people download without >> noticing, even if they verify hashes. >> >> If you put the hashes on a different host from the tarballs, the attacker >> has to break into two machines. In this scenario, the hashes add more >> strength. >> > > I'm not a security expert, but I can't see how that gives any more > security than the current system (I tried to find whatever article you're > talking about, but failed). It doesn't matter if you provide downloads in > one place and direct people to get the hashes from elsewhere. An attacker > has no need to compromise the server where the hashes are stored - they > only need to compromise the server that tells you where to get the > downloads and hashes. > I don't see the original article anymore, but I believe it was in a Crypto-gram newsletter several years ago. The closest thing I found tonight was: http://en.wikipedia.org/wiki/MD5#Applications ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] #19335 is a codeop, not Idle issue
I know that many core devs subscribe to the new tracker issues list. If you skipped over http://bugs.python.org/issue19335 because it was (mis) titled as an Idle issue (as I presume most would), you might want to reconsider as it is actually a code and in particular, a codeop issue. Consider the real interpreter. C:\Programs\Python33>python Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> def a(): ... def b(): ... nonlocal c ... _ It waits to see if one enters a blank line (to which it properly responds SyntaxError), or continues with something that makes the statement syntactically valid. ... c = 1 ... >>> The 'close simulation' in the code module acts differently. C:\Programs\Python33>python -m code Python 3.3.2 (v3.3.2:d047928ae3f6, May 16 2013, 00:06:53) [MSC v.1600 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. (InteractiveConsole) >>> def a(): ... def b(): ... nonlocal c File "", line None SyntaxError: no binding for nonlocal 'c' found It prematurely acts as if one had entered a fourth, blank line. InteractiveConsole subclasses InteractiveInterpreter (as does Idle, hence the same behavior). II.runsource compiles with codeop.CommandCompile, which wraps codeop._maybe_compile, which returns None (src incomplete), raises (src complete and bad), or returns code (complete and ok) to be executed. For the above code, it re-raises SyntaxError instead of returning None. The issue needs someone who can find and read the C equivalent used by the real interpreter. Perhaps the latter was adjusted when nonlocal was introduced, while codeop was not. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
