Martin,
You seem heavily invested in minidom.
In the near future I will need to parse and rewrite parts of an xml file
created by a third-party program (PrintShopMail, for the curious).
It contains both binary and textual data.
Would you recommend minidom for this purpose? What other purpose
On Sun, Dec 11, 2011 at 2:36 PM, MRAB wrote:
> On 11/12/2011 21:04, Guido van Rossum wrote:
>>
>> On Sun, Dec 11, 2011 at 12:47 PM, MRAB wrote:
>>>
>>> On 11/12/2011 20:27, Guido van Rossum wrote:
On Sun, Dec 11, 2011 at 12:12 PM, MRAB
wrote:
>
>
> I've just come a
Le vendredi 9 décembre 2011 20:32:16 Antoine Pitrou a écrit :
> ... it's a bit obscure why the function exists.
Yeah ok, I marked the function as private: renamed to _PyUnicode_Copy() and I
undocumented it.
Victor
___
Python-Dev mailing list
Python-Dev
> 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.
Are you talking about general porting, or about Twisted?
It is a common misconception that "drop everything prior to 2
>> 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
> 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 you run "build" repeatedly (e.g. in a development cycle), then
it will process only the modified files (comparing time stamps
Am 09.12.2011 11:17, schrieb Nick Coghlan:
> 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.
>
>
Le dimanche 11 décembre 2011 à 23:44 +0100, "Martin v. Löwis" a écrit :
> Am 09.12.2011 20:32, schrieb Antoine Pitrou:
> > 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 wro
On 2011-12-11, at 23:03 , Martin v. Löwis wrote:
> People are still using PyXML, despite it's not being maintained anymore.
> Telling them to replace 4DOM with minidom is much more appropriate than
> telling them to rewrite in ET.
>From my understanding, Stefan's suggestion is mostly aimed at "new
Am 09.12.2011 20:32, schrieb Antoine Pitrou:
> 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)
+
>>
On Sat, 10 Dec 2011 20:40:17 +0100
lars.gustaebel wrote:
>
> The :mod:`tarfile` module makes it possible to read and write tar
> -archives, including those using gzip or bz2 compression.
> +archives, including those using gzip, bz2 and lzma compression.
> (:file:`.zip` files can be read and wr
> 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.
What do you think is the reason? It's not at all obvious to me.
Regards,
Martin
___
Python-Dev mailing list
P
Am 09.12.2011 16:09, schrieb Dirkjan Ochtman:
> 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
On 11/12/2011 21:04, Guido van Rossum wrote:
On Sun, Dec 11, 2011 at 12:47 PM, MRAB wrote:
On 11/12/2011 20:27, Guido van Rossum wrote:
On Sun, Dec 11, 2011 at 12:12 PM, MRAB
wrote:
I've just come across an omission in re.sub which I hadn't noticed
before.
In re.sub the replacement string
Am 09.12.2011 10:12, schrieb Nick Coghlan:
> 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)
+
> 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 wouldn't mind such a wording. I still would mind the changes that
Stefan proposed (whic
Am 09.12.2011 10:09, schrieb Xavier Morel:
> 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
I guess the current rule is that any escapes referring to characters
by a numeric value are not supported; this probably made some kind of
sense because \1 etc. are backreferences. But since we're discouraging
octal escapes anyway I think it's fine to improve over this.
On Sun, Dec 11, 2011 at 12:
On 11/12/2011 20:27, Guido van Rossum wrote:
On Sun, Dec 11, 2011 at 12:12 PM, MRAB
wrote:
I've just come across an omission in re.sub which I hadn't noticed
before.
In re.sub the replacement string can contain escape sequences, for
example:
repr(re.sub(r"x", r"\n", "axb"))
"'a\\nb'"
Howeve
As long as there's a way to place a single backslash in the output
this seems fine to me, though I'm not sure it's important. Of course
it will likely break some test... the test will then have to be fixed.
I can't remember why we did this -- is there a full list of all the
escapes that re.sub() i
On Sat, Dec 10, 2011 at 5:30 PM, Terry Reedy wrote:
> Is doctest really insisting that the whole line
> Traceback (most recent call last):
> exactly match, with nothing added? It really should not, as that is not
> part of the language spec. This seems like the tail wagging the dog.
>
It's a re
I've just come across an omission in re.sub which I hadn't noticed
before.
In re.sub the replacement string can contain escape sequences, for
example:
>>> repr(re.sub(r"x", r"\n", "axb"))
"'a\\nb'"
However:
>>> repr(re.sub(r"x", r"\x0A", "axb"))
"'ax0Ab'"
Yes, it doesn't recognise "\xNN".
22 matches
Mail list logo
