[Python-Dev] Fixing the XML batteries
Hi everyone, I think Py3.3 would be a good milestone for cleaning up the stdlib support for XML. Note upfront: you may or may not know me as the maintainer of lxml, the de-facto non-stdlib standard Python XML tool. This (lengthy) post was triggered by the following kind of conversation that I keep having with new XML users in Python (mostly on c.l.py), which hints at some serious flaw in the stdlib. User: I'm trying to do XML stuff XYZ in Python and have problem ABC. Me: What library are you using? Could you show us some code? User: My code looks like this snippet: ... Me: You are using minidom which is known to be hard to use, slow and uses lots of memory. Use the xml.etree.ElementTree package instead, or rather its C implementation cElementTree, also in the stdlib. User (coming back after a while): thanks, that was exactly what [I didn't know] I was looking for. What does this tell us? 1) MiniDOM is what new users find first. It's highly visible because there are still lots of ancient "Python and XML" web pages out there that date back from the time before Python 2.5 (or rather something like 2.2), when it was the only XML tree library in the stdlib. It's also the first hit from the top when you search for "XML" on the stdlib docs page and contains the (to some people) familiar word "DOM", which lets users stop their search and start writing code, not expecting to find a separate alternative in the same stdlib, way further down. And the description as "mini", "simple" and "lightweight" suggests to users that it's going to be easy to use and efficient. 2) MiniDOM is not what users want. It leads to complicated, unpythonic code and lots of problems. It is neither easy to use, nor efficient, nor "lightweight", "simple" or "mini", not in absolute numbers (see http://bugs.python.org/issue11379#msg148584 and following for a recent discussion). It's also badly maintained in the sense that its performance characteristics could likely be improved, but no-one is seriously interested in doing that, because it would not lead to something that actually *is* fast or memory friendly compared to any of the 'real' alternatives that are available right now. 3) ElementTree is what users should use, MiniDOM is not. ElementTree was added to the stdlib in Py2.5 on popular demand, exactly because it is very easy to use, very fast, and very memory friendly. And because users did not want to use MiniDOM any more. Today, ElementTree has a rather straight upgrade path towards lxml.etree if more XML features like validation or XSLT are needed. MiniDOM has nothing like that to offer. It's a dead end. 4) In the stdlib, cElementTree is independent of ElementTree, but totally hidden in the documentation. In conversations like the above, it's unnecessarily complex to explain to users that there is ElementTree (which is documented in the stdlib), but that what they want to use is really cElementTree, which has the same API but does not have a stdlib documentation page that I can send them to. Note that the other Python implementations simply provide cElementTree as an alias for ElementTree. That leaves CPython as the only Python implementation that really has these two separate modules. So, there are many problems here. And I think they make it unnecessarily complicated for users to process XML in Python and that the current situation helps in turning away new users from Python as a language for XML processing. Python does have impressively great tools for working with XML. It's just that the stdlib and its documentation do not reflect or even appreciate that. What should change? a) The stdlib documentation should help users to choose the right tool right from the start. Instead of using the totally misleading wording that it uses now, it should be honest about the performance characteristics of MiniDOM and should actively suggest that those who don't know what to choose (or even *that* they can choose) should not use MiniDOM in the first place. I created a ticket (issue11379) for a minor step in this direction, but given the responses, I'm rather convinced that there's a lot more that can be done and should be done, and that it should be done now, right for the next release. b) cElementTree should finally loose it's "special" status as a separate library and disappear as an accelerator module behind ElementTree. This has been suggested a couple of times already, and AFAIR, there was some opposition because 1) ET was maintained outside of the stdlib and 2) the APIs of both were not identical. However, getting ET 1.3 into Py2.7 and 3.2 was a U-turn. Today, ET is *only* being maintained in the stdlib by Florent Xicluna (who is doing a good job with it), and ET 1.3 has basically made the APIs of both implementations compatible again. So, 3.3 would be the right milestone for fixing the "two libs for one" quirk. Given that this is the third time during the last c
Re: [Python-Dev] readd u'' literal support in 3.3?
Given that WSGI 1.0.1 is defined in terms of native strings and restoring u'' support allows that to be expressed clearly in a shared codebase, I at least understand the point of the suggestion now. I'm not quite convinced restoring u'' is the right answer as yet, but a solid use case is always a nice place to start :) -- Nick Coghlan (via Gmail on Android, so likely to be more terse than usual) On Dec 9, 2011 5:38 PM, "Chris McDonough" wrote: > On Fri, 2011-12-09 at 16:36 +1000, Nick Coghlan wrote: > > On Fri, Dec 9, 2011 at 4:01 PM, Chris McDonough > wrote: > > > On the consumer side, folks who want to run 2.6/2.7/3.3-only codebases > > > will have the wherewithal to compile their own Python 3 (or use a PPA > or > > > equivalent) until the distros catch up. > > > > > > So I'm not sure why 3.2 not having support for u'' should be a real > > > blocker for the change. > > > > If this argument was valid, people wouldn't be so worried about > > maintaining 2.5 compatibility in their libraries. Consider if I tried > > to make this argument to justify everyone dropping 2.5 and earlier > > support today: > > > > """On the consumer side, folks who want to run 2.6+ codebases on older > > Linux distros have the wherewithal to compile their own more recent > > Python 2 (or use a PPA or > > equivalent) until they can move to a more recent version of their > distro.""" > > Fair point. > > That said, personally, I have given up entirely on Python 2.4 and 2.5 > support for newer versions of my OSS libraries. I continue to backport > fixes and (some) features to older library versions so folks can run > those on systems that require older Pythons. I gave up 2.5 support > fairly recently across everything new, and I gave up support for 2.4 a > year ago or more in new releases with the same intent. > > In reality, there is only one major platform that requires 2.4: RHEL 5 > and folks who use it will just need to also use old versions of popular > libraries; trying to support it for all future feature work until it's > EOLed is not sane unless someone pays for it. Python 2.5 has slightly > more compelling platforms (GAE and Jython), but GAE is moving to Python > 2.7 and Jython is a bit moribund these days and is not really popular > enough that a critical mass of folks will clamor for new-and-shiny > releases that run on it. > > The upshot is that most newly created code only needs to run on Python > 2.6 and *some* version of Python 3. And being able to eventually write > that code in a nonsucky subset of Python 2/3 is important to me, because > I'm going to be developing software in that subset for many years (way > past the timeframe we're talking about in which Python 3.2 will rule the > roost). > > > It's simply not true in the general case - people don't maintain 2.4+ > > compatibility for fun, they do it because RHEL5 (and CentOS 5, etc) > > are still reasonably common and ship with 2.4 as the system Python. As > > soon as you switch away from the system provided Python, you're > > switching away from the vendors entire pre-packaged Python *stack*, > > not just the interpreter itself. You then have to install (and > > generally build) *everything* for yourself. While that is certainly > > possible these days (and a lot simpler than it used to be), it's still > > not trivial [1]. > > > > Since 3.2 is already quite usable for applications that aren't > > fighting with the "native strings" problem (which seems to be the > > common thread running through the complaints I've heard from web > > framework authors), and with it being included in at least the next > > Ubuntu LTS, current versions of Fedora, Arch, etc, it's going to be > > around for a long time. Ignoring 3.1 is a reasonable option. Ignoring > > 3.2 entirely is unlikely to be viable for anyone that is interested in > > supporting 3.x within the next couple of years - the 3.3 release is at > > least 9 months away, and it's also going to take a while for it to > > make its way into distros after the final release gets published on > > python.org. > > > > Hence my suggestion: perhaps the problem is the fact that PEP 3.3/WSGI > > 1.0.1 introduced the "native string" concept as a minimalist hack to > > try to get a usable gateway interface in Python 3, and that just > > doesn't work in practice when attempting to straddle 2.x and 3.x > > (because the values WSGI is dealing with aren't really text, they're > > bytes, only *some* of which represent text). Perhaps a PEP 444 based > > model would be less painful and more coherent in the long run? > > Possibly. I was the original author of PEP 444 with help from Armin. > (although it has since been taken up by Alice and I do not support the > updates it has received since then). > > A bytes-oriented WSGI-like protocol was always the saner option. The > native string idea optimized in exactly the wrong place, which was to > make it easy to write WSGI middleware, where you're required to do lots > of textlike man
Re: [Python-Dev] readd u'' literal support in 3.3?
> Sorry, I don't understand this. What does it mean to be "str in both > versions"? And why would you want that? One use case (and the only one I'm aware of) is to pass keyword parameters. Python 2 insists that they are str (and doesn't accept unicode), Python 3 insists that they are str (and doesn't accept bytes). This is fairly uncommon as a problem, though, and is also solved in Python 2.6, which does accept Unicode strings as keyword parameter names. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
> They fail to hear the "again" in that sentence. I've clearly already > thought about the distinction between bytes and text at least once: > that's *why* I'm using a u'' literal there. I shouldn't have to think > about it again to service syntax constraints. Code that is more > explicit than strictly necessary should not be needlessly punished. But you don't have to think about this *again*, in none of the proposed alternatives (whether you use a u() function, whether you use the future import, or whether you use 2to3). They differ only (slightly) in how you spell Unicode literals, but all provide for explicit spelling of Unicode literals when applied. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
> Or, alternatively, you use 'six' (or a similar compatibility module)
> and ensure unicode at runtime, using native or binary strings
> otherwise:
>
> --
> from six import u
> foo = u("this is a Unicode string in both Python 2.x and 3.x")
> bar = "this is an 8-bit string in Python 2.x and a Unicode string in 3.x"
> baz = b"this is an 8-bit string in Python 2.x and a bytes object in 3.x"
> --
An alternative here is to use a function for bar, not foo:
from __future__ import unicode_literals
from six.next import native_str
foo = "this is a Unicode string in both Python 2.x and 3.x"
bar = native_str("this is an 7-bit string in Python 2.x"
" and a Unicode string in 3.x")
baz = b"this is an 8-bit string in Python 2.x and a bytes object in 3.x"
Which of them is "better" depends on which of the two string types are
more common.
Regards,
Martin
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
> a) The stdlib documentation should help users to choose the right tool > right from the start. Instead of using the totally misleading wording > that it uses now, it should be honest about the performance > characteristics of MiniDOM and should actively suggest that those who > don't know what to choose (or even *that* they can choose) should not > use MiniDOM in the first place. I disagree. The right approach is not to document performance problems, but to fix them. > b) cElementTree should finally loose it's "special" status as a separate > library and disappear as an accelerator module behind ElementTree. This > has been suggested a couple of times already, and AFAIR, there was some > opposition because 1) ET was maintained outside of the stdlib and 2) the > APIs of both were not identical. However, getting ET 1.3 into Py2.7 and > 3.2 was a U-turn. Unfortunately (?), there is a near-contract-like agreement with Fredrik Lundh that any significant changes to ElementTree in the standard library have to be agreed by him. So whatever change you plan: make sure Fredrik gives his explicit support. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Document PyUnicode_Copy() and PyUnicode_EncodeCodePage()
Am 09.12.2011 01:35, schrieb Antoine Pitrou: > On Fri, 09 Dec 2011 00:16:02 +0100 > victor.stinner wrote: >> >> +.. c:function:: PyObject* PyUnicode_Copy(PyObject *unicode) >> + >> + Get a new copy of a Unicode object. >> + >> + .. versionadded:: 3.3 > > I'm not sure I understand. Why would you make a copy of an immutable > object? It can convert a unicode subtype object into a an exact unicode object. I'd rename it to _PyUnicode_AsExactUnicode, and undocument it. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
"Martin v. Löwis", 09.12.2011 09:41: a) The stdlib documentation should help users to choose the right tool right from the start. Instead of using the totally misleading wording that it uses now, it should be honest about the performance characteristics of MiniDOM and should actively suggest that those who don't know what to choose (or even *that* they can choose) should not use MiniDOM in the first place. I disagree. The right approach is not to document performance problems, but to fix them. Here's the relevant part of my mail that you stripped: It's also badly maintained in the sense that its performance characteristics could likely be improved, but no-one is seriously interested in doing that, because it would not lead to something that actually *is* fast or memory friendly compared to any of the 'real' alternatives that are available right now. I can't recall anyone working on any substantial improvements during the last six years or so, and the reason for that seems obvious to me. b) cElementTree should finally loose it's "special" status as a separate library and disappear as an accelerator module behind ElementTree. This has been suggested a couple of times already, and AFAIR, there was some opposition because 1) ET was maintained outside of the stdlib and 2) the APIs of both were not identical. However, getting ET 1.3 into Py2.7 and 3.2 was a U-turn. Unfortunately (?), there is a near-contract-like agreement with Fredrik Lundh that any significant changes to ElementTree in the standard library have to be agreed by him. So whatever change you plan: make sure Fredrik gives his explicit support. Ok, I'll try to contact him. Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
On Fri, 9 Dec 2011 15:30:36 +1000
Nick Coghlan wrote:
>
> Or, alternatively, you use 'six' (or a similar compatibility module)
> and ensure unicode at runtime, using native or binary strings
> otherwise:
>
> --
> from six import u
> foo = u("this is a Unicode string in both Python 2.x and 3.x")
> bar = "this is an 8-bit string in Python 2.x and a Unicode string in 3.x"
> baz = b"this is an 8-bit string in Python 2.x and a bytes object in 3.x"
> --
>
> If you want to target 3.2, you *have* to use one of those mechanisms -
> any potential restoration of u'' syntax support won't help you (and
> even after 3.3 gets released in the latter half of next year, it's
> still going to be a fair while before it makes it's way into the
> various distros, especially the ones that include long term support
> from major vendors).
>
> So, instead of attempting to paper over the problem by reintroducing
> u'', perhaps the discussion we should be having is whether or not PEP
> 's superficially appealing concept of defining an API in terms of
> "native strings" is a loser in practice, and we should instead be
> looking more closely at PEP 444
It's not only PEP . Many network protocol implementations will
show the same characteristics (an FTP implementation accepting str in
2.x will also want to accept str in 3.x). But using six is a reasonable
suggestion for those who want to share a single codebase accross 2.x
and 3.x.
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
On 2011-12-09, at 09:41 , Martin v. Löwis wrote: >> a) The stdlib documentation should help users to choose the right tool >> right from the start. Instead of using the totally misleading wording >> that it uses now, it should be honest about the performance >> characteristics of MiniDOM and should actively suggest that those who >> don't know what to choose (or even *that* they can choose) should not >> use MiniDOM in the first place. > > I disagree. The right approach is not to document performance problems, > but to fix them. Even if performance problems "should not be documented", I think Stefan's point that users should be steered away from minidom and towards ET and cET is completely valid and worthy of support: the *only* advantage minidom has over ET is that it uses an interface familiar to Java users[0] (they are about the only people using actual W3C DOM, while the DOM exists in javascript I'd say most code out there actively tries to not touch it with anything less than a 10-foot library pole like jQuery). That interface is also, of course, absolutely dreadful. Minidom is inferior in interface flow and pythonicity, in terseness, in speed, in memory consumption (even more so using cElementTree, and that's not something which can be fixed unless minidom gets a C accelerator), etc… Even after fixing minidom (if anybody has the time and drive to commit to it), ET/cET should be preferred over it. And that's not even considering the ease of switching to lxml (if only for validators), which Stefan outlined. [0] not 100% true now that I think about it: handling mixed content is simpler in minidom as there is no .text/.tail duality and text nodes are nodes like every other, but I really can't think of an other reason to prefer minidom ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
On Fri, Dec 9, 2011 at 6:41 PM, "Martin v. Löwis" wrote: >> a) The stdlib documentation should help users to choose the right tool >> right from the start. Instead of using the totally misleading wording >> that it uses now, it should be honest about the performance >> characteristics of MiniDOM and should actively suggest that those who >> don't know what to choose (or even *that* they can choose) should not >> use MiniDOM in the first place. > > I disagree. The right approach is not to document performance problems, > but to fix them. When we offer a better way to do something that new users are want to do, we generally redirect them to the more recent alternative. I believe the redirection from the getopt module to the argparse module strikes the right tone for that kind of thing: http://docs.python.org/library/getopt For the various XML libraries, a message along the lines of "Note: The module is a . If all you are trying to do is read and write XML files, consider using the xml.etree.ElementTree module instead". I'd also be +1 on adjusting the order of the XML pages in the main index such that xml.etree.ElementTree appeared before xml.parser.expat and all the others slid down one entry. These are simple changes that don't harm current users of the modules in the least, while being up front and very helpful for beginners. Again, I think argparse vs getopt is a good comparison: argparse appears first in the main index, and there's a redirection from getopt to argparse that says "if you don't have a specific reason to be using getopt, you probably want argparse instead". -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Document PyUnicode_Copy() and PyUnicode_EncodeCodePage()
On Fri, Dec 9, 2011 at 6:44 PM, "Martin v. Löwis" wrote: > Am 09.12.2011 01:35, schrieb Antoine Pitrou: >> On Fri, 09 Dec 2011 00:16:02 +0100 >> victor.stinner wrote: >>> >>> +.. c:function:: PyObject* PyUnicode_Copy(PyObject *unicode) >>> + >>> + Get a new copy of a Unicode object. >>> + >>> + .. versionadded:: 3.3 >> >> I'm not sure I understand. Why would you make a copy of an immutable >> object? > > It can convert a unicode subtype object into a an exact unicode > object. > > I'd rename it to _PyUnicode_AsExactUnicode, and undocument it. Isn't it basically just exposing a C level version of the unicode() builtin's behaviour? While I agree the name could be better (and PyUnicode_AsExactUnicode would certainly work), why make it private? Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
Mostly uninformed +1 to Stefan's suggestions from me. Regards Antoine. On Fri, 09 Dec 2011 09:02:35 +0100 Stefan Behnel wrote: > Hi everyone, > > I think Py3.3 would be a good milestone for cleaning up the stdlib support > for XML. Note upfront: you may or may not know me as the maintainer of > lxml, the de-facto non-stdlib standard Python XML tool. This (lengthy) post > was triggered by the following kind of conversation that I keep having with > new XML users in Python (mostly on c.l.py), which hints at some serious > flaw in the stdlib. [etc.] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
On 12/8/2011 8:39 PM, Vinay Sajip wrote: It's not the speed of 2to3 per se; this seems very reasonable for a > tool of its type > It's the overall process, which currently involves running 2to3 > on an entire codebase (for example, using setup.py with flags to run 2to3 during setup). Oh. That explains the 'slow' complaint. However, 2to3 tools could be developed which are based on 2to3/lib2to3 and are *incremental* in nature; then as you edit and save a file, its processed version could be available very shortly afterwards (since we only need to translate the file that was saved) I had assumed that people were aleady running 2to3 on a per edited file basis already. On a multi-core machine, I would think it possible to run 2to3 and then a test on the result in a separate process while tests are running on the 2.x version. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
On Fri, Dec 9, 2011 at 8:03 PM, Terry Reedy wrote: > On 12/8/2011 8:39 PM, Vinay Sajip wrote: >> on an >> >> entire codebase (for example, using setup.py with flags to run 2to3 >> during setup). > > > Oh. That explains the 'slow' complaint. As Chris pointed out though, the real problem with the "repeatedly run 2to3" workflow is that it can make interpreting tracebacks from the field *really* hard. That's where Antoine's suggested approach may be better - use 2to3 to do the initial mechanical update in a new branch, then subsequently use a process similar to what we do ourselves for the standard library (i.e. update the 2.x and 3.x versions in parallel, perhaps using 2to3 on a few files if they have changed substantially in a particular patch). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
On Fri, 9 Dec 2011 15:41:40 +1000 Nick Coghlan wrote: > On Fri, Dec 9, 2011 at 3:33 PM, Chris McDonough wrote: > > Even if it weren't slow, I still wouldn't use it to automatically > > convert code at install time; a single codebase is easier to reason > > about, and easier to support. Users send me tracebacks all the time; > > having them match the source is a wonderful thing. > > Yeah, if single source doesn't work, then I think Antoine's suggested > way (i.e. convert once, then maintain two distinct branches and > builds, the way python-dev did for years with the standard library) is > a more sane option. My suggestion is actually to convert each time you pull changes from the 2.x sources. You have three branches: - the default 2.x branch - a branch containing changesets which are pristine 2to3 runs over the 2.x codebase - a branch containing the modified 3.x code The 2to3 branch can be updated through an automatic script. Each changeset should be a child of both the previous 2to3 changeset, and the 2.x changeset which 2to3 has been run on (in other words, each changeset - except the first one - is a merge). Then the changes from the 2to3 branch are simply merged to the 3.x branch. This is the only manual step, in that you have to fix potential conflicts and regressions. (I suppose the strategy can be reversed, i.e. maintain code primarily in the 3.x branch and use 3to2 to backport them to the 2.x codebase) Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
On Fri, Dec 9, 2011 at 03:53, Guido van Rossum wrote: > Are you saying that with that future import, b"..." is still a Unicode > literal? If I said that, this is not what I was trying to say. :-) //Lennart ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
Nick Coghlan writes: > So, instead of attempting to paper over the problem by reintroducing > u'', perhaps the discussion we should be having is whether or not PEP > 's superficially appealing concept of defining an API in terms of > "native strings" is a loser in practice, +1 to that discussion. str is a different type in the two implementations, binary sludge with essentially undefined semantics in Python 2 and highly standardized text in Python 3. I don't understand how this can be expected to work well, and especially not in a code base that is trying to be portable across Python 2 and 3. I sympathize with Chris's complaint that he has to think about it "again", but in fact, it seems to me that may not be entirely true. AFAICS, having the WSGI APIs mask the difference between str and bytes (or unicode and str, depending on where you're working) requires that you think about it every time you pass something to a WSGI API. I could be wrong, of course (I don't do WSGI stuff, which is why I'm really surprised to hear this, and so I don't know the rationale for the WSGI API decision), but this description of the API just triggers all my alarms. I am somewhat sympathetic to the request for reintroduction of u'' (in my personal use it would just be cruft, so I'm -0.1 on that ground), but I can't see how the WSGI API is an argument for it. Making that case requires showing that the "native string" API makes pragmatic sense, and then that u'' can help. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
On Fri, Dec 9, 2011 at 04:34, Barry Warsaw wrote: > Sorry, I don't understand this. What does it mean to be "str in both > versions"? And why would you want that? It means that it's a str, that is a string of bytes, in Python 2, and a str, that is a string of Unicode characters, in Python 3. There are cases where you want this, for example not all libraries will accept both str and Unicode under Python 2. > As for "Unicode in Python 2 and str in Python 3", unadorned strings with the > future import in Python >= 2.6 does that just fine. Yes, but the future import will change this for *all* strings, making it impossible to have a string that is a "str" in both Python 2 and Python 3. For that reason, the future import is not enough as a solution (and I suspect, one major reason why I haven't actually seen any one using it). For most cases, using something like six's b() and u() has turned out to be a better solution. It's uglier than having u'' support in Python 3, but has the benefit that b() works also in Python 2.5. > The > problem comes when you aren't or can't be sure, i.e. you have objects that are > sometimes one and sometimes the other. Such as email headers. In that case, > you're kind of screwed. Python 2's str type let you cheat, but not without > consequences. Those consequences are spelled "UnicodeErrors" and I'll be glad > to be rid of them. Me too. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
Chris McDonough writes: > Given an effective choice between enabling six lines of code in Python > 3.3 to support u'' and months of political wrangling and code rewriting, > I'll choose the former any day. Sure, but the real question is whether that *is* the effective choice. Maybe the effective choice is between enabling six lines of code in Python 3.3 to support u'' and not doing so, with both options eventually entailing months of political wrangling and code rewriting because it doesn't help with the underlying problems. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Unicode re support in Python 3
Hey python-devers, As I'm sure many of you are aware, Armin Ronacher posted a blog entry explaining the reasons he dislikes Python 3 in its current form. Whilst I don't agree with all of his complaints, he makes a fair point about the re module Unicode support. It seems that the specific issue he has could be fixed by accepting the re module improvement / overhaul implemented by mrab: http://bugs.python.org/issue2636 As it comes with an active maintainer, and is a big step forward for Python regex support, I'd like to see it in Python 3.3. Reading through the issue it's not clear to me what needs to be done for it to be accepted (or rejected), beyond a general "it's a big change". All the best, Michael Foord -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
Slightly OT: The slowness of running 2to3 during install time can be fixed by not doing so, but instead running it when the distribution is created, including both Python 2 and Python 3 code in the distribution. http://python3porting.com/2to3.html#distribution-section There are no tools that support this at the moment though. I guess it would be cool if Distribute supported making these kinds of distributions... //Lennart ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Unicode re support in Python 3
On Fri, 9 Dec 2011 14:42:43 + Michael Foord wrote: > > Whilst I don't agree with all of his complaints, he makes a fair point about > the re module Unicode support. It seems that the specific issue he has could > be fixed by accepting the re module improvement / overhaul implemented by > mrab: > > http://bugs.python.org/issue2636 > > As it comes with an active maintainer, and is a big step forward for Python > regex support, I'd like to see it in Python 3.3. Reading through the issue > it's not clear to me what needs to be done for it to be accepted (or > rejected), beyond a general "it's a big change". Reviewing. Do you volunteer? Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
On Fri, Dec 9, 2011 at 09:02, Stefan Behnel wrote: > a) The stdlib documentation should help users to choose the right tool right > from the start. > b) cElementTree should finally loose it's "special" status as a separate > library and disappear as an accelerator module behind ElementTree. An at least somewhat informed +1 from me. The ElementTree API is a very good way to deal with XML from Python, and it deserves to be promoted over the included alternatives. Let's deprecate the NiCad batteries and try to guide users toward the Li-Ion ones. Cheers, Dirkjan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
On Dec 09, 2011, at 03:18 PM, Lennart Regebro wrote: >On Fri, Dec 9, 2011 at 04:34, Barry Warsaw wrote: >> Sorry, I don't understand this. What does it mean to be "str in both >> versions"? And why would you want that? > >It means that it's a str, that is a string of bytes, in Python 2, and >a str, that is a string of Unicode characters, in Python 3. There are >cases where you want this, for example not all libraries will accept >both str and Unicode under Python 2. As Chris points out, this seems to be a use case tied to WSGI and PEP . I guess it's an unfortunate choice for so recent a PEP, but maybe there was no way to do better. Still, it seems the "native string" discussion is an indication that the PEP is introducing a binary vs. text ambiguity when switching Python versions. My previous "you're screwed" comment comes back to mind. ;) >> As for "Unicode in Python 2 and str in Python 3", unadorned strings with the >> future import in Python >= 2.6 does that just fine. > >Yes, but the future import will change this for *all* strings, making >it impossible to have a string that is a "str" in both Python 2 and >Python 3. For that reason, the future import is not enough as a >solution (and I suspect, one major reason why I haven't actually seen >any one using it). It can certainly be useful in many contexts outside of WSGI. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
On Dec 09, 2011, at 09:20 AM, Martin v. Löwis wrote: >One use case (and the only one I'm aware of) is to pass keyword >parameters. Python 2 insists that they are str (and doesn't accept >unicode), Python 3 insists that they are str (and doesn't accept bytes). > >This is fairly uncommon as a problem, though, and is also solved in >Python 2.6, which does accept Unicode strings as keyword parameter >names. Oh, I remember this one, because I think I reported and fixed it. But I take it as a given that Python 2.6 is the minimal (sane) version to target for one-codebase cross-Python code. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
On Dec 09, 2011, at 06:09 PM, Nick Coghlan wrote: >Given that WSGI 1.0.1 is defined in terms of native strings and restoring >u'' support allows that to be expressed clearly in a shared codebase, I at >least understand the point of the suggestion now. I'm not quite convinced >restoring u'' is the right answer as yet, but a solid use case is always a >nice place to start :) Maybe a more interesting approach would be to expand on the `six` idea and bring some of those concepts into the stdlib for 3.3. You could implement the u() function somewhat more efficiently in an extension module, and make that available for older Pythons via the Cheeseshop. I now also have a few more Python and C level compatibility hacks that could make it into such a module. -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
On 9 Dec 2011, at 15:13, Barry Warsaw wrote: > On Dec 09, 2011, at 09:20 AM, Martin v. Löwis wrote: > >> One use case (and the only one I'm aware of) is to pass keyword >> parameters. Python 2 insists that they are str (and doesn't accept >> unicode), Python 3 insists that they are str (and doesn't accept bytes). >> >> This is fairly uncommon as a problem, though, and is also solved in >> Python 2.6, which does accept Unicode strings as keyword parameter >> names. > > Oh, I remember this one, because I think I reported and fixed it. But I take > it as a given that Python 2.6 is the minimal (sane) version to target for > one-codebase cross-Python code. > In mock (at least 5000 lines of code including tests) I target 2.4 -> 3.2+. Admittedly mock does little I/O but does some fairly crazy introspection (and even found bugs in Python 3 because of it). The exception handling is the worst - no compatible syntax between 2.4-5 and Python 3. So you have to use sys.exc_info. Other than that it isn't too hard / bad. All the best, Michael > -Barry > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Document PyUnicode_Copy() and PyUnicode_EncodeCodePage()
On Dec 09, 2011, at 07:12 PM, Nick Coghlan wrote: >Isn't it basically just exposing a C level version of the unicode() >builtin's behaviour? While I agree the name could be better (and >PyUnicode_AsExactUnicode would certainly work), why make it private? Don't we already have that in PyObject_Str(), or in Python 2, PyObject_Unicode()? -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
On 12/09/2011 08:35 AM, Michael Foord wrote: > On 9 Dec 2011, at 15:13, Barry Warsaw wrote: >> Oh, I remember this one, because I think I reported and fixed it. >> But I take it as a given that Python 2.6 is the minimal (sane) >> version to target for one-codebase cross-Python code. >> > > In mock (at least 5000 lines of code including tests) I target 2.4 -> > 3.2+. Admittedly mock does little I/O but does some fairly crazy > introspection (and even found bugs in Python 3 because of it). pip and virtualenv also both support 2.4 - 3.2+ from a single codebase (pip is ~7300 lines of code including tests, virtualenv ~1600). I consider them a bit of a special case; since they are both early-stage bootstrapping tools, the inconvenience level for users of a 2to3 step or having to keep separate versions around would be higher than for an ordinary library. But I will say that the workarounds necessary to support 2.4 - 3.2 have not really been problematic enough to tempt me towards a more complex workflow, and I would probably take the single-codebase approach with another port, even if I needed to support pre-2.6. The sys.exc_info() business is ugly indeed, but (IMHO) not bad enough to warrant adding 2to3 hassles into the maintenance workflow. Carl ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
On Thu, 08 Dec 2011 13:27:20 +0100, Barry Warsaw wrote: On Dec 08, 2011, at 11:01 AM, Vinay Sajip wrote: Well, if 3.2 remains in use for a longish time, then it is relevant, in the broader context, isn't it? We know how conservative Linux distributions can be with their Python releases - although most are still releasing 2.x as their system Python, this could change at some point in the future. Even if it doesn't, there might be a fair user base of people stuck with 3.2 for any number of reasons, and to support them, the change you propose won't help, because some variant of a package will still have to use u() and b(), just for 3.2 support. Case in point: Ubuntu 12.04 is a long term support release, meaning 5 years of official support on both the desktop and server. It will ship with Python 2.7 and 3.2 only. From a Plone perspective, Python 3 support is something that I don't see becoming important for maybe 5 years, so support for 3.2 is simply not an issue for us. Before Plone can consider a move to Python 3 we first need support in the libraries we depend on. For those libraries under active development it seems that compatibility with both 2.x and 3.x is the best way to go. Adding support for u'' to Python 3.x certainly looks like it would cut down the amount of work required for libraries like the Zope Toolkit which already use unicode extensively. Laurence ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
Hi, When running 2to3 from a setup.py script, does it run on the whole codebase or only files that are found newer by the make-like timestamp-based dependency system? If it’s the former, as some messages seem to show (sorry no time to test right now), ISTM we can fix distutils to do the latter (unless there are bugs due to import rewriting to use explicit relative imports when there are extension modules—blergh). Regards ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/09/2011 07:45 AM, Lennart Regebro wrote: > The slowness of running 2to3 during install time can be fixed by not > doing so, but instead running it when the distribution is created, > including both Python 2 and Python 3 code in the distribution. > > http://python3porting.com/2to3.html#distribution-section > > There are no tools that support this at the moment though. I guess it > would be cool if Distribute supported making these kinds of > distributions... Doesn't just this move the problem to testing? Presumably one wants to test that changes to the code don't break under Python 3, and ideally at every change, not only at release time. Carl -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7iNfYACgkQ8W4rlRKtE2dsqACffHkX7fVtCnmu8E4rdbfNdAfS 0fIAoLKzkmV3woLjXQP2sb8FcnlSgrux =7pRs -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] 2to3 and timestamps
On Fri, 09 Dec 2011 17:38:56 +0100 Éric Araujo wrote: > Hi, > > When running 2to3 from a setup.py script, does it run on the whole > codebase or only files that are found newer by the make-like > timestamp-based dependency system? If it’s the former, as some messages > seem to show (sorry no time to test right now), ISTM we can fix > distutils to do the latter (unless there are bugs due to import > rewriting to use explicit relative imports when there are extension > modules—blergh). It would be better to teach 2to3 to do it by itself. Not everybody runs 2to3 through a setup.py script. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
+1 On Sat, Dec 10, 2011 at 2:09 AM, Dirkjan Ochtman wrote: > On Fri, Dec 9, 2011 at 09:02, Stefan Behnel wrote: >> a) The stdlib documentation should help users to choose the right tool right >> from the start. >> b) cElementTree should finally loose it's "special" status as a separate >> library and disappear as an accelerator module behind ElementTree. > > An at least somewhat informed +1 from me. The ElementTree API is a > very good way to deal with XML from Python, and it deserves to be > promoted over the included alternatives. > > Let's deprecate the NiCad batteries and try to guide users toward the > Li-Ion ones. > > Cheers, > > Dirkjan > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com -- ಠ_ಠ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2011-12-02 - 2011-12-09) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open3169 (+21) closed 22180 (+26) total 25349 (+47) Open issues with patches: 1351 Issues opened (39) == #5905: strptime fails in non-UTF locale http://bugs.python.org/issue5905 reopened by haypo #12555: PEP 3151 implementation http://bugs.python.org/issue12555 reopened by ncoghlan #13521: Make dict.setdefault() atomic http://bugs.python.org/issue13521 opened by rhettinger #13522: Document error return values for PyFloat_* and PyComplex_* http://bugs.python.org/issue13522 opened by skrah #13525: Tutorial: Example of Source Code Encoding triggers error http://bugs.python.org/issue13525 opened by nicolasg #13528: Rework performance FAQ http://bugs.python.org/issue13528 opened by pitrou #13530: Docs for os.lseek neglect to mention what it returns http://bugs.python.org/issue13530 opened by nedbat #13532: In IDLE, sys.stdout.write and sys.stderr can write any picklea http://bugs.python.org/issue13532 opened by maniram.maniram #13533: Would like Py_Initialize to play friendly with host app http://bugs.python.org/issue13533 opened by dangermouseb #13535: Improved two's complement arithmetic support: to_signed() and http://bugs.python.org/issue13535 opened by ncoghlan #13537: Namedtuple instances can't be pickled in a daemonized process http://bugs.python.org/issue13537 opened by Popa.Claudiu #13538: Docstring of str() and/or behavior http://bugs.python.org/issue13538 opened by Guillaume.Bouchard #13539: A return is missing in TimeEncoding of calendar.py http://bugs.python.org/issue13539 opened by psam #13540: Document the Action API in argparse http://bugs.python.org/issue13540 opened by jason.coombs #13541: HTTPResponse (urllib) has no attribute read1 needed for TextIO http://bugs.python.org/issue13541 opened by maubp #13543: shlex with string ending in space gives "ValueError: No closin http://bugs.python.org/issue13543 opened by ekorn #13544: Add __qualname__ to functools.WRAPPER_ASSIGNMENTS http://bugs.python.org/issue13544 opened by ncoghlan #13545: Pydoc3.2: TypeError: unorderable types http://bugs.python.org/issue13545 opened by threewestwinds #13547: Clean Lib/_sysconfigdata.py and Modules/_testembed http://bugs.python.org/issue13547 opened by skrah #13548: Invalid 'line' tracer event on pass within else clause http://bugs.python.org/issue13548 opened by sdeibel #13549: Incorrect nested list comprehension documentation http://bugs.python.org/issue13549 opened by mattlong #13550: Rewrite logging hack of the threading module http://bugs.python.org/issue13550 opened by haypo #13551: pulldom doesn't populate DOM tree http://bugs.python.org/issue13551 opened by AchimGaedke #13552: Compilation issues of the curses module on OpenIndiana http://bugs.python.org/issue13552 opened by haypo #13553: Tkinter doesn't set proper application name http://bugs.python.org/issue13553 opened by th9 #13554: Tkinter doesn't use higher resolution app icon http://bugs.python.org/issue13554 opened by th9 #13555: cPickle MemoryError when loading large file (while pickle work http://bugs.python.org/issue13555 opened by phillies #13556: When tzinfo.utcoffset is out-of-bounds, the exception message http://bugs.python.org/issue13556 opened by exarkun #13557: exec of list comprehension fails on NameError http://bugs.python.org/issue13557 opened by sdeibel #13558: multiprocessing package incompatible with PyObjC http://bugs.python.org/issue13558 opened by mrmekon #13559: Use sendfile where possible in httplib http://bugs.python.org/issue13559 opened by benjamin.peterson #13560: Add PyUnicode_DecodeLocale and PyUnicode_DecodeLocaleAndSize http://bugs.python.org/issue13560 opened by haypo #13561: os.listdir documentation should mention surrogateescape http://bugs.python.org/issue13561 opened by michael.foord #13562: Notes about module load path http://bugs.python.org/issue13562 opened by Nam.Nguyen #13563: Make use of with statement in ftplib http://bugs.python.org/issue13563 opened by giampaolo.rodola #13564: ftplib and sendfile() http://bugs.python.org/issue13564 opened by giampaolo.rodola #13565: test_multiprocessing.test_notify_all() hangs on "AMD64 Snow Le http://bugs.python.org/issue13565 opened by haypo #13566: Array objects pickled in 3.x with protocol <=2 are unpickled i http://bugs.python.org/issue13566 opened by sbt #13567: HTTPError interface changes / breaks depending on what was pas http://bugs.python.org/issue13567 opened by Keto Most recent 15 issues with no replies (15) == #13565: test_multiprocessing.test_notify_all() hangs on "AMD64 Snow Le http://bugs.python.org/issue13565 #13564: ftplib and sendfile() http://bugs.python.org/issue13564 #13562: Notes
Re: [Python-Dev] Unicode re support in Python 3
Michael Foord wrote: > Hey python-devers, > > As I'm sure many of you are aware, Armin Ronacher posted a blog entry > explaining the reasons he dislikes Python 3 in its current form. > > Whilst I don't agree with all of his complaints, he makes a fair point > about the re module Unicode support. It seems that the specific issue > he has could be fixed by accepting the re module improvement / > overhaul implemented by mrab: > > http://bugs.python.org/issue2636 > > As it comes with an active maintainer, and is a big step forward for > Python regex support, I'd like to see it in Python 3.3. Reading > through the issue it's not clear to me what needs to be done for it to > be accepted (or rejected), beyond a general "it's a big change". I've been using mrab's regex daily for about six months, and have found it stable and useful. It now includes two features which are both unusual and useful (very Pythonic!), named lists and fuzzy matching. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
On Fri, 09 Dec 2011 09:02:35 +0100 Stefan Behnel wrote: > a) The stdlib documentation should help users to choose the right > tool right from the start. > b) cElementTree should finally loose it's "special" status as a > separate library and disappear as an accelerator module behind > ElementTree. +1 and +1. I've done a lot of xml work in Python, and unless you've got a particular reason for wanting to use the dom, ElementTree is the only sane way to go. I recently converted a middling-sized app from using the dom to using ElementTree, and wrote up some guidelines for the process for the client. I can try and shake it out of my clients lawyers if it would help with this or others are interested. http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
Mike Meyer wrote: > On Fri, 09 Dec 2011 09:02:35 +0100 > Stefan Behnel wrote: > > > a) The stdlib documentation should help users to choose the right > > tool right from the start. > > b) cElementTree should finally loose it's "special" status as a > > separate library and disappear as an accelerator module behind > > ElementTree. > > +1 and +1. > > I've done a lot of xml work in Python, and unless you've got a > particular reason for wanting to use the dom, ElementTree is the only > sane way to go. I use ElementTree for parsing valid XML, but minidom for producing it. I think another thing that might go into "refreshing the batteries" is a feature comparison of BeautifulSoup and HTML5lib against the stdlib competition, to see what needs to be added/revised. Having to switch to an outside package for parsing possibly invalid HTML is a pain. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
On 9 December 2011 18:15, Bill Janssen wrote: > I use ElementTree for parsing valid XML, but minidom for producing it. > > I think another thing that might go into "refreshing the batteries" is a > feature comparison of BeautifulSoup and HTML5lib against the stdlib > competition, to see what needs to be added/revised. Having to switch to > an outside package for parsing possibly invalid HTML is a pain. For what little use I make of XML/HTML parsing, I use lxml, simply because it has a parser that covers the sort of HTML I have to deal with in real life. As I have lxml installed, I use it for any XML parsing tasks, just because I'm used to it. Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
On Dec 9, 2011, at 12:43 AM, Guido van Rossum wrote: > Even if it weren't slow, I still wouldn't use it to automatically > convert code at install time; a single codebase is easier to reason > about, and easier to support. Users send me tracebacks all the time; > having them match the source is a wonderful thing. > > Even though 2to3 was my idea, I am gradually beginning to appreciate this > approach. I skimmed the docs for "six" and liked it. Actually, maybe I like it a bit better than I thought. The biggest issue for the single-codebase approach is 'except ... as ...'. Peppering one's codebase with calls to sys.exc_info() can be a real performance problem, especially on PyPy. Not to mention how ugly it is. For some reason I thought that this syntax was only supported by 2.7 and up; I see now that it's 2.6 and up. This is still a problem for 2.5 support, of course, but 2.6-only may not be too far away for many projects; Twisted's support schedule for Python versions typically follows Ubuntu's, which means that we might be able to drop 2.5 as early as 2013! :). Even in the plans that involve 2to3 though, "drop everything prior to 2.6" was always supposed to be step 0, so "single codebase" adds much less of a burden than I thought. -glyph ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
On 2011-12-09, at 19:15 , Bill Janssen wrote: > I use ElementTree for parsing valid XML, but minidom for producing it. Could you expand on your reasons to use minidom for producing XML? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Document PyUnicode_Copy() and PyUnicode_EncodeCodePage()
On 09/12/2011 01:35, Antoine Pitrou wrote: On Fri, 09 Dec 2011 00:16:02 +0100 victor.stinner wrote: +.. c:function:: PyObject* PyUnicode_Copy(PyObject *unicode) + + Get a new copy of a Unicode object. + + .. versionadded:: 3.3 I'm not sure I understand. Why would you make a copy of an immutable object? PyUnicode_Copy() can be used to modify a string to create a new string with the same length. It is used for example by str.upper(), str.title(), ... (fixup()). It is also used by str.__getnewargs__(). I am not sure that str.__getnewargs__() must be a copy of str (s.__getnewargs__() is not x). As mentionned by Martin, PyUnicode_Copy() is also used to get "an exact" Unicode object when you have a subtype. We can maybe make the function private. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] re.findall() should return named tuple
hi devs, just an idea that popped up in my mind: re.findall() returns a list of tuples, where every entry of each tuple represents a match group. since match groups can be named, we are able to use named tuples instead of plain tuples here, in the same fashion as namedtuple’s rename works: misssing group names get renamed to _1 and so on. i suggest to add the rename keyword option, to findall, defaulting to True, since mixed positional and named tuples are more common than in usual use cases of namedtuple. do you think it’s a good idea? finally: should i join the mailing list to see answers? should i file a PEP? i have no idea how the inner workings of python development are, but i wanted to share this idea with you :) thanks for keeping python great, philipp ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
Xavier Morel wrote: > On 2011-12-09, at 19:15 , Bill Janssen wrote: > > I use ElementTree for parsing valid XML, but minidom for producing it. > Could you expand on your reasons to use minidom for producing XML? Inertia, I guess. I tried that first, and it seems to work. I tend to use html5lib and/or BeautifulSoup instead of ElementTree, and that's mainly because I find the documentation for ElementTree is confusing and partial and inconsistent. Having various undated but obsolete tutorials and documentation still up on effbot.org doesn't help. Bill ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: Document PyUnicode_Copy() and PyUnicode_EncodeCodePage()
On Fri, 09 Dec 2011 19:51:14 +0100 Victor Stinner wrote: > On 09/12/2011 01:35, Antoine Pitrou wrote: > > On Fri, 09 Dec 2011 00:16:02 +0100 > > victor.stinner wrote: > >> > >> +.. c:function:: PyObject* PyUnicode_Copy(PyObject *unicode) > >> + > >> + Get a new copy of a Unicode object. > >> + > >> + .. versionadded:: 3.3 > > > > I'm not sure I understand. Why would you make a copy of an immutable > > object? > > PyUnicode_Copy() can be used to modify a string to create a new string > with the same length. It is used for example by str.upper(), > str.title(), ... (fixup()). Then the doc should mention that the returned string can be modified. Otherwise it's a bit obscure why the function exists. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
On Fri, Dec 9, 2011 at 10:11 AM, Barry Warsaw wrote: > As Chris points out, this seems to be a use case tied to WSGI and PEP > . I > guess it's an unfortunate choice for so recent a PEP, but maybe there was > no > way to do better. For the record, "native strings" are defined the way they are because of IronPython and Jython, which had unicode strings long before CPython. At the time WSGI was developed, the approach for Python 3 (then called "3000") was expected to be similar, and the new I/O system was not (AFAIR) designed yet. All that changed in PEP was introducing *byte* strings (to accommodate the I/O changes), not native strings. In fact, I'm not sure why people are bringing it into this discussion at all: PEP was designed to work well with 2to3, which does the right thing for WSGI code: it converts 2.x "str" to 3.x "str", as it should. If you're writing 2.x WSGI code with 'u' literals, *your code is broken*. WSGI doesn't need 'u' literals and never has. It *does* need b'' literals for stuff that refers to request and response bodies, but everything else should be plain old string literals for the appropriate Python version. It can certainly be useful in many contexts outside of WSGI. > And *only* there, pretty much. ;-) PEP was designed to work with the official upgrade path (2to3), which is why it has a concept of native strings. Thing is, if you mark them with a 'u', you're writing incorrect code for 2.x. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [PATCH] Adding braces to __future__
IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD BEEN DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", THAT "WHO DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR SOMETHING SIMILAR, JUST DON'T. Otherwise, read on. I know very well that this topic has been discussed before. On forums. Mailing lists. IRC. Blogs. From person to person, even. And I know equally well, from all those years experiencing argument-turned-debates on the internet, how a (minor|major) fraction of participants make up for their inability to lead a proper debate by speaking the loudest of all, so that eventually quantity triumphs over quality and logic. That ahead; I hope you can try not to fall in that category. Let instead reason prevail over sentimentalism, mislead purism, elitism, and all other sorts of isms which hinder advancement in the greater context. Python has surprised once already: The changes from 2 to 3 were not downwards compatible because the core developers realized there is more to a sustainable language than constantly patching it up until it comes apart like the roman empire. Let's keep that spirit for a second and let us discuss braces, again, with the clear goal of improving the language. End of disclaimer? End of disclaimer! Whitespace-Blocking (WSB) as opposed to Delimiter-Blocking (DB) has reasons. What are those reasons? Well, primarily, it forces the programmer to maintain well readable code. Then, some might argue, it is quicker to type. Two reasons, but of what importance are they? And are they actually reasons? You may guessed it from the questions themselves that I'm about to question that. I don't intend to connote brazen implications, so let me spell out what I just implied: I think anyone who thinks that exclusive WSB is a good alternative or even preferable to DB is actually deluding themselves for some personal version of one of those isms mentioned above. Let's examine these alleged advantages objectively one for one. But before that, just to calm troubled waters a little, allow me bring forward the conclusion: Absolutely no intentions to remowe WSB from Python. Although one might have gotten that impression from the early paragraphs, no intentions to break downwards compatibility, either. What Python needs is an alternative to WSB and can stay Python by still offering WSB to all those who happen to like it. Readable code, is it really an advantage? Two linebreaks, just for the suspense, then: Of course it is. Forcing the programmer to write readable code, is that an advantage? No suspense, the answer is Of course not. Python may have started off as the casual scripting language for casual people. People, who may not even have known programming. And perhaps it has made sense to force -- or shall we say motivate, since you can still produce perfectly obfuscated code with Python -- them to write readably. But Python has matured and so has its clientele. Python does not become a better language, neither for beginners nor for experienced programmers who also frequently use Python these days, by patronizing them and restricting them in their freedom. Readable code? Yes. Forcing people to write readable code by artificial means? No. Practice is evidence for the mischief of this policy: Does the FOSS community suffer from a notorious lack of proper indention or readability of code? Of course we don't. I'm not a native speaker, but dict.cc tells me that what we call "mit Kanonen auf Spatzen schießen" (firing cannons at sparrows) is called breaking a fly on the wheel in English. I may lack the analogy for the fly on the wheel, which, if I'm not mistaken, used to be a device for torture in the Middle Ages, but I can tell you that the cannon ball which might have struck the sparrows, coincidently caused havoc in the hinterlands. For the wide-spread and professional language Python is today, the idea of forcing people to indent is misguided. These days, it may address a neglible minority of absolute beginners who barely started programming and would not listen to the simple advice of indenting properly, but on the other hand it hurts/annoys/deters a great community of typical programmers for whom DB has long become a de facto standard. For them, it's not a mere inconsistency without, for them, any apparent reason. It's more than the inconvenience not being able to follow ones long time practices, using the scripts one wrote for delimiters, the shortcuts that are usually offered by editor, etc. It also brings about a whole class of new problems which may be anticipated and prevent, yet bear a great potential for new, even hard-to-find bugs (just in case anyone would respond that we had eventually successfully redeemed the mismatched parenthesis problem - at what cost?!). Not just difficult to find, near to impossible would be the right word for anyone who has to review someone else's patch. It is widely known among the programmer's community that
Re: [Python-Dev] [PATCH] Adding braces to __future__
On Fri, Dec 9, 2011 at 14:26, Cedric Sodhi wrote: > IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD BEEN > DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", THAT "WHO > DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR SOMETHING > SIMILAR, JUST DON'T. > > Otherwise, read on. > > I know very well that this topic has been discussed before. On forums. > Mailing lists. IRC. Blogs. From person to person, even. > > And I know equally well, from all those years experiencing > argument-turned-debates on the internet, how a (minor|major) fraction of > participants make up for their inability to lead a proper debate by > speaking the loudest of all, so that eventually quantity triumphs over > quality and logic. > > That ahead; I hope you can try not to fall in that category. Let instead > reason prevail over sentimentalism, mislead purism, elitism, and all > other sorts of isms which hinder advancement in the greater context. > > Python has surprised once already: The changes from 2 to 3 were not > downwards compatible because the core developers realized there is more > to a sustainable language than constantly patching it up until it comes > apart like the roman empire. > > Let's keep that spirit for a second and let us discuss braces, again, > with the clear goal of improving the language. > > End of disclaimer? > > End of disclaimer! > > Whitespace-Blocking (WSB) as opposed to Delimiter-Blocking (DB) has > reasons. What are those reasons? Well, primarily, it forces the > programmer to maintain well readable code. Then, some might argue, it is > quicker to type. > > Two reasons, but of what importance are they? And are they actually > reasons? > > You may guessed it from the questions themselves that I'm about to > question that. > > I don't intend to connote brazen implications, so let me spell out what > I just implied: I think anyone who thinks that exclusive WSB is a good > alternative or even preferable to DB is actually deluding themselves for > some personal version of one of those isms mentioned above. > > Let's examine these alleged advantages objectively one for one. But > before that, just to calm troubled waters a little, allow me bring > forward the conclusion: > > Absolutely no intentions to remowe WSB from Python. Although one might > have gotten that impression from the early paragraphs, no intentions to > break downwards compatibility, either. > > What Python needs is an alternative to WSB and can stay Python by still > offering WSB to all those who happen to like it. > > Readable code, is it really an advantage? > > Two linebreaks, just for the suspense, then: > > Of course it is. > > Forcing the programmer to write readable code, is that an advantage? No > suspense, the answer is Of course not. > > Python may have started off as the casual scripting language for casual > people. People, who may not even have known programming. And perhaps it > has made sense to force -- or shall we say motivate, since you can still > produce perfectly obfuscated code with Python -- them to write readably. > > But Python has matured and so has its clientele. Python does not become > a better language, neither for beginners nor for experienced programmers > who also frequently use Python these days, by patronizing them and > restricting them in their freedom. > > Readable code? Yes. Forcing people to write readable code by artificial > means? No. > > Practice is evidence for the mischief of this policy: Does the FOSS > community suffer from a notorious lack of proper indention or > readability of code? Of course we don't. > > I'm not a native speaker, but dict.cc tells me that what we call "mit > Kanonen auf Spatzen schießen" (firing cannons at sparrows) is called > breaking a fly on the wheel in English. > > I may lack the analogy for the fly on the wheel, which, if I'm not > mistaken, used to be a device for torture in the Middle Ages, but I can > tell you that the cannon ball which might have struck the sparrows, > coincidently caused havoc in the hinterlands. > > For the wide-spread and professional language Python is today, the idea > of forcing people to indent is misguided. These days, it may address a > neglible minority of absolute beginners who barely started programming > and would not listen to the simple advice of indenting properly, but on > the other hand it hurts/annoys/deters a great community of typical > programmers for whom DB has long become a de facto standard. > > For them, it's not a mere inconsistency without, for them, any apparent > reason. It's more than the inconvenience not being able to follow ones > long time practices, using the scripts one wrote for delimiters, the > shortcuts that are usually offered by editor, etc. > > It also brings about a whole class of new problems which may be > anticipated and prevent, yet bear a great potential for new, even > hard-to-find bugs (just in case anyone would respond that we had > eventually successfully r
Re: [Python-Dev] readd u'' literal support in 3.3?
On Fri, Dec 9, 2011 at 17:38, Éric Araujo wrote: > When running 2to3 from a setup.py script, does it run on the whole > codebase or only files that are found newer by the make-like > timestamp-based dependency system? Only on the ones that are newer. But since at install time, that's all of them, it doesn't really help. :-) //Lennart ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PATCH] Adding braces to __future__
On Friday, December 9, 2011 at 3:26 PM, Cedric Sodhi wrote: > IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD BEEN > DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", THAT "WHO > DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR SOMETHING > SIMILAR, JUST DON'T. > > Otherwise, read on. > > I know very well that this topic has been discussed before. On forums. > Mailing lists. IRC. Blogs. From person to person, even. > > And I know equally well, from all those years experiencing > argument-turned-debates on the internet, how a (minor|major) fraction of > participants make up for their inability to lead a proper debate by > speaking the loudest of all, so that eventually quantity triumphs over > quality and logic. > > That ahead; I hope you can try not to fall in that category. Let instead > reason prevail over sentimentalism, mislead purism, elitism, and all > other sorts of isms which hinder advancement in the greater context. > > Python has surprised once already: The changes from 2 to 3 were not > downwards compatible because the core developers realized there is more > to a sustainable language than constantly patching it up until it comes > apart like the roman empire. > > Let's keep that spirit for a second and let us discuss braces, again, > with the clear goal of improving the language. > > End of disclaimer? > > End of disclaimer! > > Whitespace-Blocking (WSB) as opposed to Delimiter-Blocking (DB) has > reasons. What are those reasons? Well, primarily, it forces the > programmer to maintain well readable code. Then, some might argue, it is > quicker to type. > > Two reasons, but of what importance are they? And are they actually > reasons? > > You may guessed it from the questions themselves that I'm about to > question that. > > I don't intend to connote brazen implications, so let me spell out what > I just implied: I think anyone who thinks that exclusive WSB is a good > alternative or even preferable to DB is actually deluding themselves for > some personal version of one of those isms mentioned above. > > Let's examine these alleged advantages objectively one for one. But > before that, just to calm troubled waters a little, allow me bring > forward the conclusion: > > Absolutely no intentions to remowe WSB from Python. Although one might > have gotten that impression from the early paragraphs, no intentions to > break downwards compatibility, either. > > What Python needs is an alternative to WSB and can stay Python by still > offering WSB to all those who happen to like it. > > Readable code, is it really an advantage? > > Two linebreaks, just for the suspense, then: > > Of course it is. > > Forcing the programmer to write readable code, is that an advantage? No > suspense, the answer is Of course not. > > Python may have started off as the casual scripting language for casual > people. People, who may not even have known programming. And perhaps it > has made sense to force -- or shall we say motivate, since you can still > produce perfectly obfuscated code with Python -- them to write readably. > > But Python has matured and so has its clientele. Python does not become > a better language, neither for beginners nor for experienced programmers > who also frequently use Python these days, by patronizing them and > restricting them in their freedom. > > Readable code? Yes. Forcing people to write readable code by artificial > means? No. > > Practice is evidence for the mischief of this policy: Does the FOSS > community suffer from a notorious lack of proper indention or > readability of code? Of course we don't. > > I'm not a native speaker, but dict.cc (http://dict.cc) tells me that what we > call "mit > Kanonen auf Spatzen schießen" (firing cannons at sparrows) is called > breaking a fly on the wheel in English. > > I may lack the analogy for the fly on the wheel, which, if I'm not > mistaken, used to be a device for torture in the Middle Ages, but I can > tell you that the cannon ball which might have struck the sparrows, > coincidently caused havoc in the hinterlands. > > For the wide-spread and professional language Python is today, the idea > of forcing people to indent is misguided. These days, it may address a > neglible minority of absolute beginners who barely started programming > and would not listen to the simple advice of indenting properly, but on > the other hand it hurts/annoys/deters a great community of typical > programmers for whom DB has long become a de facto standard. > > For them, it's not a mere inconsistency without, for them, any apparent > reason. It's more than the inconvenience not being able to follow ones > long time practices, using the scripts one wrote for delimiters, the > shortcuts that are usually offered by editor, etc. > > It also brings about a whole class of new problems which may be > anticipated and prevent, yet bear a great potential for new, even > hard
Re: [Python-Dev] [PATCH] Adding braces to __future__
On 2011-12-09, at 21:26 , Cedric Sodhi wrote: > IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD BEEN > DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", THAT "WHO > DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR SOMETHING > SIMILAR, JUST DON'T. > > Otherwise, read on. > > I know very well that this topic has been discussed before. On forums. > Mailing lists. IRC. Blogs. From person to person, even. > > And I know equally well, from all those years experiencing > argument-turned-debates on the internet, how a (minor|major) fraction of > participants make up for their inability to lead a proper debate by > speaking the loudest of all, so that eventually quantity triumphs over > quality and logic. > > That ahead; I hope you can try not to fall in that category. Let instead > reason prevail over sentimentalism, mislead purism, elitism, and all > other sorts of isms which hinder advancement in the greater context. > > Python has surprised once already: The changes from 2 to 3 were not > downwards compatible because the core developers realized there is more > to a sustainable language than constantly patching it up until it comes > apart like the roman empire. > > Let's keep that spirit for a second and let us discuss braces, again, > with the clear goal of improving the language. > > End of disclaimer? > > End of disclaimer! > > Whitespace-Blocking (WSB) as opposed to Delimiter-Blocking (DB) has > reasons. What are those reasons? Well, primarily, it forces the > programmer to maintain well readable code. Then, some might argue, it is > quicker to type. > > Two reasons, but of what importance are they? And are they actually > reasons? > > You may guessed it from the questions themselves that I'm about to > question that. > > I don't intend to connote brazen implications, so let me spell out what > I just implied: I think anyone who thinks that exclusive WSB is a good > alternative or even preferable to DB is actually deluding themselves for > some personal version of one of those isms mentioned above. > > Let's examine these alleged advantages objectively one for one. But > before that, just to calm troubled waters a little, allow me bring > forward the conclusion: > > Absolutely no intentions to remowe WSB from Python. Although one might > have gotten that impression from the early paragraphs, no intentions to > break downwards compatibility, either. > > What Python needs is an alternative to WSB and can stay Python by still > offering WSB to all those who happen to like it. > > Readable code, is it really an advantage? > > Two linebreaks, just for the suspense, then: > > Of course it is. > > Forcing the programmer to write readable code, is that an advantage? No > suspense, the answer is Of course not. > > Python may have started off as the casual scripting language for casual > people. People, who may not even have known programming. And perhaps it > has made sense to force -- or shall we say motivate, since you can still > produce perfectly obfuscated code with Python -- them to write readably. > > But Python has matured and so has its clientele. Python does not become > a better language, neither for beginners nor for experienced programmers > who also frequently use Python these days, by patronizing them and > restricting them in their freedom. > > Readable code? Yes. Forcing people to write readable code by artificial > means? No. > > Practice is evidence for the mischief of this policy: Does the FOSS > community suffer from a notorious lack of proper indention or > readability of code? Of course we don't. > > I'm not a native speaker, but dict.cc tells me that what we call "mit > Kanonen auf Spatzen schießen" (firing cannons at sparrows) is called > breaking a fly on the wheel in English. > > I may lack the analogy for the fly on the wheel, which, if I'm not > mistaken, used to be a device for torture in the Middle Ages, but I can > tell you that the cannon ball which might have struck the sparrows, > coincidently caused havoc in the hinterlands. > > For the wide-spread and professional language Python is today, the idea > of forcing people to indent is misguided. These days, it may address a > neglible minority of absolute beginners who barely started programming > and would not listen to the simple advice of indenting properly, but on > the other hand it hurts/annoys/deters a great community of typical > programmers for whom DB has long become a de facto standard. > > For them, it's not a mere inconsistency without, for them, any apparent > reason. It's more than the inconvenience not being able to follow ones > long time practices, using the scripts one wrote for delimiters, the > shortcuts that are usually offered by editor, etc. > > It also brings about a whole class of new problems which may be > anticipated and prevent, yet bear a great potential for new, even > hard-to-find bugs (just in case anyone would respond that we had > ev
Re: [Python-Dev] [PATCH] Adding braces to __future__
Cedric Sodhi writes: > IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD BEEN > DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", THAT "WHO > DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR SOMETHING > SIMILAR, JUST DON'T. If you're going to post a long screed on a settled subject, and try to lay a heap of special restrictions in an open discussion forum on how you want people to respond: just don't. -- \ “Don't be afraid of missing opportunities. Behind every failure | `\ is an opportunity somebody wishes they had missed.” —Jane | _o__) Wagner, via Lily Tomlin | Ben Finney ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PATCH] Adding braces to __future__
On Fri, 9 Dec 2011 21:26:29 +0100 Cedric Sodhi wrote: > Readable code, is it really an advantage? > Of course it is. Ok, you got that right. > Forcing the programmer to write readable code, is that an advantage? > No suspense, the answer is Of course not. This is *not* an "Of course". Readable code is *important*. Giving programmers more power in exchange for less readable code is a bad trade. For an extended analsysis, see: http://blog.mired.org/2011/10/more-power-is-not-always-good-thing.html One of Python's best points is that the community resists the urge to add things just to add things. The community generally applies three tests to any feature before accepting it: 1) It should have a good use case. 2) It should enable more readable code for that use case. 3) It shouldn't make writing unreadable code easy. DB fails all three of these tests. It doesn't have a good use case. The code you create using it is not more readable than the alternative. And it definitely makes writing unreadable code easy. And of course, it violates TOOWTDI. http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PATCH] Adding braces to __future__
On Fri, Dec 09, 2011 at 01:11:29PM -0800, Mike Meyer wrote: > On Fri, 9 Dec 2011 21:26:29 +0100 > Cedric Sodhi wrote: > > Readable code, is it really an advantage? > > Of course it is. > > Ok, you got that right. Thank you. It doesn't go unnoticed that you learned your Feedback Rules. > > > Forcing the programmer to write readable code, is that an advantage? > > No suspense, the answer is Of course not. > > This is *not* an "Of course". Readable code is *important*. Giving > programmers more power in exchange for less readable code is a bad > trade. For an extended analsysis, see: > http://blog.mired.org/2011/10/more-power-is-not-always-good-thing.html And here is the catch. The typical ignoratio elenchi which is frequently put forward by those who want to depict WSB as a neccessity, as a social contract à Locke for the Python community, by which they oblidge themselves to write readable code. The fallacy is trivial, though, and even further supported by evidence presented by reality. Indeed, you pretty much serve the comeback on a silver plate: "Power in exchange for less readable code" There is no such exchange. Instead of further elaborating on why I say that, I leave it to you and possible others readers to recognize the fallacy as a whole. Rather, let me support the argument by the apparent evidence which I already emphasized in the introductory script: Not a single language in the FOSS community suffers from a lack of proper indention. The propagated fear of unreadable code is unjustified. That article you linked also completely ignores that. kind regards, Cedric ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PATCH] Adding braces to __future__
Dear Cedric, I'm guessing you drank too much (perhaps you are training for New Year's Eve), ate some bad sausages or are simply very self-complacent. python-dev is not the place where to post long unstructured ramblings with no practical value. Consider writing on your personal blog instead. Thank you Antoine. On Fri, 9 Dec 2011 21:26:29 +0100 Cedric Sodhi wrote: > IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD BEEN > DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", THAT "WHO > DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR SOMETHING > SIMILAR, JUST DON'T. > > Otherwise, read on. > > I know very well that this topic has been discussed before. On forums. > Mailing lists. IRC. Blogs. From person to person, even. > > And I know equally well, from all those years experiencing > argument-turned-debates on the internet, how a (minor|major) fraction of > participants make up for their inability to lead a proper debate by > speaking the loudest of all, so that eventually quantity triumphs over > quality and logic. > > That ahead; I hope you can try not to fall in that category. Let instead > reason prevail over sentimentalism, mislead purism, elitism, and all > other sorts of isms which hinder advancement in the greater context. > > Python has surprised once already: The changes from 2 to 3 were not > downwards compatible because the core developers realized there is more > to a sustainable language than constantly patching it up until it comes > apart like the roman empire. > > Let's keep that spirit for a second and let us discuss braces, again, > with the clear goal of improving the language. > > End of disclaimer? > > End of disclaimer! > > Whitespace-Blocking (WSB) as opposed to Delimiter-Blocking (DB) has > reasons. What are those reasons? Well, primarily, it forces the > programmer to maintain well readable code. Then, some might argue, it is > quicker to type. > > Two reasons, but of what importance are they? And are they actually > reasons? > > You may guessed it from the questions themselves that I'm about to > question that. > > I don't intend to connote brazen implications, so let me spell out what > I just implied: I think anyone who thinks that exclusive WSB is a good > alternative or even preferable to DB is actually deluding themselves for > some personal version of one of those isms mentioned above. > > Let's examine these alleged advantages objectively one for one. But > before that, just to calm troubled waters a little, allow me bring > forward the conclusion: > > Absolutely no intentions to remowe WSB from Python. Although one might > have gotten that impression from the early paragraphs, no intentions to > break downwards compatibility, either. > > What Python needs is an alternative to WSB and can stay Python by still > offering WSB to all those who happen to like it. > > Readable code, is it really an advantage? > > Two linebreaks, just for the suspense, then: > > Of course it is. > > Forcing the programmer to write readable code, is that an advantage? No > suspense, the answer is Of course not. > > Python may have started off as the casual scripting language for casual > people. People, who may not even have known programming. And perhaps it > has made sense to force -- or shall we say motivate, since you can still > produce perfectly obfuscated code with Python -- them to write readably. > > But Python has matured and so has its clientele. Python does not become > a better language, neither for beginners nor for experienced programmers > who also frequently use Python these days, by patronizing them and > restricting them in their freedom. > > Readable code? Yes. Forcing people to write readable code by artificial > means? No. > > Practice is evidence for the mischief of this policy: Does the FOSS > community suffer from a notorious lack of proper indention or > readability of code? Of course we don't. > > I'm not a native speaker, but dict.cc tells me that what we call "mit > Kanonen auf Spatzen schießen" (firing cannons at sparrows) is called > breaking a fly on the wheel in English. > > I may lack the analogy for the fly on the wheel, which, if I'm not > mistaken, used to be a device for torture in the Middle Ages, but I can > tell you that the cannon ball which might have struck the sparrows, > coincidently caused havoc in the hinterlands. > > For the wide-spread and professional language Python is today, the idea > of forcing people to indent is misguided. These days, it may address a > neglible minority of absolute beginners who barely started programming > and would not listen to the simple advice of indenting properly, but on > the other hand it hurts/annoys/deters a great community of typical > programmers for whom DB has long become a de facto standard. > > For them, it's not a mere inconsistency without, for them, any apparent > reason. It's more than the inconvenience not being able to follow ones > lo
Re: [Python-Dev] [PATCH] Adding braces to __future__
This belongs on python-ideas. Please take it there. ~Ethan~ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PATCH] Adding braces to __future__
I don't always post to python-dev, but when I do I ask for braces. On Friday, December 9, 2011 at 4:43 PM, Antoine Pitrou wrote: > > Dear Cedric, > > I'm guessing you drank too much (perhaps you are training for New Year's > Eve), ate some bad sausages or are simply very self-complacent. > python-dev is not the place where to post long unstructured ramblings > with no practical value. Consider writing on your personal blog > instead. > > Thank you > > Antoine. > > > > On Fri, 9 Dec 2011 21:26:29 +0100 > Cedric Sodhi mailto:[email protected])> wrote: > > IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD BEEN > > DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", THAT "WHO > > DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR SOMETHING > > SIMILAR, JUST DON'T. > > > > Otherwise, read on. > > > > I know very well that this topic has been discussed before. On forums. > > Mailing lists. IRC. Blogs. From person to person, even. > > > > And I know equally well, from all those years experiencing > > argument-turned-debates on the internet, how a (minor|major) fraction of > > participants make up for their inability to lead a proper debate by > > speaking the loudest of all, so that eventually quantity triumphs over > > quality and logic. > > > > That ahead; I hope you can try not to fall in that category. Let instead > > reason prevail over sentimentalism, mislead purism, elitism, and all > > other sorts of isms which hinder advancement in the greater context. > > > > Python has surprised once already: The changes from 2 to 3 were not > > downwards compatible because the core developers realized there is more > > to a sustainable language than constantly patching it up until it comes > > apart like the roman empire. > > > > Let's keep that spirit for a second and let us discuss braces, again, > > with the clear goal of improving the language. > > > > End of disclaimer? > > > > End of disclaimer! > > > > Whitespace-Blocking (WSB) as opposed to Delimiter-Blocking (DB) has > > reasons. What are those reasons? Well, primarily, it forces the > > programmer to maintain well readable code. Then, some might argue, it is > > quicker to type. > > > > Two reasons, but of what importance are they? And are they actually > > reasons? > > > > You may guessed it from the questions themselves that I'm about to > > question that. > > > > I don't intend to connote brazen implications, so let me spell out what > > I just implied: I think anyone who thinks that exclusive WSB is a good > > alternative or even preferable to DB is actually deluding themselves for > > some personal version of one of those isms mentioned above. > > > > Let's examine these alleged advantages objectively one for one. But > > before that, just to calm troubled waters a little, allow me bring > > forward the conclusion: > > > > Absolutely no intentions to remowe WSB from Python. Although one might > > have gotten that impression from the early paragraphs, no intentions to > > break downwards compatibility, either. > > > > What Python needs is an alternative to WSB and can stay Python by still > > offering WSB to all those who happen to like it. > > > > Readable code, is it really an advantage? > > > > Two linebreaks, just for the suspense, then: > > > > Of course it is. > > > > Forcing the programmer to write readable code, is that an advantage? No > > suspense, the answer is Of course not. > > > > Python may have started off as the casual scripting language for casual > > people. People, who may not even have known programming. And perhaps it > > has made sense to force -- or shall we say motivate, since you can still > > produce perfectly obfuscated code with Python -- them to write readably. > > > > But Python has matured and so has its clientele. Python does not become > > a better language, neither for beginners nor for experienced programmers > > who also frequently use Python these days, by patronizing them and > > restricting them in their freedom. > > > > Readable code? Yes. Forcing people to write readable code by artificial > > means? No. > > > > Practice is evidence for the mischief of this policy: Does the FOSS > > community suffer from a notorious lack of proper indention or > > readability of code? Of course we don't. > > > > I'm not a native speaker, but dict.cc (http://dict.cc) tells me that what > > we call "mit > > Kanonen auf Spatzen schießen" (firing cannons at sparrows) is called > > breaking a fly on the wheel in English. > > > > I may lack the analogy for the fly on the wheel, which, if I'm not > > mistaken, used to be a device for torture in the Middle Ages, but I can > > tell you that the cannon ball which might have struck the sparrows, > > coincidently caused havoc in the hinterlands. > > > > For the wide-spread and professional language Python is today, the idea > > of forcing people to indent is misguided. These days, it may address
Re: [Python-Dev] [PATCH] Adding braces to __future__
You've really only given one reason why braces are a good idea: "I also appreciate single lined conditional or loops once in a while." Not only is this argument even weaker than the two you yourself gave in defense of whitespace, these two features are already supported in Python. If you're not aware of them, perhaps you should spend some quality time with the documentation rather than suggesting unnecessary changes. -Marty ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PATCH] Adding braces to __future__
On Fri, Dec 9, 2011 at 12:26 PM, Cedric Sodhi wrote: > IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD BEEN > DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", THAT "WHO > DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR SOMETHING > SIMILAR, JUST DON'T. > Every single response in this thread so far has ignored this request. The correct response honoring this should have been deafening silence. For me, if I had to design a new language today, I would probably use braces, not because they're better than whitespace, but because pretty much every other lanugage uses them, and there are more interesting concepts to distinguish a new language. That said, I don't regret that Python uses indentation, and the rest I have to say about the topic would violate the above request. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PATCH] Adding braces to __future__
On Fri, Dec 09, 2011 at 02:21:42PM -0800, Guido van Rossum wrote: >On Fri, Dec 9, 2011 at 12:26 PM, Cedric Sodhi <[1][email protected]> wrote: > > IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD BEEN > DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", THAT "WHO > DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR SOMETHING > SIMILAR, JUST DON'T. > >Every single response in this thread so far has ignored this request. The >correct response honoring this should have been deafening silence. > >For me, if I had to design a new language today, I would probably use >braces, not because they're better than whitespace, but because pretty >much every other lanugage uses them, and there are more interesting >concepts to distinguish a new language. That said, I don't regret that >Python uses indentation, and the rest I have to say about the topic would >violate the above request. > I think this deserves a reply. Thank you for contributing your opinion and respecting my request and therefore honoring the rules of a civilized debate. -- Cedric ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PATCH] Adding braces to __future__
If braces were introduced I would switch to Haskell, I can't stand the noise. If you want to see a language that allows both whitespace, semi colons and braces take a look at it. Nails it. On Dec 10, 2011 9:31 AM, "Cedric Sodhi" wrote: > On Fri, Dec 09, 2011 at 02:21:42PM -0800, Guido van Rossum wrote: > >On Fri, Dec 9, 2011 at 12:26 PM, Cedric Sodhi <[1][email protected]> > wrote: > > > > IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS HAD > BEEN > > DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", THAT > "WHO > > DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR SOMETHING > > SIMILAR, JUST DON'T. > > > >Every single response in this thread so far has ignored this request. > The > >correct response honoring this should have been deafening silence. > > > >For me, if I had to design a new language today, I would probably use > >braces, not because they're better than whitespace, but because pretty > >much every other lanugage uses them, and there are more interesting > >concepts to distinguish a new language. That said, I don't regret that > >Python uses indentation, and the rest I have to say about the topic > would > >violate the above request. > > > > I think this deserves a reply. Thank you for contributing your opinion > and respecting my request and therefore honoring the rules of a > civilized debate. > > -- Cedric > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
I second this. The doco is very bad. On Dec 10, 2011 6:34 AM, "Bill Janssen" wrote: > Xavier Morel wrote: > > > On 2011-12-09, at 19:15 , Bill Janssen wrote: > > > I use ElementTree for parsing valid XML, but minidom for producing it. > > Could you expand on your reasons to use minidom for producing XML? > > Inertia, I guess. I tried that first, and it seems to work. > > I tend to use html5lib and/or BeautifulSoup instead of ElementTree, and > that's mainly because I find the documentation for ElementTree is > confusing and partial and inconsistent. Having various undated but > obsolete tutorials and documentation still up on effbot.org doesn't > help. > > > Bill > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PATCH] Adding braces to __future__
I reply to your contribution mainly because I see another, valid argument hidden in what you formulated as an opinion: Readability would be reduced by such "noise". To anticipate other people agreeing with that, let me say, that it would be exactly one more character, and the same amount of key presses. All that, assuming you use editor automatisms, which particularly the advocates of WSB tend to bring forth in defense of WSB and aforementioned problems associated with it. Only one more character and not more key presses? Yes, instead of opening a block with a colon, you open it with an opening bracket. And you close it with a closing one. Referring to "noise", I take it you are preferring naturally expressed languages (what Roff's PIC, for example, exemplifies to banality). How is a COLON, which, in natural language, PUNCTUATES a context, any more suited than braces, which naturally ENCLOSE a structure? Obviously, it by far is not, even from the standpoint of not intersparsing readable code with unnatural characters. On Sat, Dec 10, 2011 at 09:40:54AM +1100, Matt Joiner wrote: >If braces were introduced I would switch to Haskell, I can't stand the >noise. If you want to see a language that allows both whitespace, semi >colons and braces take a look at it. Nails it. > >On Dec 10, 2011 9:31 AM, "Cedric Sodhi" <[1][email protected]> wrote: > > On Fri, Dec 09, 2011 at 02:21:42PM -0800, Guido van Rossum wrote: > > On Fri, Dec 9, 2011 at 12:26 PM, Cedric Sodhi > <[1][2][email protected]> wrote: > > > > IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT THIS > HAD BEEN > > DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", > THAT "WHO > > DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR SOMETHING > > SIMILAR, JUST DON'T. > > > > Every single response in this thread so far has ignored this > request. The > > correct response honoring this should have been deafening silence. > > > > For me, if I had to design a new language today, I would probably > use > > braces, not because they're better than whitespace, but because > pretty > > much every other lanugage uses them, and there are more interesting > > concepts to distinguish a new language. That said, I don't regret > that > > Python uses indentation, and the rest I have to say about the topic > would > > violate the above request. > > > > I think this deserves a reply. Thank you for contributing your opinion > and respecting my request and therefore honoring the rules of a > civilized debate. > > -- Cedric > ___ > Python-Dev mailing list > [3][email protected] > [4]http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > > [5]http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com > > References > >Visible links >1. mailto:[email protected] >2. mailto:[email protected] >3. mailto:[email protected] >4. http://mail.python.org/mailman/listinfo/python-dev >5. http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PATCH] Adding braces to __future__
Point of order (repeated), please move this thread to python-ideas. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
Glyph twistedmatrix.com> writes: > The biggest issue for the single-codebase approach is 'except ... as ...'. > Peppering one's codebase with calls to sys.exc_info() can be a real > performance problem, especially on PyPy. Not to mention how ugly it is. > For some reason I thought that this syntax was only supported by 2.7 and up; > I see now that it's 2.6 and up. Granted that it's ugly, but where is the evidence that it can be a real performance problem? I mean in practice on real projects, rather than in theory or on code contrived to show up a problem. Please note, I'm not saying it isn't a real performance problem, I'm just asking where the evidence is, whether running on PyPy or elsewhere. Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PATCH] Adding braces to __future__
Guido van Rossum wrote: Point of order (repeated), please move this thread to python-ideas. Isn't that cruel to the people reading python-ideas? -- Steven ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [PATCH] Adding braces to __future__
Ditch the colon too. Also you're a troll. On Dec 10, 2011 9:58 AM, "Cedric Sodhi" wrote: > I reply to your contribution mainly because I see another, valid > argument hidden in what you formulated as an opinion: > > Readability would be reduced by such "noise". To anticipate other people > agreeing with that, let me say, that it would be exactly one more > character, and the same amount of key presses. All that, assuming you > use editor automatisms, which particularly the advocates of WSB tend to > bring forth in defense of WSB and aforementioned problems associated > with it. > > Only one more character and not more key presses? Yes, instead of > opening a block with a colon, you open it with an opening bracket. And > you close it with a closing one. > > Referring to "noise", I take it you are preferring naturally expressed > languages (what Roff's PIC, for example, exemplifies to banality). > > How is a COLON, which, in natural language, PUNCTUATES a context, any > more suited than braces, which naturally ENCLOSE a structure? > > Obviously, it by far is not, even from the standpoint of not > intersparsing readable code with unnatural characters. > > On Sat, Dec 10, 2011 at 09:40:54AM +1100, Matt Joiner wrote: > >If braces were introduced I would switch to Haskell, I can't stand the > >noise. If you want to see a language that allows both whitespace, semi > >colons and braces take a look at it. Nails it. > > > >On Dec 10, 2011 9:31 AM, "Cedric Sodhi" <[1][email protected]> wrote: > > > > On Fri, Dec 09, 2011 at 02:21:42PM -0800, Guido van Rossum wrote: > > >On Fri, Dec 9, 2011 at 12:26 PM, Cedric Sodhi > > <[1][2][email protected]> wrote: > > > > > > IF YOU THINK YOU MUST REPLY SOMETHING WITTY, ITERATE THAT > THIS > > HAD BEEN > > > DISCUSSED BEFORE, REPLY THAT "IT'S SIMPLY NOT GO'NNA HAPPEN", > > THAT "WHO > > > DOESN'T LIKE IT IS FREE TO CHOOSE ANOTHER LANGUAGE" OR > SOMETHING > > > SIMILAR, JUST DON'T. > > > > > >Every single response in this thread so far has ignored this > > request. The > > >correct response honoring this should have been deafening > silence. > > > > > >For me, if I had to design a new language today, I would > probably > > use > > >braces, not because they're better than whitespace, but because > > pretty > > >much every other lanugage uses them, and there are more > interesting > > >concepts to distinguish a new language. That said, I don't > regret > > that > > >Python uses indentation, and the rest I have to say about the > topic > > would > > >violate the above request. > > > > > > > I think this deserves a reply. Thank you for contributing your > opinion > > and respecting my request and therefore honoring the rules of a > > civilized debate. > > > > -- Cedric > > ___ > > Python-Dev mailing list > > [3][email protected] > > [4]http://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > > [5] > http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com > > > > References > > > >Visible links > >1. mailto:[email protected] > >2. mailto:[email protected] > >3. mailto:[email protected] > >4. http://mail.python.org/mailman/listinfo/python-dev > >5. > http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
On Sat, Dec 10, 2011 at 00:43, Matt Joiner wrote: > I second this. The doco is very bad. > It would be constructive to open issues for specific problems in the documentation. I'm sure this won't be hard to fix. Documentation should not be the roadblock for using a library. Eli ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] re.findall() should return named tuple
On 12/8/2011 8:31 AM, Philipp A. wrote: hi devs, just an idea that popped up in my mind: re.findall() returns a list of tuples, where every entry of each tuple represents a match group. since match groups can be named, we are able to use named tuples instead of plain tuples here, in the same fashion as namedtuple’s rename works: misssing group names get renamed to _1 and so on. i suggest to add the rename keyword option, to findall, defaulting to True, since mixed positional and named tuples are more common than in usual use cases of namedtuple. do you think it’s a good idea? I have not used named tuples or re.findall (much), so I have no opinion). finally: should i join the mailing list to see answers? should i file a PEP? i have no idea how the inner workings of python development are, but i wanted to share this idea with you :) Ideas like this should either go the the python-ideas list or to the tracker at bugs.python.org as a feature request. If you post to the list, you should either subscribe at mail.python.org or follow it as a newsgroup at news.gmane.org (which is what I do). Posting a tracker issue requires registration of some sort. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Tag trackbacks with version (was Re: readd u'' literal support in 3.3?)
On 12/9/2011 5:17 AM, Nick Coghlan wrote: As Chris pointed out though, the real problem with the "repeatedly run 2to3" workflow is that it can make interpreting tracebacks from the field *really* hard. This just gave me the idea of tagging tracebacks with the Python version number. Something like Traceback (Py3.2.2, most recent call last): and perhaps with the platform also Traceback (most recent call last) [Py3.2.2 on win23]: Since computation has stopped, the few extra milliseconds is trivial. This would certainly help on Python list and the tracker when people do post the traceback (which they do not always) without version and system (which they often do not, especially on Python list). It might suggest to people that this is important info to include. I wonder if this would also help with tracebacks sent to library/app developers. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] readd u'' literal support in 3.3?
On Sat, Dec 10, 2011 at 5:58 AM, PJ Eby wrote:
> In fact, I'm not sure why people are bringing it into this discussion at
> all: PEP was designed to work well with 2to3, which does the right
> thing for WSGI code: it converts 2.x "str" to 3.x "str", as it should. If
> you're writing 2.x WSGI code with 'u' literals, *your code is broken*.
>
> WSGI doesn't need 'u' literals and never has. It *does* need b'' literals
> for stuff that refers to request and response bodies, but everything else
> should be plain old string literals for the appropriate Python version.
The reason it came up is that the reason "from __future__ import
unicode_literals" doesn't obviously help with doing single codebase
style ports for a lot of WSGI related code is because such code
actually has *3* string types to deal with:
Actual text (u'', unicode -> str)
Native strings for WSGI ('', str -> str)
Binary data (b'', str -> bytes)
That works fine with 2to3, since 2to3 will strip out the leading 'u'
from the actual text literals, but presents a potential hassle for the
single codebase approach. Most other contexts only need the
binary->binary and text->text conversion, so the future import really
helps out.
However, I just realised that there actually *is* a relatively clear
way to spell this for all 2.6+ versions: the future import *doesn't*
change the meaning of the 'str' builtin (it's still the 8-bit string
type in 2.x), so the native way to spell the above distinction when
"from __future__ import unicode_literals" is in effect is as follows:
Actual text: ''
Native strings for WSGI: str('')
Binary data: b''
Calling a builtin is much lower overhead than calling a helper from a
compatibility module, and this also makes it clear that native strings
are the odd ones out.
So I'm back to being -1 on the idea of adding back u'' literals for
3.3. Instead, people should explicitly call str() on any literals that
they want to be actual str instances both in 3.x and in 2.x when the
unicode literals future import is in effect.
Cheers,
Nick.
--
Nick Coghlan | [email protected] | Brisbane, Australia
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fixing the XML batteries
Bill Janssen, 09.12.2011 19:15: I think another thing that might go into "refreshing the batteries" is a feature comparison of BeautifulSoup and HTML5lib against the stdlib competition, to see what needs to be added/revised. Having to switch to an outside package for parsing possibly invalid HTML is a pain. Such a feature request should be worth a separate thread. Note, however, that html5lib is likely way too big to add it to the stdlib, and that BeautifulSoup lacks a parser for non-conforming HTML in Python 3, which would be the target release series for better HTML support. So, whatever library or API you would want to use for HTML processing is currently only the second question as long as Py3 lacks a real-world HTML parser in the stdlib, as well as a robust character detection mechanism. I don't think that can be fixed all that easily. Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
