Re: [Python-Dev] python3.5.3: xmlrpc_net unit test fail
That unit test was written when https://buildbot.python.org was running at Buildbot version 8 which had an XMLRPC interface. Last year, buildbot.python.org was upgraded to Buildbot version 9, which dropped the XMLRPC interface in favor of a REST API. So that link no longer works. The unit change was changed to skip: https://github.com/python/cpython/blob/master/Lib/test/test_xmlrpc_net.py#L8 -- Craig On Thu, Apr 12, 2018 at 3:16 AM, Nikita Gupta wrote: > Hi All, > > Before installing python 3.5.3, i performed the test cases provided with > the source tar ball. > But 3 tests failed. I figured out the reason for other 2. But 1 test case > is out of my understanding. > > Re-running test 'test_xmlrpc_net' in verbose mode > test_python_builders (test.test_xmlrpc_net.PythonBuildersTest) ... ERROR > > == > ERROR: test_python_builders (test.test_xmlrpc_net.PythonBuildersTest) > -- > Traceback (most recent call last): > File "/pkgs/Python-3.5.3/Lib/test/test_xmlrpc_net.py", line 17, in > test_python_builders > builders = server.getAllBuilders() > File "/pkgs/Python-3.5.3/Lib/xmlrpc/client.py", line 1092, in __call__ > return self.__send(self.__name, args) > File "/pkgs/Python-3.5.3/Lib/xmlrpc/client.py", line 1432, in __request > verbose=self.__verbose > File "/pkgs/Python-3.5.3/Lib/xmlrpc/client.py", line 1134, in request > return self.single_request(host, handler, request_body, verbose) > File "/pkgs/Python-3.5.3/Lib/xmlrpc/client.py", line 1167, in > single_request > dict(resp.getheaders()) > xmlrpc.client.ProtocolError: xmlrpc/: 503 Service Unavailable> > > -- > Ran 1 test in 0.215s > > FAILED (errors=1) > test test_xmlrpc_net failed > > Can somebody highlight the reason of failure. > > > -- > Regards, > Nikita Gupta > > ___ > 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/ > rodrigc%40freebsd.org > > ___ 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] Slow down...
On Sun, May 6, 2018 at 7:35 PM Nick Coghlan wrote: > > I'm inclined to agree that a Python 3.8 PEP in the spirit of the PEP 3003 > language moratorium could be a very good idea. Between matrix > multiplication, enhanced tuple unpacking, native coroutines, f-strings, and > type hinting for variable assignments, we've had quite a bit of syntactic > churn in the past few releases, and the rest of the ecosystem really hasn't > caught up on it all yet (and that's not just other implementations - it's > training material, online courses, etc, etc). > > If we're going to take such a step, now's also the time to do it, since > 3.8 feature development is only just getting under way, and if we did > decide to repeat the language moratorium, we could co-announce it with the > Python 3.7 release. > > Would it be reasonable to request a 10 year moratorium on making changes to the core Python language, and for the next 10 years only focus on things that do not require core language changes, such as improving/bugfixing existing libraries, writing new libraries, improving tooling, improving infrastructure (PyPI), improving performance, etc., etc.? There are still many companies still stuck on Python 2, so giving 10 years of breathing room for these companies to catch up to Python 3 core language, even past 2020 would be very helpful. -- Craig ___ 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] Slow down...
On Mon, May 7, 2018 at 2:24 PM Barry Warsaw wrote: > On May 7, 2018, at 11:49, Craig Rodrigues wrote: > > > > Would it be reasonable to request a 10 year moratorium on making changes > to the core Python language, > > and for the next 10 years only focus on things that do not require core > language changes, > > such as improving/bugfixing existing libraries, writing new libraries, > improving tooling, improving infrastructure (PyPI), > > improving performance, etc., etc.? > > IMHO, no. > > I don’t believe that the way for Python to remain relevant and useful for > the next 10 years is to cease all language evolution. Who knows what the > computing landscape will look like in 5 years, let alone 10? Something as > arbitrary as a 10 year moratorium is (again, IMHO) a death sentence for the > language. > > But I do think it makes sense to think about how Python-the-language and > CPython-the-reference implementation can better balance the desire to > evolve vs the need to concentrate on improving what we’ve got. With that > in mind, it does make sense to occasionally use a moratorium release to > focus on tech debt, cleaning up the stdlib, improve performance, etc. > > CPython’s 18 month release cycle has served us well for a long time, but I > do think it’s time to discuss whether it will still be appropriate moving > forward. I’m not saying it is or isn’t, but with the release of 3.7, I > think it’s a great time to explore our options. > > 10 years is a long time for many types of applications, such as web server and desktop applications where regular and somewhat frequent upgrades can happen. However, I have worked on embedding Python in networking and storage devices. It is true that many of these types of devices can also have their software upgraded, but often the frequency of such upgrades is much slower than for conventional web server and desktop applications. Upgrades of these devices usually spans user-space and kernel/device drivers, so upgrades are usually done more cautiously and less frequently. For Python 2.x, the ship has sailed. However, 10 years from now, if the Python language is pretty much the same as Python 3.7 today, that would be nice. I'm not stuck on the number "10 years", but I am just throwing it out there as a draft proposal. So even 5-8 year moratorium would be nice to strive for. Outside of the embedded space, I will give another example where folks in industry are behind. I don't want to pick on a particular vendor, but from April 24-26, I attended training sessions at RedisConf18 in San Francisco. During the training sessions, multiple sample Python code examples were given for accessing the Redis database. The instructor thought that the code examples worked in Python 3, but in fact, they only worked in Python 2 mostly due to bytes/unicode issues. During the class, I fixed the examples for Python 3 and submitted the patches to the instructor, who gratefully accepted my patches. However, there are going to be many, many users of Redis out there who maybe will not upgrade their Python code for newer versions of Python for many years. Besides Redis users, I am seeing all sorts of communities and companies which are behind in terms of having working code and documentation that works on latest Python 3. It is going to take YEARS for all these communities and companies to catch up (if ever). I understand that Python as a language must evolve over time to succeed and thrive. But I would request that at least for the next 5-10 years, a moratorium on language changes be considered, to allow the world to catch up in terms of code, documentation, and mind/understanding. Looking back at how the Python 2.7 EOL was extended by 5 years, I would remind the core Python developers that it is very easy to underestimate how slow the world is to change their code, documentation, training, and understanding to adapt to new Python versions. Going slow or imposing a moratorium wouldn't be such a bad thing. -- Craig ___ 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] Porting buildbot to Python 3
Hi, It's not essential, but I thought it would be nice to port buildbot to Python 3. I've managed to submit multiple simple patches to buildbot, which were quickly accepted: https://github.com/buildbot/buildbot/pulls/rodrigc?q=is%3Apr+is%3Aclosed Now things are more slow going as the easy stuff is out of the way and I am submitting more complicated things: https://github.com/buildbot/buildbot/pulls/rodrigc Is there anyone on python-dev who has the interest and free cycles to push Python 3 fixes to the buildbot team? Thanks. -- Craig ___ 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] Generator objects and list comprehensions?
Hi, Glyph pointed this out to me here: http://twistedmatrix.com/pipermail/twisted-python/2017-January/031106.html If I do this on Python 3.6: >> [(yield 1) for x in range(10)] at 0x10cd210f8> If I understand this: https://docs.python.org/3/reference/expressions.html#list-displays then this is a list display and should give a list, not a generator object. Is there a bug in Python, or does the documentation need to be updated? -- Craig ___ 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] Generator objects and list comprehensions?
On Thu, Jan 26, 2017 at 4:09 AM, Ivan Levkivskyi wrote: > > > Concerning list/set/dict comprehensions, I am much more in favor of making > comprehensions simply equivalent to for-loops (more or less like you > proposed using yield from). The only reason to introduce auxiliary function > scope was to prevent the loop variables from leaking outside comprehensions. > Formally, this is indeed backward incompatible, but I doubt many people > depend on the current counter-intuitive behavior. > > Concerning generator expressions, probably it is indeed better to simply > prohibit yield inside them. > > Thank you to everyone who responded to my post and provided excellent analysis. For Python, I don't know what the best way to proceed is: OPTION 1 Make a SyntaxError: [(yield 1) for x in range(10)] and update the documentation to explain that this is an invalid construct. This would have certainly helped me identify the source of the problem as I tried porting buildbot 0.9 to Python 3. However, while not very common, there is Python 2.x code that uses that. I found these cases in the buildbot code which I changed so as to work on Python 2 and 3: https://github.com/buildbot/buildbot/pull/2661 https://github.com/buildbot/buildbot/pull/2673 OPTION 2 = Make this return a list on Python 3, like in Python 2: [ (yield 1) for x in range(10)] As pointed out by others on the this mailing list, there are some problems associated with that. I don't know if there are many Python 2 codebases out there with this construct, but it would be nice to have one less Python 2 -> 3 porting gotcha. I'm OK with either approach. Leaving things the way they are in Python 3 is no good, IMHO. -- Craig ___ 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] Format strings, Unicode, and Py2.7: need clarification
Hi,
While cleaning up some code during Python 2 -> Python 3 porting,
I switched some code to use str.format(), I found this behavor:
Python 2.7
=
a = "%s" % "hi"
b = "%s" % u"hi"
c = u"%s" % "hi"
d = "{}".format("hi")
e = "{}".format(u"hi")
f = u"{}".format("hi")
type(a) == str
type(b) == unicode
type(c) == unicode
type(d) == str
type(e) == str
type(f) == unicode
My intuition would lead me to believe that type(b)
and type(e) would be the same (unicode), but they are not.
The confusion for me is why is type(e) of type str, and not unicode?
Can someone clarify this for me?
I understand that in Python 3, all these cases are str, so it is not
as big a problem there, but I am trying to keep things working on
Python 2.7.
Thanks.
--
Craig
___
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] Inquiry on Buildbot
Corwyn, This mailing list is related to development on Python itself, and not really oriented to support questions for buildbot. For setting up buildbot under Windows 10, I recommend that you go to https://buildbot.net and read the documentation there for installing buildbot. If you need further help, that web site has pointers to buildbot-specific mailing lists. The wiki page you read for BuildbotOnWindows is very old and outdated, so it is not a good guide to follow. -- Craig On Thu, Jun 15, 2017 at 7:40 PM, Blaine Corwyn Aboy wrote: > Hello Ms/Mr Python People, > > I'm Corwyn Aboy and am a student of the University of the Philippines and > currently working on a project to create a buildbot system on a Windows 10 > machine and would like to ask for guidance in doing so. I've read the > BuildbotOnWindows in your wiki.python.org website but have not yet tried > it out. > > I would like to ask if the same steps would still apply to installing it > on a Windows 10 machine. It would be really great to hear some feedback as > soon as possible. > > Thank you for your time. > > ___ > 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/ > rodrigc%40freebsd.org > > ___ 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] New workflow change: Welcome to blurb
On Fri, Jun 23, 2017 at 8:24 PM, Larry Hastings wrote: > > > We've been talking about addressing this for years. Fixing this was one > of the goals of the new workflow. And finally, as of right now, the future > is here. Ladies and gentlemen, I present: blurb. > > https://github.com/python/core-workflow/tree/master/blurb > > Yes, when you have a single NEWS file that needs to get updated, the process begins to fall apart when you have a pull request type of workflow which results in many merge conflicts to the single NEWS file. Twisted and Buildbot use towncrier ( https://github.com/hawkowl/towncrier ) which tries to solve the same problem as blurb. The developer needs to commit individual newsfragment files to the tree along with their pull request. At release time, the release engineer runs towncrier which aggregates the individual newsfragments into a single NEWS file. The NEWS file is not checked in, but the release engineer makes it available as part of official release tarballs. -- Craig ___ 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
