Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On 17 August 2014 15:08, Guido van Rossum wrote: > I think this would be a great topic for a blog post. Once you've written it > I can even bless it by Tweeting about it. :-) Sounds like a plan - I'll try to put together something coherent this week :) > PS. Why isn't PEP 387 accepted yet? Not sure - it mostly looks correct to me. I suspect it just fell off the radar since it's a "describe what we're already doing anyway" kind of document. 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 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
I think this would be a great topic for a blog post. Once you've written it I can even bless it by Tweeting about it. :-) PS. Why isn't PEP 387 accepted yet? On Sat, Aug 16, 2014 at 8:48 PM, Nick Coghlan wrote: > On 17 August 2014 12:43, Guido van Rossum wrote: > > On Sat, Aug 16, 2014 at 6:28 PM, Nick Coghlan > wrote: > >> I've also had people express the concern that "you broke compatibility > >> in a major way once, how do we know you won't do it again?". > > > > > > Well, they won't, really. You can't predict the future. But really, > that's a > > pretty poor way to say "please don't do it again." > > > > I'm not sure why, but I hate when someone starts a suggestion or a > question > > with "why doesn't Python ..." and I have to fight the urge to reply in a > > flippant way without answering the real question. (And just now I did it > > again.) > > > > I suppose this phrasing may actually be meant as a form of politeness, > but > > to me it often sounds passive-aggressive, pretend-polite. (Could it be a > > matter of cultural difference? The internet is full of broken English, my > > own often included.) > > I don't mind it if the typical answers are accepted as valid: > > * "because it has these downsides, and those are considered to > outweigh the benefits" > * "because it's difficult, and it never bothered anyone enough for > them to put in the work to do something about it" > > Those aren't always obvious, especially to folks that don't have a lot > of experience with long lived software projects (I had only just > started high school when Python was first released!), so I don't mind > explaining them when I have time. > > >> Both of those contrast strongly with Guido's stated position that he > >> never wants to go through a transition like the 2->3 one again. > > > > Right. What's more, when I say that, I don't mean that you should wait > until > > I retire -- I think it's genuinely a bad idea. > > Absolutely agreed - I think the Unicode change was worthwhile (even > with the impact proving to be higher than expected), but there isn't > any such fundamental change to the data model lurking for Python 3. > > > I also don't expect that it'll be necessary -- in fact, I am counting on > > tools (e.g. static analysis!) to improve to the point where there won't > be a > > reason for such a transition. > > The fact that things like Hylang and MacroPy can already run on the > CPython VM also shows that other features (like import hooks and the > AST compiler) have evolved to the point where the Python data model > and runtime semantics can be more effectively decoupled from syntactic > details. > > > (Don't understand this to mean that we should never deprecate things. > > Deprecations will happen, they are necessary for the evolution of any > > programming language. But they won't ever hurt in the way that Python 3 > > hurt.) > > Right. I think Python 2 has been stable for so long that I sometimes > wonder if folks forget (or never knew?) we used to deprecate things > within the Python 2 series as well, such that code that ran on Python > 2.x wasn't necessarily guaranteed to run on Python 2.(x+2). "Never > deprecate anything" is a recipe for unbounded growth in complexity. > > Benjamin has made a decent start on documenting that normal > deprecation process in PEP 387, so I'd also suggest refining that a > bit and getting it to "Accepted" as part of any explicit "Python 4.x > won't be as disruptive as 3.x" clarification. > > >> no plans to create a Python 2.8 release. Would it be worth writing a > >> similarly explicit "not an option" PEP explaining that the regular > >> deprecation and removal process (roughly documented in PEP 387) is the > >> *only* deprecation and removal process? It could also point to the > >> fact that we now have PEP 411 (provisional APIs) to help reduce our > >> chances of being locked indefinitely into design decisions we aren't > >> happy with. > >> > >> If folks (most significantly, Guido) are amenable to the idea, it > >> > >> shouldn't take long to put such a PEP together, and I think it could > >> help reduce some of the confusions around the expectations for Python > >> 4.0 and the evolution of 3.x in general. > > > > But what should it say? > > The specific things I was thinking we could point out were: > > - PEP 387, documenting the normal deprecation process that existed > even in Python 2 > - highlighting the increased preference for "documented deprecation > only" in cases where maintaining something isn't actively causing > problems, there are just better alternatives now available > - PEP 411, the (still relatively new) provisional API concept > - PEP 405, adding pyvenv as a standard part of Python > - PEP 453, better integrating PyPI into the recommended way of working > with the language > > Those all help change the way the language evolves, as they reduce the > pressure to rush things into the standard library before they're > ready, while at the same
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On 17 August 2014 12:43, Guido van Rossum wrote: > On Sat, Aug 16, 2014 at 6:28 PM, Nick Coghlan wrote: >> I've also had people express the concern that "you broke compatibility >> in a major way once, how do we know you won't do it again?". > > > Well, they won't, really. You can't predict the future. But really, that's a > pretty poor way to say "please don't do it again." > > I'm not sure why, but I hate when someone starts a suggestion or a question > with "why doesn't Python ..." and I have to fight the urge to reply in a > flippant way without answering the real question. (And just now I did it > again.) > > I suppose this phrasing may actually be meant as a form of politeness, but > to me it often sounds passive-aggressive, pretend-polite. (Could it be a > matter of cultural difference? The internet is full of broken English, my > own often included.) I don't mind it if the typical answers are accepted as valid: * "because it has these downsides, and those are considered to outweigh the benefits" * "because it's difficult, and it never bothered anyone enough for them to put in the work to do something about it" Those aren't always obvious, especially to folks that don't have a lot of experience with long lived software projects (I had only just started high school when Python was first released!), so I don't mind explaining them when I have time. >> Both of those contrast strongly with Guido's stated position that he >> never wants to go through a transition like the 2->3 one again. > > Right. What's more, when I say that, I don't mean that you should wait until > I retire -- I think it's genuinely a bad idea. Absolutely agreed - I think the Unicode change was worthwhile (even with the impact proving to be higher than expected), but there isn't any such fundamental change to the data model lurking for Python 3. > I also don't expect that it'll be necessary -- in fact, I am counting on > tools (e.g. static analysis!) to improve to the point where there won't be a > reason for such a transition. The fact that things like Hylang and MacroPy can already run on the CPython VM also shows that other features (like import hooks and the AST compiler) have evolved to the point where the Python data model and runtime semantics can be more effectively decoupled from syntactic details. > (Don't understand this to mean that we should never deprecate things. > Deprecations will happen, they are necessary for the evolution of any > programming language. But they won't ever hurt in the way that Python 3 > hurt.) Right. I think Python 2 has been stable for so long that I sometimes wonder if folks forget (or never knew?) we used to deprecate things within the Python 2 series as well, such that code that ran on Python 2.x wasn't necessarily guaranteed to run on Python 2.(x+2). "Never deprecate anything" is a recipe for unbounded growth in complexity. Benjamin has made a decent start on documenting that normal deprecation process in PEP 387, so I'd also suggest refining that a bit and getting it to "Accepted" as part of any explicit "Python 4.x won't be as disruptive as 3.x" clarification. >> no plans to create a Python 2.8 release. Would it be worth writing a >> similarly explicit "not an option" PEP explaining that the regular >> deprecation and removal process (roughly documented in PEP 387) is the >> *only* deprecation and removal process? It could also point to the >> fact that we now have PEP 411 (provisional APIs) to help reduce our >> chances of being locked indefinitely into design decisions we aren't >> happy with. >> >> If folks (most significantly, Guido) are amenable to the idea, it >> >> shouldn't take long to put such a PEP together, and I think it could >> help reduce some of the confusions around the expectations for Python >> 4.0 and the evolution of 3.x in general. > > But what should it say? The specific things I was thinking we could point out were: - PEP 387, documenting the normal deprecation process that existed even in Python 2 - highlighting the increased preference for "documented deprecation only" in cases where maintaining something isn't actively causing problems, there are just better alternatives now available - PEP 411, the (still relatively new) provisional API concept - PEP 405, adding pyvenv as a standard part of Python - PEP 453, better integrating PyPI into the recommended way of working with the language Those all help change the way the language evolves, as they reduce the pressure to rush things into the standard library before they're ready, while at the same time giving us a chance to publish "not quite ready to be locked down" features for very broad feedback. I'd also point out that the "variable encodings" to "Unicode" transition for text handling is an industry wide issue, one which even operating systems are still struggling with in some cases. POSIX-only software that only needs to run on modern platforms can assume UTF-8, while modern Windows and Java
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On Aug 16, 2014, at 7:43 PM, Guido van Rossum wrote: > But can we really say there won't be a 4.0? Never? Why not? Who is to say > that at some point some folks won't be going off on their own to design a > whole new language and name it Python 4, following Larry Wall's Perl 6 > example? If they ever do, please make them not follow the Perl 6 example! -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev ___ 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 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On Aug 16, 2014, at 6:28 PM, Nick Coghlan wrote: > I've seen a few people on python-ideas express the assumption that > there will be another Py3k style compatibility break for Python 4.0. Whenever I mention Python 4 or PEP 4000, it’s always a joke. However, saying upfront that we will never break compatibility is a bold statement. Technically even introducing new syntax breaks compatibility. Not to mention fixing long-lasting bugs. So you’d need to split hairs just defining what we mean by a “major compatibility break”. Worse, if we ever did a change that we feel is within the bounds of the contract, you’d have someone pointing at that PEP saying that they feel we broke the contract. Splitting hairs again. PEP 404 was necessary for some people/organizations to move on. I fail to see how PEP 4000 (or rather PEP 4004? ;-)) would be useful in that context. -- Best regards, Łukasz Langa WWW: http://lukasz.langa.pl/ Twitter: @llanga IRC: ambv on #python-dev___ 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 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On Sat, Aug 16, 2014 at 6:28 PM, Nick Coghlan wrote: > I've seen a few people on python-ideas express the assumption that > there will be another Py3k style compatibility break for Python 4.0. > There used to be only joking references to 4.0 or py4k -- how things have changed! I've seen nothing that a gentle correction on the list couldn't fix though. > I've also had people express the concern that "you broke compatibility > in a major way once, how do we know you won't do it again?". > Well, they won't, really. You can't predict the future. But really, that's a pretty poor way to say "please don't do it again." I'm not sure why, but I hate when someone starts a suggestion or a question with "why doesn't Python ..." and I have to fight the urge to reply in a flippant way without answering the real question. (And just now I did it again.) I suppose this phrasing may actually be meant as a form of politeness, but to me it often sounds passive-aggressive, pretend-polite. (Could it be a matter of cultural difference? The internet is full of broken English, my own often included.) > Both of those contrast strongly with Guido's stated position that he > never wants to go through a transition like the 2->3 one again. > Right. What's more, when I say that, I don't mean that you should wait until I retire -- I think it's genuinely a bad idea. I also don't expect that it'll be necessary -- in fact, I am counting on tools (e.g. static analysis!) to improve to the point where there won't be a reason for such a transition. (Don't understand this to mean that we should never deprecate things. Deprecations will happen, they are necessary for the evolution of any programming language. But they won't ever hurt in the way that Python 3 hurt.) > Barry wrote PEP 404 to make it completely explicit that python-dev had > no plans to create a Python 2.8 release. Would it be worth writing a > similarly explicit "not an option" PEP explaining that the regular > deprecation and removal process (roughly documented in PEP 387) is the > *only* deprecation and removal process? It could also point to the > fact that we now have PEP 411 (provisional APIs) to help reduce our > chances of being locked indefinitely into design decisions we aren't > happy with. > > If folks (most significantly, Guido) are amenable to the idea, it > shouldn't take long to put such a PEP together, and I think it could > help reduce some of the confusions around the expectations for Python > 4.0 and the evolution of 3.x in general. > But what should it say? It's easy to say there won't be a 2.8 because we already have 3.0 (and 3.1, and 3.2, and ...). But can we really say there won't be a 4.0? Never? Why not? Who is to say that at some point some folks won't be going off on their own to design a whole new language and name it Python 4, following Larry Wall's Perl 6 example? I think it makes sense to occasionally remind the more eager contributors that we want the future to come gently (that's not to say in our sleep :-). But I'm not sure a PEP is the best form for such a reminder. Even the Pope has a Twitter account. :-) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
On Sun, Aug 17, 2014 at 11:28:48AM +1000, Nick Coghlan wrote: > I've seen a few people on python-ideas express the assumption that > there will be another Py3k style compatibility break for Python 4.0. I used to refer to Python 4000 as the hypothetical compatibility break version. Now I refer to Python 5000. > I've also had people express the concern that "you broke compatibility > in a major way once, how do we know you won't do it again?". Even languages with ISO standards behind them and release schedules measured in decades make backward-incompatible changes. For example, I see that Fortran 95 (despite being classified as a minor revision) deleted at least six language features. To expect Python to never break compatibility again is asking too much. But I think it is fair to promise that Python won't make *so many* backwards incompatible changes all at once again, and has no concrete plans to make backwards incompatible changes to syntax in the foreseeable future. (That is, not before Python 5000 :-) [...] > If folks (most signficantly, Guido) are amenable to the idea, it > shouldn't take long to put such a PEP together, and I think it could > help reduce some of the confusions around the expectations for Python > 4.0 and the evolution of 3.x in general. I think it's a good idea, so long as there's no implied or explicit promise that Python language is now set in stone never to change. -- Steven ___ 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] PEP 4000 to explicitly declare we won't be doing a Py3k style compatibility break again?
I've seen a few people on python-ideas express the assumption that there will be another Py3k style compatibility break for Python 4.0. I've also had people express the concern that "you broke compatibility in a major way once, how do we know you won't do it again?". Both of those contrast strongly with Guido's stated position that he never wants to go through a transition like the 2->3 one again. Barry wrote PEP 404 to make it completely explicit that python-dev had no plans to create a Python 2.8 release. Would it be worth writing a similarly explicit "not an option" PEP explaining that the regular deprecation and removal process (roughly documented in PEP 387) is the *only* deprecation and removal process? It could also point to the fact that we now have PEP 411 (provisional APIs) to help reduce our chances of being locked indefinitely into design decisions we aren't happy with. If folks (most signficantly, Guido) are amenable to the idea, it shouldn't take long to put such a PEP together, and I think it could help reduce some of the confusions around the expectations for Python 4.0 and the evolution of 3.x in general. Regards, 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] Multiline with statement line continuation
On 17 August 2014 07:42, Chris Angelico wrote:
> On Sat, Aug 16, 2014 at 10:47 PM, Marko Rauhamaa wrote:
>>
>> You might be able to have it bothways. You could have:
>>
>>with (open(name) for name in os.listdir("config")) as files:
>
> But that's not a tuple, it's a generator. Should generators be context
> managers? Is anyone seriously suggesting this? I don't think so. Is
> this solutions looking for problems?
Yes. We have a whole programming language to play with, when "X is
hard to read" becomes a problem, it may be time to reach for a better
tool. If the context manager line is getting unwieldy, it's often a
sign it's time to factor it out to a dedicated helper, or break it up
into multiple with statements :)
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] Multiline with statement line continuation
On Sat, Aug 16, 2014 at 10:47 PM, Marko Rauhamaa wrote:
>
> You might be able to have it bothways. You could have:
>
>with (open(name) for name in os.listdir("config")) as files:
But that's not a tuple, it's a generator. Should generators be context
managers? Is anyone seriously suggesting this? I don't think so. Is
this solutions looking for problems?
ChrisA
___
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] Multiline with statement line continuation
Steven D'Aprano :
> I simply don't care. They will try it, discover that tuples are not
> context managers, fix their code, and move on.
*Could* tuples (and lists and sequences) be context managers?
*Should* tuples (and lists and sequences) be context managers?
> I don't think that some vague similarity between it and tuples is
> justification for rejecting the proposal.
You might be able to have it bothways. You could have:
with (open(name) for name in os.listdir("config")) as files:
...
Marko
___
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] Multiline with statement line continuation
On Sat, Aug 16, 2014 at 05:25:33PM +1000, Ben Finney wrote:
[...]
> > they would have already mistaken:
> >
> > with a, b, c: ...
> >
> > the same way. But they haven't.
>
> Right. The presence or absence of parens make a big semantic difference.
from silly.mistakes.programmers.make import (
hands, up, anyone, who, thinks, this, is_, a, tuple)
def function(how, about, this, one): ...
But quite frankly, even if there is some person somewhere who gets
confused and tries to write:
context_managers = (open("a"), open("b", "w"), open("c", "w"))
with context_managers as things:
text = things[0].read()
things[1].write(text)
things[2].write(text.upper())
I simply don't care. They will try it, discover that tuples are not
context managers, fix their code, and move on. (I've made sillier
mistakes, and became a better programmer from it.)
We cannot paralyse ourselves out of fear that somebody, somewhere, will
make a silly mistake. You can try that "with tuple" code right now, and
you will get nice runtime exception. I admit that the error message is
not the most descriptive I've ever seen, but I've seen worse, and any
half-decent programmer can do what they do for any other unexpected
exception: read the Fine Manual, or ask for help, or otherwise debug the
problem. Why should this specific exception be treated as so harmful
that we have to forgo a useful piece of functionality to avoid it?
Some designs are bug-magnets, like the infamous "except A,B" syntax,
which fails silently, doing the wrong thing. Unless someone has a
convincing rationale for how and why this multi-line with will likewise
be a bug-magnet, I don't think that some vague similarity between it and
tuples is justification for rejecting the proposal.
--
Steven
___
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-checkins] cpython (2.7): Fix Issue #8797: Raise HTTPError on failed Basic Authentication immediately.
I added some extra coverage for basic auth in the tests and I notice that
in buildbots, some of them are throwing "error: [Errno 32] Broken pipe"
error.
I am looking into this and will fix this.
Thanks,
Senthil
On Sat, Aug 16, 2014 at 2:19 PM, senthil.kumaran wrote:
> http://hg.python.org/cpython/rev/e0510a3bdf8f
> changeset: 92111:e0510a3bdf8f
> branch: 2.7
> parent: 92097:6d41f139709b
> user:Senthil Kumaran
> date:Sat Aug 16 14:16:14 2014 +0530
> summary:
> Fix Issue #8797: Raise HTTPError on failed Basic Authentication
> immediately. Initial patch by Sam Bull.
>
> files:
> Lib/test/test_urllib2_localnet.py | 86 ++-
> Lib/urllib2.py| 19 +---
> Misc/NEWS | 3 +
> 3 files changed, 90 insertions(+), 18 deletions(-)
>
>
> diff --git a/Lib/test/test_urllib2_localnet.py
> b/Lib/test/test_urllib2_localnet.py
> --- a/Lib/test/test_urllib2_localnet.py
> +++ b/Lib/test/test_urllib2_localnet.py
> @@ -1,6 +1,8 @@
> +import base64
> import urlparse
> import urllib2
> import BaseHTTPServer
> +import SimpleHTTPServer
> import unittest
> import hashlib
>
> @@ -66,6 +68,48 @@
>
> # Authentication infrastructure
>
> +
> +class BasicAuthHandler(SimpleHTTPServer.SimpleHTTPRequestHandler):
> +"""Handler for performing Basic Authentication."""
> +# Server side values
> +USER = "testUser"
> +PASSWD = "testPass"
> +REALM = "Test"
> +USER_PASSWD = "%s:%s" % (USER, PASSWD)
> +ENCODED_AUTH = base64.b64encode(USER_PASSWD)
> +
> +def __init__(self, *args, **kwargs):
> +SimpleHTTPServer.SimpleHTTPRequestHandler.__init__(self, *args,
> + **kwargs)
> +
> +def log_message(self, format, *args):
> +# Supress the HTTP Console log output
> +pass
> +
> +def do_HEAD(self):
> +self.send_response(200)
> +self.send_header("Content-type", "text/html")
> +self.end_headers()
> +
> +def do_AUTHHEAD(self):
> +self.send_response(401)
> +self.send_header("WWW-Authenticate", "Basic realm=\"%s\"" %
> self.REALM)
> +self.send_header("Content-type", "text/html")
> +self.end_headers()
> +
> +def do_GET(self):
> +if self.headers.getheader("Authorization") == None:
> +self.do_AUTHHEAD()
> +self.wfile.write("No Auth Header Received")
> +elif self.headers.getheader(
> +"Authorization") == "Basic " + self.ENCODED_AUTH:
> +SimpleHTTPServer.SimpleHTTPRequestHandler.do_GET(self)
> +else:
> +self.do_AUTHHEAD()
> +self.wfile.write(self.headers.getheader("Authorization"))
> +self.wfile.write("Not Authenticated")
> +
> +
> class DigestAuthHandler:
> """Handler for performing digest authentication."""
>
> @@ -228,6 +272,45 @@
> test_support.threading_cleanup(*self._threads)
>
>
> +class BasicAuthTests(BaseTestCase):
> +USER = "testUser"
> +PASSWD = "testPass"
> +INCORRECT_PASSWD = "Incorrect"
> +REALM = "Test"
> +
> +def setUp(self):
> +super(BasicAuthTests, self).setUp()
> +# With Basic Authentication
> +def http_server_with_basic_auth_handler(*args, **kwargs):
> +return BasicAuthHandler(*args, **kwargs)
> +self.server =
> LoopbackHttpServerThread(http_server_with_basic_auth_handler)
> +self.server_url = 'http://127.0.0.1:%s' % self.server.port
> +self.server.start()
> +self.server.ready.wait()
> +
> +def tearDown(self):
> +self.server.stop()
> +super(BasicAuthTests, self).tearDown()
> +
> +def test_basic_auth_success(self):
> +ah = urllib2.HTTPBasicAuthHandler()
> +ah.add_password(self.REALM, self.server_url, self.USER,
> self.PASSWD)
> +urllib2.install_opener(urllib2.build_opener(ah))
> +try:
> +self.assertTrue(urllib2.urlopen(self.server_url))
> +except urllib2.HTTPError:
> +self.fail("Basic Auth Failed for url: %s" % self.server_url)
> +except Exception as e:
> +raise e
> +
> +def test_basic_auth_httperror(self):
> +ah = urllib2.HTTPBasicAuthHandler()
> +ah.add_password(self.REALM, self.server_url, self.USER,
> +self.INCORRECT_PASSWD)
> +urllib2.install_opener(urllib2.build_opener(ah))
> +self.assertRaises(urllib2.HTTPError, urllib2.urlopen,
> self.server_url)
> +
> +
> class ProxyAuthTests(BaseTestCase):
> URL = "http://localhost";
>
> @@ -240,6 +323,7 @@
> self.digest_auth_handler = DigestAuthHandler()
> self.digest_auth_handler.set_users({self.USER: self.PASSWD})
> self.digest_auth_handler.set_realm(self.REALM)
> +# With Digest Authentication
> def create_fake_proxy_handler(*args, **kwargs):
> return FakeProxyHandler(self.digest_
Re: [Python-Dev] Multiline with statement line continuation
On Sat, Aug 16, 2014 at 12:25 AM, Ben Finney wrote: > Steven D'Aprano writes: > >> If people were going to be prone to mistake >> >> with (a, b, c): ... >> >> as including a tuple > > … because the parens are a strong signal “this is an expression to be > evaluated, resulting in a single value to use in the statement”. > >> they would have already mistaken: >> >> with a, b, c: ... >> >> the same way. But they haven't. > > Right. The presence or absence of parens make a big semantic difference. At least historically so, since "except a, b:" and "except (a, b):" used to be different things (only the latter constructs a tuple in 2.x). OTOH, consider "from .. import (..., ..., ...)". Pretty sure at this point parens can be used for non-expressions quite reasonably -- although I'd still prefer just allowing newlines without requiring extra syntax. -- Devin ___ 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] Multiline with statement line continuation
Steven D'Aprano writes: > If people were going to be prone to mistake > > with (a, b, c): ... > > as including a tuple … because the parens are a strong signal “this is an expression to be evaluated, resulting in a single value to use in the statement”. > they would have already mistaken: > > with a, b, c: ... > > the same way. But they haven't. Right. The presence or absence of parens make a big semantic difference. -- \ “The process by which banks create money is so simple that the | `\ mind is repelled.” —John Kenneth Galbraith, _Money: Whence It | _o__) Came, Where It Went_, 1975 | Ben Finney ___ 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
