Re: [Python-Dev] General Q&A regarding Python 3, adoption etc.
On 7 Jan 2014 07:46, "Antoine Pitrou" wrote: > > I assume it's > http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html Thanks, that's the one - I copied the link, but neglected to paste it in before hitting send :P Cheers, Nick. > > Regards > > Antoine. > > > ___ > 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/ncoghlan%40gmail.com ___ 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] General Q&A regarding Python 3, adoption etc.
On 1/6/2014 3:16 PM, Nick Coghlan wrote: I thought I mentioned it on this list last year when I first wrote it, but some messages I've seen recently suggest many folks haven't seen it before. And even more will see it if you provide a link. Please. Emile ___ 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] General Q&A regarding Python 3, adoption etc.
On Tue, 7 Jan 2014 09:16:10 +1000 Nick Coghlan wrote: > For anyone that isn't already aware, I wrote a Q & A about Python 3 last > year (in response to an article about how we should have fixed the GIL > instead of Unicode), and I've updated it extensively over the past several > days due to Alex's misunderstanding of the objectives for Python 3.4 as > well as Armin's latest piece on the increased difficulties in writing wire > protocol handling code. A couple remarks: - the unicode section would gain being a little more on the practical side; for example the "surrogateescape" paragraph is an obscure and theoretical way of saying unicode filepaths (etc.) are fully supported on all platforms - also, it doesn't seem very clear that the primary string type (str) is now unicode; this has important consequences, for example non-ASCII exception messages work fine in 3.x while they were very delicate to work with in 2.x - when discussing Twisted / gevent alternatives, you should also mention Tornado, which is especially interesting because it works on both Python 2 and Python 3, and therefore presents a nice migration path - perhaps you should discuss the idea that "uptake is slow", because the numbers are rather conflicting on that point; see what I wrote in https://mail.python.org/pipermail/python-list/2014-January/663922.html and also Chris Angelico's elaboration in https://mail.python.org/pipermail/python-list/2014-January/664003.html Regards Antoine. ___ 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] Proposed: The Great Argument Clinic Conversion Derby
On Mon, Jan 6, 2014 at 3:40 PM, Skip Montanaro wrote: > On Mon, Jan 6, 2014 at 2:17 PM, Antoine Pitrou > wrote: > >> I agree with Serhiy, but that is probably known at this point. :) > > > > I agree with Serhiy and you too. Clinic's current output makes C files > > more tedious to read, and I'm not really willing to participate in the > > "conversion derby" because of that. > > My first thought was that this exercise falls into the realm of fixing > things which aren't broken. > The gain in introspection now and possible automated improvements later (e.g. if we come up with a faster way to parse arguments it will automatically propagate through the code base) make it worth it. ___ 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] General Q&A regarding Python 3, adoption etc.
On Mon, 06 Jan 2014 23:25:12 + Mark Lawrence wrote: > On 06/01/2014 23:16, Nick Coghlan wrote: > > For anyone that isn't already aware, I wrote a Q & A about Python 3 last > > year (in response to an article about how we should have fixed the GIL > > instead of Unicode), and I've updated it extensively over the past > > several days due to Alex's misunderstanding of the objectives for Python > > 3.4 as well as Armin's latest piece on the increased difficulties in > > writing wire protocol handling code. > > > > The two main additions I currently have planned are a question > > specifically about the state of the WSGI protocol (it works, but it an > > error prone way), as well as one on what I'd like to see as the next > > steps in encouraging Python 3 adoption now that we're within 18 months > > of the planned date for 2.7 to enter security fix only mode (which > > involve encouraging community workshops to switch to teaching Python 3.4 > > initially, with Python 2.7 as an optional follow up, helping Ubuntu & > > Fedora with their transitions to Py3 by default, bringing 3.5 closer to > > parity with Python 2 for wire protocol development, and, on the Red > > Hat/Fedora side, helping to encourage the adoption of software > > collections as a mechanism for decoupling the runtime for Python > > applications from the system Python on RHEL 6 and its derivatives. > > > > I thought I mentioned it on this list last year when I first wrote it, > > but some messages I've seen recently suggest many folks haven't seen it > > before. > > > > Cheers, > > Nick. > > > > Is it on the back of a fag packet or is there a link somewhere? :) I assume it's http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html Regards Antoine. ___ 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] General Q&A regarding Python 3, adoption etc.
On 06/01/2014 23:16, Nick Coghlan wrote: For anyone that isn't already aware, I wrote a Q & A about Python 3 last year (in response to an article about how we should have fixed the GIL instead of Unicode), and I've updated it extensively over the past several days due to Alex's misunderstanding of the objectives for Python 3.4 as well as Armin's latest piece on the increased difficulties in writing wire protocol handling code. The two main additions I currently have planned are a question specifically about the state of the WSGI protocol (it works, but it an error prone way), as well as one on what I'd like to see as the next steps in encouraging Python 3 adoption now that we're within 18 months of the planned date for 2.7 to enter security fix only mode (which involve encouraging community workshops to switch to teaching Python 3.4 initially, with Python 2.7 as an optional follow up, helping Ubuntu & Fedora with their transitions to Py3 by default, bringing 3.5 closer to parity with Python 2 for wire protocol development, and, on the Red Hat/Fedora side, helping to encourage the adoption of software collections as a mechanism for decoupling the runtime for Python applications from the system Python on RHEL 6 and its derivatives. I thought I mentioned it on this list last year when I first wrote it, but some messages I've seen recently suggest many folks haven't seen it before. Cheers, Nick. Is it on the back of a fag packet or is there a link somewhere? :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] General Q&A regarding Python 3, adoption etc.
On Mon, Jan 6, 2014, at 03:16 PM, Nick Coghlan wrote: > For anyone that isn't already aware, I wrote a Q & A about Python 3 last > year (in response to an article about how we should have fixed the GIL > instead of Unicode), and I've updated it extensively over the past > several > days due to Alex's misunderstanding of the objectives for Python 3.4 as > well as Armin's latest piece on the increased difficulties in writing > wire > protocol handling code. I'd like to thank you for taking on the task of Python 3 justification. ___ 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] General Q&A regarding Python 3, adoption etc.
For anyone that isn't already aware, I wrote a Q & A about Python 3 last year (in response to an article about how we should have fixed the GIL instead of Unicode), and I've updated it extensively over the past several days due to Alex's misunderstanding of the objectives for Python 3.4 as well as Armin's latest piece on the increased difficulties in writing wire protocol handling code. The two main additions I currently have planned are a question specifically about the state of the WSGI protocol (it works, but it an error prone way), as well as one on what I'd like to see as the next steps in encouraging Python 3 adoption now that we're within 18 months of the planned date for 2.7 to enter security fix only mode (which involve encouraging community workshops to switch to teaching Python 3.4 initially, with Python 2.7 as an optional follow up, helping Ubuntu & Fedora with their transitions to Py3 by default, bringing 3.5 closer to parity with Python 2 for wire protocol development, and, on the Red Hat/Fedora side, helping to encourage the adoption of software collections as a mechanism for decoupling the runtime for Python applications from the system Python on RHEL 6 and its derivatives. I thought I mentioned it on this list last year when I first wrote it, but some messages I've seen recently suggest many folks haven't seen it before. 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
Re: [Python-Dev] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
I've just posted about PEP 460 and this discussion on the mercurial-devel mailing list. Tim Delaney ___ 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] Proposed: The Great Argument Clinic Conversion Derby
06.01.14 22:53, Erik Bray написав(ла): I ask because some built-in functions are used internally by other built-in functions. I don't know how common this is but, for example, fileio_read calls fileio_readall. So if fileio_readall is renamed to io_FileIO_readall_impl or whatever we need to also go through and fix any references to fileio_readall. Should be easy enough, but I wonder if there are any broader side-effects of this. Might it be safer for the first round to keep the existing function names? You can left fileio_readall as is and call it from io_FileIO_readall_impl and other places. ___ 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] Proposed: The Great Argument Clinic Conversion Derby
On Mon, Jan 6, 2014 at 10:17 AM, Antoine Pitrou wrote: > On Mon, 6 Jan 2014 00:25:53 +0100 > Stefan Krah wrote: >> Nick Coghlan wrote: >> > > I had that working at one point. Guido said no, keep it all in one file. >> > > I'm flexible but first you'd have to convince him. >> > >> > It's also not something we're stuck with forever - we can start with it >> > inline >> > (which has the advantage of keeping all the code in the same place), and >> > later >> > move to having the helpers in a separate file included from the >> > implementation >> > file if we decide it makes sense to do so. >> >> If we move big chunks of code around twice, I guess "hg blame" will break >> twice, too. That is another thing worth considering. > > Breaking on generated code doesn't sound very annoying, though. That depends on how stressed you are when you are trying to use hg blame to figure out where a certain breakage was introduced, when and by whom. >> I agree with Serhiy, but that is probably known at this point. :) > > I agree with Serhiy and you too. Clinic's current output makes C files > more tedious to read, and I'm not really willing to participate in the > "conversion derby" because of that. What were Guido's arguments? > > Also, see http://bugs.python.org/issue19723 I added a hopefully useful suggestion there; ISTM the situation can easily be improved by changing the wording of the magic comments. I'm not yet convinced that the generated code is better off in separate files nor why that is considered such a big deal. And how would you prevent the generated functions from becoming externally visible? As long as they are in the same file they can be static. (I'm not a fan of #include to stitch files together.) -- --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] Proposed: The Great Argument Clinic Conversion Derby
On Sun, Jan 5, 2014 at 11:21 AM, Larry Hastings wrote: > Now, properly converting a function to work with Argument Clinic does not > change its behavior. Internally, the code performing argument parsing > should be nigh-identical; it should call the same PyArg_Parse function, with > the same arguments, and the implementation should perform the same work as a > result. The only externally observable change should be that > inspect.signature() now produces a valid signature for the builtin; in all > other respects Python should be unchanged. No documentation should have to > change, no tests should need to be modified, and absolutely no code should > be broken as a result. Converting a function to use Argument Clinic should > be a blissfully low-risk procedure, and produce a pleasant, > easier-to-maintain result. Hi, If it goes forward I would be willing to help out with the derby on a few modules. I haven't followed the Argument Clinic arguments closely before now, so I don't know if this question has been addressed. I didn't see it mentioned in the docs anywhere, but will the policy be to *prefer* renaming existing functions to the names generated by clinic (the "_impl" names) or to override that to keep the existing names? I ask because some built-in functions are used internally by other built-in functions. I don't know how common this is but, for example, fileio_read calls fileio_readall. So if fileio_readall is renamed to io_FileIO_readall_impl or whatever we need to also go through and fix any references to fileio_readall. Should be easy enough, but I wonder if there are any broader side-effects of this. Might it be safer for the first round to keep the existing function names? Erik ___ 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] Proposed: The Great Argument Clinic Conversion Derby
On Mon, Jan 6, 2014 at 2:17 PM, Antoine Pitrou wrote: >> I agree with Serhiy, but that is probably known at this point. :) > > I agree with Serhiy and you too. Clinic's current output makes C files > more tedious to read, and I'm not really willing to participate in the > "conversion derby" because of that. My first thought was that this exercise falls into the realm of fixing things which aren't broken. Skip ___ 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] Proposed: The Great Argument Clinic Conversion Derby
On Mon, 6 Jan 2014 00:25:53 +0100 Stefan Krah wrote: > Nick Coghlan wrote: > > > I had that working at one point. Guido said no, keep it all in one file. > > > I'm flexible but first you'd have to convince him. > > > > It's also not something we're stuck with forever - we can start with it > > inline > > (which has the advantage of keeping all the code in the same place), and > > later > > move to having the helpers in a separate file included from the > > implementation > > file if we decide it makes sense to do so. > > If we move big chunks of code around twice, I guess "hg blame" will break > twice, too. That is another thing worth considering. Breaking on generated code doesn't sound very annoying, though. > I agree with Serhiy, but that is probably known at this point. :) I agree with Serhiy and you too. Clinic's current output makes C files more tedious to read, and I'm not really willing to participate in the "conversion derby" because of that. What were Guido's arguments? Also, see http://bugs.python.org/issue19723 Regards Antoine. ___ 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: whatsnew: XMLPullParser, plus some doc updates.
On Tue, 07 Jan 2014 01:22:21 +1000, Nick Coghlan wrote: > On 5 Jan 2014 12:54, "r.david.murray" wrote: > > > > http://hg.python.org/cpython/rev/069f88f4935f > > changeset: 88308:069f88f4935f > > user:R David Murray > > date:Sat Jan 04 23:52:50 2014 -0500 > > summary: > > whatsnew: XMLPullParser, plus some doc updates. > > > > I was confused by the text saying that read_events "iterated", since it > > actually returns an iterator (that's what a generator does) that the > > caller must then iterate. So I tidied up the language. I'm not sure > > what the sentence "Events provided in a previous call to read_events() > > will not be yielded again." is trying to convey, so I didn't try to fix > that. > > It's a mutating API - once the events have been retrieved, that's it, > they're gone from the internal state. Suggestions for wording improvements > welcome :) Well, my guess as to what it meant was roughly: "An Event will be yielded exactly once regardless of how many read_events iterators are processed." Looking at the code, though, I'm not sure that's actually true. The code does not appear to be thread-safe. Of course, it isn't intended to be used in a threaded context, but the docs don't quite make that explicit. I imagine that's the intent of the statement about "parallel" reading, but it doesn't actually say that the code is not thread safe. It reads more as if it is warning that the order of retrieval would be unpredictable. --David ___ 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] [RELEASED] Python 3.4.0b2
On Mon, Jan 6, 2014 at 9:43 AM, Guido van Rossum wrote: > Since MSIEXEC.EXE is a legit binary (not coming from our packager) and > Akamai is a legitimate company (MS most likely has an agreement with > them), at this point I would assume that there's something that > MSIEXEC.EXE wants to get from Akamai, which is unintentionally but > harmlessly triggered by the Python install. Could it be checking for > upgrades? Here's some more guesswork. Does it seem possible that msiexec is trying to verify the revocation status of the certificate used to sign the python .msi file? Per http://blogs.technet.com/b/pki/archive/2006/11/30/basic-crl-checking-with-certutil.aspx it looks like crl.microsoft.com is the host; this is hosted on akamai: crl.microsoft.com is an alias for crl.www.ms.akadns.net. crl.www.ms.akadns.net is an alias for a1363.g.akamai.net. There are various things you could try to verify this. You could test with simpler .msi files where one is signed and another is not signed (I'll leave it up to you to find such things, but ORCA is a common "test" .msi file). Or you could take a verbose log of the installation process (msiexec /l*v python.log python.msi OR http://support.microsoft.com/kb/223300), sit on the prompt for network access so you can uniquely identify the log's timestamps, and try to identify at what point of the installation the network access occurs. Once that is known, more steps can be taken to identify and resolve any actual issues. Michael ___ 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] The desired behaviour for resolve() when the path doesn't exist
Dear friends,
This is related with ticket 19717: "resolve() fails when the path
doesn't exist".
Assuming /home/cutecat exists but not /home/cutecat/aa,
what is the desired output of
Path('/home/cutecat/aa/bb/cc').resolve(strict=False)?
Should it be:
"/home/cutecat" (the existed path only),
"/home/cutecat/aa" (the first non-existed path; my current strategy), or
"/home/cutecat/aa/bb/cc" (the default behaviour of os.path.realpath)?
Vajrasky
___
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] [RELEASED] Python 3.4.0b2
On 6 January 2014 15:29, Bob Hanson wrote: > At any rate, the attempts to connect to the network seem like > undesirable behavior to this man. If pip is necessary, then some > Window users may well end up without it -- and then not know why > something later doesn't work. I have installed python 3.4b2 on Windows (7, 64-bit) and seen no network connections like this. I didn't check too closely, and I don't know that my (corporate) firewall would necessarily report this to me. But it seemed fine to me. I'll see if I can try an install on a VM with no network access at some point, and see what that does. One possibility which might be worth investigating - some Windows software can insert itself into the network stack and trigger extra net calls (I believe it's common with things like parental control software, and I once ended up with a thoroughly broken network because ZoneAlarm did something nasty to me). As no-one else seems to be having the issues you are, could it be that something else is intercepting part of the install process, unrelated to Python? It's also worth noting that the Python MSI is "just" a database of files and settings to install (plus some post-install scripts that would behave the same on all systems, and don't connect to the net AIUI). The MSI is interpreted, as you note, by the OS-supplied msiexec.exe. Is it possible that you have some sort of patched msiexec (there's lots of opportunity for OEM customisation in Windows, maybe your hardware supplier added something to get a logo/advert from their website when installs run)? I'm clutching at straws here, certainly, but it does look like it's an issue local to your setup. 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] [RELEASED] Python 3.4.0b2
Since MSIEXEC.EXE is a legit binary (not coming from our packager) and Akamai is a legitimate company (MS most likely has an agreement with them), at this point I would assume that there's something that MSIEXEC.EXE wants to get from Akamai, which is unintentionally but harmlessly triggered by the Python install. Could it be checking for upgrades? On Mon, Jan 6, 2014 at 5:29 AM, Bob Hanson wrote: > [For the record: I'm running 32bit Windows XP (Pro) SP2 and > installing "for all users."] > > TL;DR: No matter what I tried this morning re uninstalling and > reinstalling 3.4.0b2, pip or no pip, MSI still tried to connect > to the Akamai URLs. > > On Sun, 05 Jan 2014 23:06:49 -0500, R. David Murray wrote: > >> > Still wondering why, all of a sudden after years of using a >> > firewalled msiexec.exe, I get it now trying to connect out while >> > installing 3.4.0b2 from my harddrive...? >> >> The ensurepip developers will have to say for sure, but my understanding >> is that it does *not* go out to the network. On the other hand, it is >> conceivable that pip 1.5, unlike the earlier version in Beta1, is doing >> some sort of "up to date check" that it shouldn't be doing in the >> ensurepip scenario. >> >> I presume you did have the installer install pip. > > To be honest, I forgot all about pip until after I become a wee > bit alarmed by the installer going out to the interwebs -- didn't > even notice a checkbox for that option. > >> If you haven't already, You might try reinstalling and unchecking >> that option, and see if it msiexec still tries to go out to the >> network. That would confirm it is ensurepip that is the issue >> (although that does seem most likely). > > Working again on this, this morning: Uninstalled and then > reinstalled 3.4.0b2. No check box for pip, but there was that > strange "tree" of collapsed options which included a pip one and > which appeared to default to "install pip." Left pip on as was > the default. > > Curiously, although I hadn't remembered this happening yesterday, > this morning, the installer said there was already a 3.4x > installed and do I want to overwrite it. (Uninstalling 3.4.0b2 > had left behind my addition of sympy and another file or two of > my own from 3.4.0b1.) I told MSI to go ahead and overwrite. > > Sure enough, the installer tried to connect to the same two IPs > (Akamai I'm now told) with the installer left at default options. > > --- > > Next, I uninstalled 3.4.0b2 again, this time removing the entire > dir after uninstalling. Reinstalling (still default settings on > installer) this time gave me a bunch of *new* additions to > site-packages including pip, setuptools, easy_install.py -- all > of which were *not* installed into site-packages when priorly > overinstalling. > > Again, this time, msiexec.exe still attempted to connect (two > bursts -- each time, twice to each of the aforementioned URLs). > > --- > > Finally, I uninstalled 3.4.0b2, removed the dir, and reinstalled > yet again, this time selecting the "don't install pip" option in > the funky Windows "option tree" in the MSI installer. > > Yet *still* again, there were several sets of attempts by > msiexec.exe to connect to the same two Akamai URLs -- but, no pip > or other cruft in site-packages nor any pip-things in Scripts > after the install finished. > > So, whatever I have tried -- pip or no pip -- msiexec.exe still > attempts to connect to those Akamai URLs. > > [Hopefully, I kept accurate notes this morning and didn't typo > them above.] > > At any rate, the attempts to connect to the network seem like > undesirable behavior to this man. If pip is necessary, then some > Window users may well end up without it -- and then not know why > something later doesn't work. > > Got to go now, but will check in this evening or in the morning, > tomorrow. > > Again, many thanks to all for the help -- > > Bob Hanson > > ___ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: whatsnew: XMLPullParser, plus some doc updates.
On 5 Jan 2014 12:54, "r.david.murray" wrote:
>
> http://hg.python.org/cpython/rev/069f88f4935f
> changeset: 88308:069f88f4935f
> user:R David Murray
> date:Sat Jan 04 23:52:50 2014 -0500
> summary:
> whatsnew: XMLPullParser, plus some doc updates.
>
> I was confused by the text saying that read_events "iterated", since it
> actually returns an iterator (that's what a generator does) that the
> caller must then iterate. So I tidied up the language. I'm not sure
> what the sentence "Events provided in a previous call to read_events()
> will not be yielded again." is trying to convey, so I didn't try to fix
that.
It's a mutating API - once the events have been retrieved, that's it,
they're gone from the internal state. Suggestions for wording improvements
welcome :)
Cheers,
Nick.
>
> Also fixed a couple more news items.
>
> files:
> Doc/library/xml.etree.elementtree.rst | 23 +-
> Doc/whatsnew/3.4.rst | 7 ++-
> Lib/xml/etree/ElementTree.py | 2 +-
> Misc/NEWS | 12 +++---
> 4 files changed, 25 insertions(+), 19 deletions(-)
>
>
> diff --git a/Doc/library/xml.etree.elementtree.rst
b/Doc/library/xml.etree.elementtree.rst
> --- a/Doc/library/xml.etree.elementtree.rst
> +++ b/Doc/library/xml.etree.elementtree.rst
> @@ -105,12 +105,15 @@
> >>> root[0][1].text
> '2008'
>
> +
> +.. _elementtree-pull-parsing:
> +
> Pull API for non-blocking parsing
> ^
>
> -Most parsing functions provided by this module require to read the whole
> -document at once before returning any result. It is possible to use a
> -:class:`XMLParser` and feed data into it incrementally, but it's a push
API that
> +Most parsing functions provided by this module require the whole document
> +to be read at once before returning any result. It is possible to use an
> +:class:`XMLParser` and feed data into it incrementally, but it is a push
API that
> calls methods on a callback target, which is too low-level and
inconvenient for
> most needs. Sometimes what the user really wants is to be able to parse
XML
> incrementally, without blocking operations, while enjoying the
convenience of
> @@ -119,7 +122,7 @@
> The most powerful tool for doing this is :class:`XMLPullParser`. It
does not
> require a blocking read to obtain the XML data, and is instead fed with
data
> incrementally with :meth:`XMLPullParser.feed` calls. To get the parsed
XML
> -elements, call :meth:`XMLPullParser.read_events`. Here's an example::
> +elements, call :meth:`XMLPullParser.read_events`. Here is an example::
>
> >>> parser = ET.XMLPullParser(['start', 'end'])
> >>> parser.feed('sometext')
> @@ -1038,15 +1041,17 @@
>
> .. method:: read_events()
>
> - Iterate over the events which have been encountered in the data
fed to the
> - parser. This method yields ``(event, elem)`` pairs, where *event*
is a
> + Return an iterator over the events which have been encountered in
the
> + data fed to the
> + parser. The iterator yields ``(event, elem)`` pairs, where
*event* is a
>string representing the type of event (e.g. ``"end"``) and *elem*
is the
>encountered :class:`Element` object.
>
>Events provided in a previous call to :meth:`read_events` will not
be
> - yielded again. As events are consumed from the internal queue only
as
> - they are retrieved from the iterator, multiple readers calling
> - :meth:`read_events` in parallel will have unpredictable results.
> + yielded again. Events are consumed from the internal queue only
when
> + they are retrieved from the iterator, so multiple readers
iterating in
> + parallel over iterators obtained from :meth:`read_events` will have
> + unpredictable results.
>
> .. note::
>
> diff --git a/Doc/whatsnew/3.4.rst b/Doc/whatsnew/3.4.rst
> --- a/Doc/whatsnew/3.4.rst
> +++ b/Doc/whatsnew/3.4.rst
> @@ -1088,9 +1088,10 @@
> xml.etree
> -
>
> -Add an event-driven parser for non-blocking applications,
> -:class:`~xml.etree.ElementTree.XMLPullParser`.
> -(Contributed by Antoine Pitrou in :issue:`17741`.)
> +A new parser, :class:`~xml.etree.ElementTree.XMLPullParser`, allows a
> +non-blocking applications to parse XML documents. An example can be
> +seen at :ref:`elementtree-pull-parsing`. (Contributed by Antoine
> +Pitrou in :issue:`17741`.)
>
> The :mod:`xml.etree.ElementTree` :func:`~xml.etree.ElementTree.tostring`
and
> :func:`~xml.etree.ElementTree.tostringlist` functions, and the
> diff --git a/Lib/xml/etree/ElementTree.py b/Lib/xml/etree/ElementTree.py
> --- a/Lib/xml/etree/ElementTree.py
> +++ b/Lib/xml/etree/ElementTree.py
> @@ -1251,7 +1251,7 @@
> self._close_and_return_root()
>
> def read_events(self):
> -"""Iterate over currently available (event, elem) pairs.
> +"""Return an iterator over currently available (event, elem)
pairs.
>
>
Re: [Python-Dev] [RELEASED] Python 3.4.0b2
[For the record: I'm running 32bit Windows XP (Pro) SP2 and installing "for all users."] TL;DR: No matter what I tried this morning re uninstalling and reinstalling 3.4.0b2, pip or no pip, MSI still tried to connect to the Akamai URLs. On Sun, 05 Jan 2014 23:06:49 -0500, R. David Murray wrote: > > Still wondering why, all of a sudden after years of using a > > firewalled msiexec.exe, I get it now trying to connect out while > > installing 3.4.0b2 from my harddrive...? > > The ensurepip developers will have to say for sure, but my understanding > is that it does *not* go out to the network. On the other hand, it is > conceivable that pip 1.5, unlike the earlier version in Beta1, is doing > some sort of "up to date check" that it shouldn't be doing in the > ensurepip scenario. > > I presume you did have the installer install pip. To be honest, I forgot all about pip until after I become a wee bit alarmed by the installer going out to the interwebs -- didn't even notice a checkbox for that option. > If you haven't already, You might try reinstalling and unchecking > that option, and see if it msiexec still tries to go out to the > network. That would confirm it is ensurepip that is the issue > (although that does seem most likely). Working again on this, this morning: Uninstalled and then reinstalled 3.4.0b2. No check box for pip, but there was that strange "tree" of collapsed options which included a pip one and which appeared to default to "install pip." Left pip on as was the default. Curiously, although I hadn't remembered this happening yesterday, this morning, the installer said there was already a 3.4x installed and do I want to overwrite it. (Uninstalling 3.4.0b2 had left behind my addition of sympy and another file or two of my own from 3.4.0b1.) I told MSI to go ahead and overwrite. Sure enough, the installer tried to connect to the same two IPs (Akamai I'm now told) with the installer left at default options. --- Next, I uninstalled 3.4.0b2 again, this time removing the entire dir after uninstalling. Reinstalling (still default settings on installer) this time gave me a bunch of *new* additions to site-packages including pip, setuptools, easy_install.py -- all of which were *not* installed into site-packages when priorly overinstalling. Again, this time, msiexec.exe still attempted to connect (two bursts -- each time, twice to each of the aforementioned URLs). --- Finally, I uninstalled 3.4.0b2, removed the dir, and reinstalled yet again, this time selecting the "don't install pip" option in the funky Windows "option tree" in the MSI installer. Yet *still* again, there were several sets of attempts by msiexec.exe to connect to the same two Akamai URLs -- but, no pip or other cruft in site-packages nor any pip-things in Scripts after the install finished. So, whatever I have tried -- pip or no pip -- msiexec.exe still attempts to connect to those Akamai URLs. [Hopefully, I kept accurate notes this morning and didn't typo them above.] At any rate, the attempts to connect to the network seem like undesirable behavior to this man. If pip is necessary, then some Window users may well end up without it -- and then not know why something later doesn't work. Got to go now, but will check in this evening or in the morning, tomorrow. Again, many thanks to all for the help -- Bob Hanson ___ 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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
On 6 Jan 2014 22:56, "Brett Cannon" wrote: > > > > > On Mon, Jan 6, 2014 at 9:45 AM, Nick Coghlan wrote: >> >> >> On 6 Jan 2014 22:15, "Brett Cannon" wrote: >> > >> > >> > >> > >> > On Mon, Jan 6, 2014 at 8:59 AM, Antoine Pitrou wrote: >> >> >> >> On Tue, 7 Jan 2014 00:54:17 +1100 >> >> Chris Angelico wrote: >> >> > On Tue, Jan 7, 2014 at 12:44 AM, Antoine Pitrou wrote: >> >> > > BTW, there's a subtlety here: ``%s`` currently means "insert the result >> >> > > of calling __str__", but bytes formatting should *not* call __str__. >> >> > >> >> > Since it derives from the C printf notation, it means "insert string >> >> > here". The fact that __str__ will be called is secondary to that. I >> >> > would say it's not a problem for bytes formatting to call __bytes__, >> >> > or in some other way convert to bytes without calling __str__. >> >> > >> >> > Will it be confusing to have bytes and str supporting distinctly >> >> > different format operations? Might it be better to instead create a >> >> > separate and very different method on a bytes, just to emphasize the >> >> > difference? >> >> >> >> The people who want bytes formatting, AFAICT, want something that is >> >> reasonably 2.x-compatible. That means using the same method / operator >> >> and calling conventions. >> > >> > >> > Right, but that also doesn't mean that a library from the Cheeseshop couldn't be provided which works around any Python 2/3 differences. But my suspicion is anyone requesting this feature (e.g. Mercurial) want it implemented in C for performance and so some pure Python library to help with this won't get any traction. >> >> Right, but it seems to me that a new helper module that could be made backwards compatible at least as far as 2.6 (if not further) would be more useful for that than a builtin change that won't be available until 2015. I think we have enough experience with Python 3 now to say yes, there are still some significant gaps in the support it offers for wire protocol development. > > > True, or at least we should be very clear as to how we expect people to do binary packing in Python 3 (Victor's PEP says struct doesn't work, so should that be fixed, etc.). That will help figure out where the holes are currently. > >> >> We have been hoping others would volunteer to fill that gap, but it's getting to the point where we need to start thinking about handling it ourselves by providing a hybrid Python/C helper module specifically for wire protocol programming. > > Probably. And it can work around any shortcomings we fix in Python 3.5. > >> >> An encodedstr type wouldn't implicitly interoperate with the builtins (until we finally fix the sequence operand coercion bug in CPython) but could at least handle formatting operations like this. > > > You really want that type, don't you? =) I still don't think the 2.x bytestring is inherently evil, it's just the wrong type to use as the core text type because of the problems it has with silently creating mojibake and also with multi-byte codecs and slicing. The current python-ideas thread is close to convincing me even a stripped down version isn't a good idea, though :P Cheers, Nick. > > -Brett > >> >> 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/ncoghlan%40gmail.com >> > > > ___ 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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
On Tue, 7 Jan 2014 00:45:58 +1000 Nick Coghlan wrote: > > Right, but it seems to me that a new helper module that could be made > backwards compatible at least as far as 2.6 (if not further) would be more > useful for that than a builtin change that won't be available until 2015. More useful in the short term, less useful in the long term. > An encodedstr type wouldn't implicitly interoperate with the builtins > (until we finally fix the sequence operand coercion bug in CPython) but > could at least handle formatting operations like this. That's a crude hack. Also it doesn't address the situation where you want to interpolate bytestrings without them having any textual significance. Regards Antoine. ___ 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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
On Mon, Jan 6, 2014 at 9:45 AM, Nick Coghlan wrote: > > On 6 Jan 2014 22:15, "Brett Cannon" wrote: > > > > > > > > > > On Mon, Jan 6, 2014 at 8:59 AM, Antoine Pitrou > wrote: > >> > >> On Tue, 7 Jan 2014 00:54:17 +1100 > >> Chris Angelico wrote: > >> > On Tue, Jan 7, 2014 at 12:44 AM, Antoine Pitrou > wrote: > >> > > BTW, there's a subtlety here: ``%s`` currently means "insert the > result > >> > > of calling __str__", but bytes formatting should *not* call __str__. > >> > > >> > Since it derives from the C printf notation, it means "insert string > >> > here". The fact that __str__ will be called is secondary to that. I > >> > would say it's not a problem for bytes formatting to call __bytes__, > >> > or in some other way convert to bytes without calling __str__. > >> > > >> > Will it be confusing to have bytes and str supporting distinctly > >> > different format operations? Might it be better to instead create a > >> > separate and very different method on a bytes, just to emphasize the > >> > difference? > >> > >> The people who want bytes formatting, AFAICT, want something that is > >> reasonably 2.x-compatible. That means using the same method / operator > >> and calling conventions. > > > > > > Right, but that also doesn't mean that a library from the Cheeseshop > couldn't be provided which works around any Python 2/3 differences. But my > suspicion is anyone requesting this feature (e.g. Mercurial) want it > implemented in C for performance and so some pure Python library to help > with this won't get any traction. > > Right, but it seems to me that a new helper module that could be made > backwards compatible at least as far as 2.6 (if not further) would be more > useful for that than a builtin change that won't be available until 2015. I > think we have enough experience with Python 3 now to say yes, there are > still some significant gaps in the support it offers for wire protocol > development. > True, or at least we should be very clear as to how we expect people to do binary packing in Python 3 (Victor's PEP says struct doesn't work, so should that be fixed, etc.). That will help figure out where the holes are currently. > We have been hoping others would volunteer to fill that gap, but it's > getting to the point where we need to start thinking about handling it > ourselves by providing a hybrid Python/C helper module specifically for > wire protocol programming. > Probably. And it can work around any shortcomings we fix in Python 3.5. > An encodedstr type wouldn't implicitly interoperate with the builtins > (until we finally fix the sequence operand coercion bug in CPython) but > could at least handle formatting operations like this. > You really want that type, don't you? =) -Brett > 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/ncoghlan%40gmail.com > > > > ___ 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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
On 01/06/2014 09:50 AM, Xavier Morel wrote:
> On 2014-01-06, at 14:44 , Antoine Pitrou wrote:
>>> Then,
>>> the following points must be decided to define the complete list of
>>> supported features (formatters):
>>>
>>> * Format integer to hexadecimal? ``%x`` and ``%X``
>>> * Format integer to octal? ``%o``
>>> * Format integer to binary? ``{!b}``
>>> * Alignment?
>>> * Truncating? Truncate or raise an error?
>>
>> Not desirable IMHO. bytes formatting should serve mainly for templating
>> situations (i.e. catenate and insert bytestrings into one another). We
>> cannot start giving text-like semantics to bytes objects without
>> confusing non-experts.
>
> But having at least some of struct's formatting options available on
> bytes.format or bytes % would be useful.
Perhaps, but the PEP's stated goal is to make porting between 2.x and
3.5 easier. Add struct formatting to 3.5 wouldn't help.
Eric.
___
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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
On 2014-01-06, at 14:44 , Antoine Pitrou wrote:
>> Then,
>> the following points must be decided to define the complete list of
>> supported features (formatters):
>>
>> * Format integer to hexadecimal? ``%x`` and ``%X``
>> * Format integer to octal? ``%o``
>> * Format integer to binary? ``{!b}``
>> * Alignment?
>> * Truncating? Truncate or raise an error?
>
> Not desirable IMHO. bytes formatting should serve mainly for templating
> situations (i.e. catenate and insert bytestrings into one another). We
> cannot start giving text-like semantics to bytes objects without
> confusing non-experts.
But having at least some of struct's formatting options available on
bytes.format or bytes % would be useful.
___
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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
On 6 Jan 2014 22:15, "Brett Cannon" wrote: > > > > > On Mon, Jan 6, 2014 at 8:59 AM, Antoine Pitrou wrote: >> >> On Tue, 7 Jan 2014 00:54:17 +1100 >> Chris Angelico wrote: >> > On Tue, Jan 7, 2014 at 12:44 AM, Antoine Pitrou wrote: >> > > BTW, there's a subtlety here: ``%s`` currently means "insert the result >> > > of calling __str__", but bytes formatting should *not* call __str__. >> > >> > Since it derives from the C printf notation, it means "insert string >> > here". The fact that __str__ will be called is secondary to that. I >> > would say it's not a problem for bytes formatting to call __bytes__, >> > or in some other way convert to bytes without calling __str__. >> > >> > Will it be confusing to have bytes and str supporting distinctly >> > different format operations? Might it be better to instead create a >> > separate and very different method on a bytes, just to emphasize the >> > difference? >> >> The people who want bytes formatting, AFAICT, want something that is >> reasonably 2.x-compatible. That means using the same method / operator >> and calling conventions. > > > Right, but that also doesn't mean that a library from the Cheeseshop couldn't be provided which works around any Python 2/3 differences. But my suspicion is anyone requesting this feature (e.g. Mercurial) want it implemented in C for performance and so some pure Python library to help with this won't get any traction. Right, but it seems to me that a new helper module that could be made backwards compatible at least as far as 2.6 (if not further) would be more useful for that than a builtin change that won't be available until 2015. I think we have enough experience with Python 3 now to say yes, there are still some significant gaps in the support it offers for wire protocol development. We have been hoping others would volunteer to fill that gap, but it's getting to the point where we need to start thinking about handling it ourselves by providing a hybrid Python/C helper module specifically for wire protocol programming. An encodedstr type wouldn't implicitly interoperate with the builtins (until we finally fix the sequence operand coercion bug in CPython) but could at least handle formatting operations like this. 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/ncoghlan%40gmail.com > ___ 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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
On Mon, Jan 6, 2014 at 8:44 AM, Antoine Pitrou wrote:
>
> Hi,
>
> On Mon, 6 Jan 2014 14:24:50 +0100
> Victor Stinner wrote:
> >
> > The PEP is a draft with open questions. First, I'm not sure that both
> > bytes%args and bytes.format(args) are needed. The implementation of
> > .format() is more complex, so why not only adding bytes%args?
>
> I think we must either implement both or none of them.
>
Or bytes.format() only. But I do agree that only implementing the %
operator is the wrong answer.
-Brett
>
> > Then,
> > the following points must be decided to define the complete list of
> > supported features (formatters):
> >
> > * Format integer to hexadecimal? ``%x`` and ``%X``
> > * Format integer to octal? ``%o``
> > * Format integer to binary? ``{!b}``
> > * Alignment?
> > * Truncating? Truncate or raise an error?
>
> Not desirable IMHO. bytes formatting should serve mainly for templating
> situations (i.e. catenate and insert bytestrings into one another). We
> cannot start giving text-like semantics to bytes objects without
> confusing non-experts.
>
> > * format keywords? ``b'{arg}'.format(arg=5)``
> > * ``str % dict`` ? ``b'%(arg)s' % {'arg': 5)``
>
> Yes, bytes formatting must support the same calling conventions as str
> formatting.
>
> BTW, there's a subtlety here: ``%s`` currently means "insert the result
> of calling __str__", but bytes formatting should *not* call __str__.
>
> > * Floating point number?
> > * ``%i``, ``%u`` and ``%d`` formats for integer numbers?
> > * Signed number? ``%+i`` and ``%-i``
>
> No, IMHO.
>
> Regards
>
> Antoine.
>
>
> ___
> 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/brett%40python.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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
On Mon, Jan 6, 2014 at 8:59 AM, Antoine Pitrou wrote: > On Tue, 7 Jan 2014 00:54:17 +1100 > Chris Angelico wrote: > > On Tue, Jan 7, 2014 at 12:44 AM, Antoine Pitrou > wrote: > > > BTW, there's a subtlety here: ``%s`` currently means "insert the result > > > of calling __str__", but bytes formatting should *not* call __str__. > > > > Since it derives from the C printf notation, it means "insert string > > here". The fact that __str__ will be called is secondary to that. I > > would say it's not a problem for bytes formatting to call __bytes__, > > or in some other way convert to bytes without calling __str__. > > > > Will it be confusing to have bytes and str supporting distinctly > > different format operations? Might it be better to instead create a > > separate and very different method on a bytes, just to emphasize the > > difference? > > The people who want bytes formatting, AFAICT, want something that is > reasonably 2.x-compatible. That means using the same method / operator > and calling conventions. > Right, but that also doesn't mean that a library from the Cheeseshop couldn't be provided which works around any Python 2/3 differences. But my suspicion is anyone requesting this feature (e.g. Mercurial) want it implemented in C for performance and so some pure Python library to help with this won't get any traction. ___ 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 2.7 root buildbot showing errors
On Mon, Jan 6, 2014 at 2:09 AM, Chris Angelico wrote:
> The first build my new root buildbot did showed errors in the 2.7 test
> suite, but I thought little of it as quite a few other 2.7 buildbots
> are showing red, too. But it seems they're showing different errors,
> so there might be something wrong with the setup.
>
>
> http://buildbot.python.org/all/builders/AMD64%20Debian%20root%202.7/builds/3/steps/test/logs/stdio
>
> First off, it's complaining about being unable to build _curses
> (lacking curses.h). Is that a mandatory prereq that I should install,
> or should Python be compatible with not having it?
>
Yes, curses should be considered entirely optional so the tests should
still pass (as long as the build doesn't error out then the compiler
message about not being able to build curses is not critical).
-Brett
>
> Then further down, several SSL tests attempt:
>
> s.connect_ex(("svn.python.org", 444)))
>
> and get back EAGAIN when they're expecting ECONNREFUSED. Possibly my
> firewall's delaying things somewhat and it's timing out with a signal;
> when I try manually, the connection times out.
>
> Are these failures a problem? Should they be fixed? The 3.x builds are
> all coming up green.
>
> 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/brett%40python.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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
On Tue, 7 Jan 2014 00:54:17 +1100 Chris Angelico wrote: > On Tue, Jan 7, 2014 at 12:44 AM, Antoine Pitrou wrote: > > BTW, there's a subtlety here: ``%s`` currently means "insert the result > > of calling __str__", but bytes formatting should *not* call __str__. > > Since it derives from the C printf notation, it means "insert string > here". The fact that __str__ will be called is secondary to that. I > would say it's not a problem for bytes formatting to call __bytes__, > or in some other way convert to bytes without calling __str__. > > Will it be confusing to have bytes and str supporting distinctly > different format operations? Might it be better to instead create a > separate and very different method on a bytes, just to emphasize the > difference? The people who want bytes formatting, AFAICT, want something that is reasonably 2.x-compatible. That means using the same method / operator and calling conventions. Regards Antoine. ___ 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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
On Tue, Jan 7, 2014 at 12:44 AM, Antoine Pitrou wrote: > BTW, there's a subtlety here: ``%s`` currently means "insert the result > of calling __str__", but bytes formatting should *not* call __str__. Since it derives from the C printf notation, it means "insert string here". The fact that __str__ will be called is secondary to that. I would say it's not a problem for bytes formatting to call __bytes__, or in some other way convert to bytes without calling __str__. Will it be confusing to have bytes and str supporting distinctly different format operations? Might it be better to instead create a separate and very different method on a bytes, just to emphasize the difference? 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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
Hi,
On Mon, 6 Jan 2014 14:24:50 +0100
Victor Stinner wrote:
>
> The PEP is a draft with open questions. First, I'm not sure that both
> bytes%args and bytes.format(args) are needed. The implementation of
> .format() is more complex, so why not only adding bytes%args?
I think we must either implement both or none of them.
> Then,
> the following points must be decided to define the complete list of
> supported features (formatters):
>
> * Format integer to hexadecimal? ``%x`` and ``%X``
> * Format integer to octal? ``%o``
> * Format integer to binary? ``{!b}``
> * Alignment?
> * Truncating? Truncate or raise an error?
Not desirable IMHO. bytes formatting should serve mainly for templating
situations (i.e. catenate and insert bytestrings into one another). We
cannot start giving text-like semantics to bytes objects without
confusing non-experts.
> * format keywords? ``b'{arg}'.format(arg=5)``
> * ``str % dict`` ? ``b'%(arg)s' % {'arg': 5)``
Yes, bytes formatting must support the same calling conventions as str
formatting.
BTW, there's a subtlety here: ``%s`` currently means "insert the result
of calling __str__", but bytes formatting should *not* call __str__.
> * Floating point number?
> * ``%i``, ``%u`` and ``%d`` formats for integer numbers?
> * Signed number? ``%+i`` and ``%-i``
No, IMHO.
Regards
Antoine.
___
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] RFC: PEP 460: Add bytes % args and bytes.format(args) to Python 3.5
Hi,
bytes % args and bytes.format(args) are requested by Mercurial and
Twisted projects. The issue #3982 was stuck because nobody proposed a
complete definition of the "new" features. Here is a try as a PEP.
The PEP is a draft with open questions. First, I'm not sure that both
bytes%args and bytes.format(args) are needed. The implementation of
.format() is more complex, so why not only adding bytes%args? Then,
the following points must be decided to define the complete list of
supported features (formatters):
* Format integer to hexadecimal? ``%x`` and ``%X``
* Format integer to octal? ``%o``
* Format integer to binary? ``{!b}``
* Alignment?
* Truncating? Truncate or raise an error?
* format keywords? ``b'{arg}'.format(arg=5)``
* ``str % dict`` ? ``b'%(arg)s' % {'arg': 5)``
* Floating point number?
* ``%i``, ``%u`` and ``%d`` formats for integer numbers?
* Signed number? ``%+i`` and ``%-i``
HTML version of the PEP:
http://www.python.org/dev/peps/pep-0460/
Inline copy:
PEP: 460
Title: Add bytes % args and bytes.format(args) to Python 3.5
Version: $Revision$
Last-Modified: $Date$
Author: Victor Stinner
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 6-Jan-2014
Python-Version: 3.5
Abstract
Add ``bytes % args`` operator and ``bytes.format(args)`` method to
Python 3.5.
Rationale
=
``bytes % args`` and ``bytes.format(args)`` have been removed in Python
2. This operator and this method are requested by Mercurial and Twisted
developers to ease porting their project on Python 3.
Python 3 suggests to format text first and then encode to bytes. In
some cases, it does not make sense because arguments are bytes strings.
Typical usage is a network protocol which is binary, since data are
send to and received from sockets. For example, SMTP, SIP, HTTP, IMAP,
POP, FTP are ASCII commands interspersed with binary data.
Using multiple ``bytes + bytes`` instructions is inefficient because it
requires temporary buffers and copies which are slow and waste memory.
Python 3.3 optimizes ``str2 += str2`` but not ``bytes2 += bytes1``.
``bytes % args`` and ``bytes.format(args)`` were asked since 2008, even
before the first release of Python 3.0 (see issue #3982).
``struct.pack()`` is incomplete. For example, a number cannot be
formatted as decimal and it does not support padding bytes string.
Mercurial 2.8 still supports Python 2.4.
Needed and excluded features
Needed features
* Bytes strings: bytes, bytearray and memoryview types
* Format integer numbers as decimal
* Padding with spaces and null bytes
* "%s" should use the buffer protocol, not str()
The feature set is minimal to keep the implementation as simple as
possible to limit the cost of the implementation. ``str % args`` and
``str.format(args)`` are already complex and difficult to maintain, the
code is heavily optimized.
Excluded features:
* no implicit conversion from Unicode to bytes (ex: encode to ASCII or
to Latin1)
* Locale support (``{!n}`` format for numbers). Locales are related to
text and usually to an encoding.
* ``repr()``, ``ascii()``: ``%r``, ``{!r}``, ``%a`` and ``{!a}``
formats. ``repr()`` and ``ascii()`` are used to debug, the output is
displayed a terminal or a graphical widget. They are more related to
text.
* Attribute access: ``{obj.attr}``
* Indexing: ``{dict[key]}``
* Features of struct.pack(). For example, format a number as 32 bit unsigned
integer in network endian. The ``struct.pack()`` can be used to prepare
arguments, the implementation should be kept simple.
* Features of int.to_bytes().
* Features of ctypes.
* New format protocol like a new ``__bformat__()`` method. Since the
* list of
supported types is short, there is no need to add a new protocol.
Other types must be explicitly casted.
* Alternate format for integer. For example, ``'{|#x}'.format(0x123)``
to get ``0x123``. It is more related to debug, and the prefix can be
easily be written in the format string (ex: ``0x%x``).
* Relation with format() and the __format__() protocol. bytes.format()
and str.format() are unrelated.
Unknown:
* Format integer to hexadecimal? ``%x`` and ``%X``
* Format integer to octal? ``%o``
* Format integer to binary? ``{!b}``
* Alignment?
* Truncating? Truncate or raise an error?
* format keywords? ``b'{arg}'.format(arg=5)``
* ``str % dict`` ? ``b'%(arg)s' % {'arg': 5)``
* Floating point number?
* ``%i``, ``%u`` and ``%d`` formats for integer numbers?
* Signed number? ``%+i`` and ``%-i``
bytes % args
Formatters:
* ``"%c"``: one byte
* ``"%s"``: integer or bytes strings
* ``"%20s"`` pads to 20 bytes with spaces (``b' '``)
* ``"%020s"`` pads to 20 bytes with zeros (``b'0'``)
* ``"%\020s"`` pads to 20 bytes with null bytes (``b'\0'``)
bytes.format(args)
==
Formatters:
* ``"{!c}"``: one byte
* ``"{!s}"``: integer or bytes strings
* ``"{!.20s}"`` pads to 20 bytes with spaces (``b' '``)
* ``"{!.020s}"`` pads to 2
Re: [Python-Dev] Subclasses vs. special methods
On 04.01.14 13:58, Serhiy Storchaka wrote:
Should implicit converting an instance of int, float, complex, str,
bytes, etc subclasses to call appropriate special method __int__ (or
__index__), __float__, __complex__, __str__, __bytes__, etc? Currently
explicit converting calls these methods, but implicit converting doesn't.
class I(int):
... def __int__(self): return 42
... def __index__(self): return 43
...
class F(float):
... def __float__(self): return 42.0
...
class S(str):
... def __str__(self): return '*'
...
int(I(65))
42
float(F(65))
42.0
str(S('A'))
'*'
chr(I(65))
'A'
import cmath; cmath.rect(F(65), 0)
(65+0j)
ord(S('A'))
65
Issue17576 [1] proposes to call special methods for implicit converting.
I have doubts about this.
Note that for explicit conversion this was implemented a long time ago.
See this ancient thread about str/unicode subclasses and
__str__/__unicode__:
https://mail.python.org/pipermail/python-dev/2005-January/051175.html
And this bug report:
http://bugs.python.org/issue1109424
[...]
Servus,
Walter
___
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 2.7 root buildbot showing errors
On Mon, Jan 6, 2014 at 7:58 PM, Christian Heimes wrote: > Interesting, maybe it's a general NAT issue? So far I have seen the issue on > Windows only. What kind of VM are you using? I'm using virtualbox for my > Windows VMs. It's Oracle VirtualBox v4.2.20 r90963. > Just backport the test fixes. Test fixes and new tests are not new feature > so you are always allowed to add new tests or fix existing tests. Okay. I don't have write access, myself. 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] Python 2.7 root buildbot showing errors
On 06.01.2014 09:22, Chris Angelico wrote: No, it's Debian Wheezy inside Debian Wheezy; though the outer system is a somewhat messy one (I installed Wheezy before it was stable, and compiled my own ALSA drivers and a few other things). But it could well be that same issue, as it seems to involve NAT. What's the policy on backporting patches to tests onto 2.7? Interesting, maybe it's a general NAT issue? So far I have seen the issue on Windows only. What kind of VM are you using? I'm using virtualbox for my Windows VMs. Just backport the test fixes. Test fixes and new tests are not new feature so you are always allowed to add new tests or fix existing tests. Christian ___ 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 2.7 root buildbot showing errors
On Mon, Jan 6, 2014 at 7:11 PM, Christian Heimes wrote:
> On 06.01.2014 08:09, Chris Angelico wrote:
>>
>> Then further down, several SSL tests attempt:
>>
>> s.connect_ex(("svn.python.org", 444)))
>>
>> and get back EAGAIN when they're expecting ECONNREFUSED. Possibly my
>> firewall's delaying things somewhat and it's timing out with a signal;
>> when I try manually, the connection times out.
>
> Are you running the VM on Windows? I've seen similar issues on Windows and
> Windows as host platform for VMs:
>
> http://bugs.python.org/issue19919
No, it's Debian Wheezy inside Debian Wheezy; though the outer system
is a somewhat messy one (I installed Wheezy before it was stable, and
compiled my own ALSA drivers and a few other things).
But it could well be that same issue, as it seems to involve NAT.
What's the policy on backporting patches to tests onto 2.7?
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] Python 2.7 root buildbot showing errors
On 06.01.2014 08:09, Chris Angelico wrote:
Then further down, several SSL tests attempt:
s.connect_ex(("svn.python.org", 444)))
and get back EAGAIN when they're expecting ECONNREFUSED. Possibly my
firewall's delaying things somewhat and it's timing out with a signal;
when I try manually, the connection times out.
Are you running the VM on Windows? I've seen similar issues on Windows
and Windows as host platform for VMs:
http://bugs.python.org/issue19919
Christian
___
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
