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 HTM
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
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
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 fas
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
__
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
> agreei
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
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/pyt
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 syn
Point of order (repeated), please move this thread to python-ideas.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailma
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 pr
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 produ
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
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]man...@gmx.net> 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
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.
>
Eve
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 a
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.
> py
This belongs on python-ideas. Please take it there.
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
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.
Tha
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.
>
> > For
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
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 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,
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
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,
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.
>
> Otherw
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 discu
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
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.
> >> +
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
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:
misssin
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 im
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
Python-Dev@python.org
http://mail.python.
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
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
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 accel
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
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
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 wit
+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
>> librar
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 tim
-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.
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 (u
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 -
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 moc
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
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 does
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
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 proble
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
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
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
> m
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 sup
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
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 effecti
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. Th
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 di
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
Python-Dev@python.
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 sen
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 "
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. Tha
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
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.
>>> +
>>> +
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 a
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
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 an
"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
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
> 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
> 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
> 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
> 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 do
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
n
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
73 matches
Mail list logo
