Josiah Carlson wrote:
> Fredrik Lundh <[EMAIL PROTECTED]> wrote:
>> Josiah Carlson wrote:
>>
>>> Presumably with this library you have created, you have also written a
>>> fast object encoder/decoder (like marshal or pickle). If it isn't any
>>> faster than cPickle or marshal, then users may bypas
Ronald Oussoren wrote:
> Patch http://www.python.org/sf/1580674 fixes readlink's behaviour w.r.t.
> Unicode strings: without this patch this function uses the system
> default encoding instead of the filesystem encoding to convert Unicode
> objects to plain strings. Like os.listdir, os.readlink wil
Mike Krell wrote:
>> class S(str):
>> def __str__(self): return "S.__str__"
>>
>> class U(unicode):
>> def __str__(self): return "U.__str__"
>>
>> print str(S())
>> print str(U())
>>
>> This script prints:
>>
>> S.__str__
>> U.__str__
>
> Yes, but "print U()" prints nothing, and the explic
Travis E. Oliphant wrote:
>
>
>
>
> PEP:
> Title: Adding data-type objects to the standard library
> Attributes
>
> kind -- returns the basic "kind" of the data-type. The basic kinds
> ar
Travis E. Oliphant wrote:
> M.-A. Lemburg wrote:
>> Travis E. Oliphant wrote:
>>>
>>>
>>> PEP:
>>> Title: Adding data-type objects to the standard library
>>> Attribu
Travis E. Oliphant wrote:
> M.-A. Lemburg wrote:
>> Travis E. Oliphant wrote:
>>> M.-A. Lemburg wrote:
>>>> Travis E. Oliphant wrote:
>>>>>
>>>>>
>>>&
On 2006-12-06 10:26, Fredrik Lundh wrote:
> over at my work copy of the python language reference, Adrian Holovaty
> asked about the exact semantics of the __str__ hook:
>
> http://effbot.org/pyref/__str__
>
>"The return value must be a string object." Does this mean it can be a
>*Uni
On 2006-12-06 10:46, M.-A. Lemburg wrote:
> On 2006-12-06 10:26, Fredrik Lundh wrote:
>> over at my work copy of the python language reference, Adrian Holovaty
>> asked about the exact semantics of the __str__ hook:
>>
>> http://effbot.org/pyref/__str__
>>
On 2006-12-06 10:56, Fredrik Lundh wrote:
> M.-A. Lemburg wrote:
>
>> This was added to make the transition to all Unicode in 3k easier:
>
> thanks for the clarification.
>
> do you recall when this was added? 2.5?
Not really, only that it was definitely before 2.5.
On 2007-01-02 01:02, brett.cannon wrote:
> Author: brett.cannon
> Date: Tue Jan 2 01:02:41 2007
> New Revision: 53204
>
> Added:
>peps/trunk/pep-3108.txt (contents, props changed)
> Modified:
>peps/trunk/pep-.txt
> Log:
> Add PEP 3108: Standard Library Reorganization.
>
>...
>
> +O
On 2007-01-02 23:54, Brett Cannon wrote:
> On 1/2/07, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>>
>> On 2007-01-02 01:02, brett.cannon wrote:
>> > Author: brett.cannon
>> > Date: Tue Jan 2 01:02:41 2007
>> > New Revision: 53204
>> >
>&
On 2007-01-03 00:35, Barry Warsaw wrote:
> On Jan 2, 2007, at 5:41 PM, M.-A. Lemburg wrote:
>
>> Note that as side-effect of this it becomes a lot harder to manipulate
>> PYTHONPATH to trick Python into loading a standard module from a
>> non-standard location, improving
On 2007-01-03 01:42, Brett Cannon wrote:
> On 1/2/07, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> >> > +Open Issues
>> >> > +===
>> >> > +
>> >> > +Consolidate dependent modules together into a single module or
>>
On 2007-01-04 07:59, Neal Norwitz wrote:
> The current schedule looks like it's shaping up to be:
>
> Wed, Jan 24 for 2.5.1c1
> Wed Jan 31 for 2.5.1
>
> It would be great if you could comment on some of the bug reports
> below. I think several already have patches/suggested fixes.
>
> It's not
On 2007-01-18 20:53, Brett Cannon wrote:
> I have discovered an issue relating to func_globals for functions and
> the deallocation of the module it is contained within. Let's say you
> store a reference to the function encodings.search_function from the
> 'encodings' module (this came up in C cod
On 2007-01-19 22:33, Brett Cannon wrote:
>> That's a typical error situation you get in __del__ methods at
>> the time the interpreter is shut down.
>>
>
> Yeah, but in this case this is at the end of Py_Initialize() for the
> stuff I am doing to the interpreter. =)
Is that in some error branch
On 2007-01-20 00:01, Brett Cannon wrote:
> On 1/19/07, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> On 2007-01-19 22:33, Brett Cannon wrote:
>>>> That's a typical error situation you get in __del__ methods at
>>>> the time the interpreter is shut down.
&g
On 2007-02-12 16:19, Georg Brandl wrote:
>> Tim Delaney asked in particular:
>>> Have you checked if [the existing uses of getattr, where "getattr" in
>>> that scope is a function argument with default value the built-in
>>> "getattr"] are intended to bring the "getattr" name into local scope
>>> f
Hi Skip,
On 2007-03-12 03:01, [EMAIL PROTECTED] wrote:
> I decided it would be worthwhile to have a csv module written in Python (no
> C underpinnings) for a number of reasons:
>
> * It will probably be easier to add Unicode support to a Python version
>
> * More people will be able to r
On 2007-03-15 07:45, Martin v. Löwis wrote:
> Phillip J. Eby schrieb:
>> And yet, that "incorrect" behavior was clearly intended by the author(s)
>> of the code, test, and docstrings.
>>
>> As it happens, Guido wrote that code (16 years ago) and the docstring (9
>> years ago), in the case of the
On 2007-03-23 19:18, Jason Orendorff wrote:
> Scheme is adding Unicode support in an upcoming standard:
> (DRAFT) http://www.r6rs.org/document/lib-html/r6rs-lib-Z-H-3.html
>
> I have two questions for the python-dev team about Python's Unicode
> experiences. If it's convenient, please take a mome
Hi Walter,
if the bytes type does turn out to be a mutable type as suggested
in PEP 358, then please make sure that no code (C code in
particular), relies on the constantness of these byte objects.
This is especially important when it comes to codecs, since
the error callback logic would allow th
On 2007-05-01 02:29, Phillip J. Eby wrote:
> I wanted to get this in before the Py3K PEP deadline, since this is a
> Python 2.6 PEP that would presumably impact 3.x as well. Feedback welcome.
Could you add a section that explains the side effects of
importing pkg_resources ?
The documentation o
On 2007-05-04 18:53, Georg Brandl wrote:
> M.-A. Lemburg schrieb:
>> Hi Walter,
>>
>> if the bytes type does turn out to be a mutable type as suggested
>> in PEP 358, then please make sure that no code (C code in
>> particular), relies on the constantness of
On 2007-05-04 19:51, Guido van Rossum wrote:
> [-python-dev]
>
> On 5/4/07, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
>> On Friday 04 May 2007, M.-A. Lemburg wrote:
>> > I also suggest making all bytes literals immutable to avoid running
>> > into any
On 2007-05-05 18:11, Steven Bethard wrote:
> On 5/5/07, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> On 2007-05-04 19:51, Guido van Rossum wrote:
>> > [-python-dev]
>> >
>> > On 5/4/07, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
>> >>
On 2007-05-10 20:53, Paul Moore wrote:
> On 10/05/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> I just discovered that, in all versions of Python as far back as I
>> have access to (2.0), \u escapes are interpreted inside raw
>> unicode strings. Thus:
> [...]
>> Does anyone remember why it
On 2007-05-11 00:11, Guido van Rossum wrote:
> On 5/10/07, M.-A. Lemburg <[EMAIL PROTECTED]> wrote:
>> On 2007-05-10 20:53, Paul Moore wrote:
>>> On 10/05/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>>>> I just discovered that, in all versions of P
On 2007-05-11 07:52, Martin v. Löwis wrote:
>> This is what prompted my question, actually: in Py3k, in the
>> str/unicode unification branch, r"\u1234" changes meaning: before the
>> unification, this was an 8-bit string, where the \u was not special,
>> but now it is a unicode string, where \u *i
On 2007-05-11 13:05, Thomas Heller wrote:
> M.-A. Lemburg schrieb:
>> On 2007-05-11 07:52, Martin v. Löwis wrote:
>>>> This is what prompted my question, actually: in Py3k, in the
>>>> str/unicode unification branch, r"\u1234" changes meaning: before the
On 2007-05-12 00:48, Martin v. Löwis wrote:
>> Using double backslashes won't cause that reaction:
>>
>> os.stat("c:\\windows\\system32\\user32.dll")
>
> Please refer to the subject. We are talking about raw strings.
If you'd leave the context in place, the reason for my suggestion
would become e
On 2007-05-12 02:42, Andrew McNabb wrote:
> On Sat, May 12, 2007 at 01:30:52AM +0200, M.-A. Lemburg wrote:
>> I wonder how we managed to survive all these years with
>> the existing consistent and concise definition of the
>> raw-unicode-escape codec ;-)
>>
>> T
On 2007-05-13 18:04, Martin v. Löwis wrote:
>> * without the Unicode escapes, the only way to put non-ASCII
>> code points into a raw Unicode string is via a source code encoding
>> of say UTF-8 or UTF-16, pretty much defeating the original
>> requirement of writing ASCII code only
>
> That'
Alexander Belopolsky wrote:
> On Thu, Dec 2, 2010 at 5:58 PM, M.-A. Lemburg wrote:
> ..
>>> I will change my mind on this issue when you present a
>>> machine-readable file with Arabic-Indic numerals and a program capable
>>> of reading it and show that this pro
Guido van Rossum wrote:
> On Fri, Dec 3, 2010 at 9:58 AM, R. David Murray wrote:
>> On Fri, 03 Dec 2010 11:14:56 -0500, Alexander Belopolsky
>> wrote:
>>> On Fri, Dec 3, 2010 at 10:11 AM, R. David Murray
>>> wrote:
>>> ..
Please also recall that transform/untransform was discussed before
Alexander Belopolsky wrote:
> On Fri, Dec 3, 2010 at 1:05 PM, Guido van Rossum wrote:
>> On Fri, Dec 3, 2010 at 9:58 AM, R. David Murray
>> wrote:
> ..
>>> I believe MAL's thought was that the addition of these methods had
>>> been approved pre-moratorium, but I don't know if that is a
>>> suff
Michael Foord wrote:
> On 09/12/2010 15:03, M.-A. Lemburg wrote:
>> Alexander Belopolsky wrote:
>>> On Fri, Dec 3, 2010 at 1:05 PM, Guido van Rossum
>>> wrote:
>>>> On Fri, Dec 3, 2010 at 9:58 AM, R. David
>>>> Murray wrote:
>>> ..
Alexander Belopolsky wrote:
> On Thu, Dec 9, 2010 at 10:03 AM, M.-A. Lemburg wrote:
>> Alexander Belopolsky wrote:
> ..
>>> The ticket that introduced the change is
>>> currently closed [3] even though the last message suggests that at
>>> least
Michael Foord wrote:
> On 03/01/2011 15:39, Alexander Belopolsky wrote:
>> On Mon, Jan 3, 2011 at 10:33 AM, Michael
>> Foord wrote:
>> ..
>>> If someone knows if this tool is still used/useful then please let us
>>> know
>>> how the description should best be updated. If there are no replies I'll
brett.cannon wrote:
> Author: brett.cannon
> Date: Thu Jan 20 20:34:35 2011
> New Revision: 88127
>
> Log:
> Remove some outdated files from Misc.
>
> Removed:
>python/branches/py3k/Misc/README.AIX
Are you sure that the AIX README is outdated ? It explains some
of the details of why there ar
I'll comment more on this later this week...
>From my first impression, I'm
not too thrilled by the prospect of making the Unicode implementation
more complicated by having three different representations on each
object.
I also don't see how this could save a lot of memory. As an example
take a F
Wesley Mesquita wrote:
> Hi all,
>
> I starting to explore python 3k core development environment. So, sorry in
> advance for any mistakes, but I really don't know what is the best list to
> post this, since it not a "use of python" issue, and probably is not a dev
> issue, it is more like a "dev
Mark Shannon wrote:
> The Unicode Exception Objects section is new and seemingly redundant:
> http://docs.python.org/py3k/c-api/exceptions.html#unicode-exception-objects
> Should this be in the public API?
Those function have been in the public API since we introduced
Unicode callbak error handler
Mark Shannon wrote:
> Nick Coghlan wrote:
>> On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon
>> wrote:
>>> Doing a search for the regex: "PyAPI_FUNC\([^)]*\) *Py" in .h files,
>>> which should match API functions (functions starting _Py are
>>> excluded) gives
>>> the following result:
>>>
>>> Vers
Mark Shannon wrote:
> M.-A. Lemburg wrote:
>> Mark Shannon wrote:
>>> Nick Coghlan wrote:
>>>> On Thu, Feb 10, 2011 at 8:16 PM, Mark Shannon
>>>> wrote:
>>>>> Doing a search for the regex: "PyAPI_FUNC\([^)]*\) *Py" in .h files,
Alexander Belopolsky wrote:
> On Wed, Feb 23, 2011 at 4:07 PM, Guido van Rossum wrote:
>> I'm guessing that one of these encoding names is recognized by the C
>> code while the other one takes the slow path via the aliasing code.
>
> This is absolutely right. In fact I am going to propose adding
Alexander Belopolsky wrote:
> On Wed, Feb 23, 2011 at 4:23 PM, M.-A. Lemburg wrote:
> ..
>> "Latin-1" is the official name and the one used internally by Python,
>> so it would be good to have the test suite and Python code in general
>> to use that varia
Alexander Belopolsky wrote:
> On Wed, Feb 23, 2011 at 4:54 PM, M.-A. Lemburg wrote:
> ..
>> Yet 108 for the correct name, so I can't follow your statement
>> that the wrong variant is used more often.
>
> Hmm, your grepping skills are probably better than mine. I g
Alexander Belopolsky wrote:
> On Wed, Feb 23, 2011 at 4:23 PM, M.-A. Lemburg wrote:
> ..
>> "Latin-1" is the official name and the one used internally by Python,
>
> In what sense is "Latin-1" the official name? The IANA charset
> registry has the follow
Alexander Belopolsky wrote:
> On Wed, Feb 23, 2011 at 6:32 PM, M.-A. Lemburg wrote:
>> Alexander Belopolsky wrote:
> ..
>>> In what sense is "Latin-1" the official name? The IANA charset
>>> registry has the following l
Sümer Cip wrote:
> Hi,
>
> While porting a C extension from 2 to 3, I realized that there are some
> general cases which can be automated. For example, for my specific
> application (yappi - http://code.google.com/p/yappi/), all I need to do is
> following things:
>
> 1) define PyModuleDef
> 2) c
Nadeem Vawda wrote:
> I was wondering what the policy is regarding copyright notices and license
> boilerplate text at the top of source files.
>
> I am currently rewriting the bz2 module (see
> http://bugs.python.org/issue5863),
> splitting the existing Modules/bz2module.c into Modules/_bz2modul
Victor Stinner wrote:
> Hi,
>
> I plan to replace all %.100s (or any other size, %\.[0-9]+s regex) by %s
> in the whole source code, in all calls to PyErr_Format(). And I would
> like your opinion.
>
> When Guido added the function PyErr_Format(), 13 years ago, the function
> was implemented usin
Victor Stinner wrote:
> Le jeudi 24 mars 2011 à 13:22 +0100, M.-A. Lemburg a écrit :
>> BTW: Why do you think that %.100s is not supported in
>> PyErr_Format() in Python 2.x ? PyString_FromFormatV()
>> does support this. The change to use Unicode error strings
>> in
Victor Stinner wrote:
> Hi,
>
> I asked one year ago if we should drop OS/2 support: Andrew MacIntyre,
> our OS/2 maintainer, answered:
> http://mail.python.org/pipermail/python-dev/2010-April/099477.html
>
> Extract: << The 3.x branch needs quite a bit of work on OS/2 to
> deal with Unicode, as
Doug Hellmann wrote:
>
> On Apr 19, 2011, at 10:36 AM, M.-A. Lemburg wrote:
>
>> Victor Stinner wrote:
>>> Hi,
>>>
>>> I asked one year ago if we should drop OS/2 support: Andrew MacIntyre,
>>> our OS/2 maintainer, answered:
>>> http:/
Stefan Behnel wrote:
> DasIch, 28.04.2011 20:55:
>> the CPython
>> benchmarks have an extensive set of microbenchmarks in the pybench
>> package
>
> Try not to care too much about pybench. There is some value in it, but
> some of its microbenchmarks are also tied to CPython's interpreter
> behavio
Mark Shannon wrote:
> Maciej Fijalkowski wrote:
>> On Thu, Apr 28, 2011 at 11:10 PM, Stefan Behnel
>> wrote:
>>> M.-A. Lemburg, 28.04.2011 22:23:
>>>> Stefan Behnel wrote:
>>>>> DasIch, 28.04.2011 20:55:
>>>>>> the CPython
>
DasIch wrote:
> Given those facts I think including pybench is a mistake. It does not
> allow for a fair or meaningful comparison between implementations
> which is one of the things the suite is supposed to be used for in the
> future.
>
> This easily leads to misinterpretation of the results fro
Sijin Joseph wrote:
> Hi - I am working on a patch where I have an argument that can either be a
> unicode string or binary data, I parse the argument using the
> PyArg_ParseTuple method using the s* format specification and get a
> Py_Buffer.
>
> I now need to convert this Py_Buffer object to a P
Raymond Hettinger wrote:
>
> On May 5, 2011, at 11:41 AM, Benjamin Peterson wrote:
>
>> 2011/5/5 raymond.hettinger :
>>> http://hg.python.org/cpython/rev/1a56775c6e54
>>> changeset: 69857:1a56775c6e54
>>> branch: 3.2
>>> parent: 69855:97a4855202b8
>>> user:Raymond Hettinger
>
Victor Stinner wrote:
> Hi,
>
> In Python 2, codecs.open() is the best way to read and/or write files
> using Unicode. But in Python 3, open() is preferred with its fast io
> module. I would like to deprecate codecs.open() because it can be
> replaced by open() and io.TextIOWrapper. I would like y
Victor Stinner wrote:
> Le mardi 24 mai 2011 à 10:03 +0200, M.-A. Lemburg a écrit :
>> Please read PEP 100 regarding StreamReader and StreamWriter.
>> Those codecs parts were explicitly designed to be stateful,
>> unlike the stateless encoder/decoder methods.
>
> Yes,
Walter Dörwald wrote:
> On 24.05.11 12:58, Victor Stinner wrote:
>> Le mardi 24 mai 2011 à 12:42 +0200, Łukasz Langa a écrit :
>>> Wiadomość napisana przez Walter Dörwald w dniu 2011-05-24, o godz. 12:16:
>>>
> I don't see which usecase is not covered by TextIOWrapper. But I know
> some cas
Victor Stinner wrote:
> Le mercredi 25 mai 2011 à 11:38 +0200, M.-A. Lemburg a écrit :
>> You are missing the point: we have StreamReader and StreamWriter APIs
>> on codecs to allow each codecs to implement more efficient ways of
>> encoding and decoding streams.
&
Victor Stinner wrote:
> Le mercredi 25 mai 2011 à 15:43 +0200, M.-A. Lemburg a écrit :
>> For UTF-16 it would e.g. make sense to always read data in blocks
>> with even sizes, removing the trial-and-error decoding and extra
>> buffering currently done by the base classes. For
Victor Stinner wrote:
> Le vendredi 27 mai 2011 10:17:29, M.-A. Lemburg a écrit :
>> I am still -1 on deprecating the StreamReader/Writer parts of
>> the codec APIs. I've given numerous reasons on why these are
>> useful, what their intention is, why they were added to Py
Victor Stinner wrote:
> Le vendredi 27 mai 2011 15:42:10, M.-A. Lemburg a écrit :
>> If we'd go by your reasoning for deprecating and eventually
>> removing parts of the stdlib or Python's subsystems, we'll end
>> up with a barebone version of Python. That
Georg Brandl wrote:
> On 06/07/11 05:20, brett.cannon wrote:
>> http://hg.python.org/cpython/rev/fc282e375703
>> changeset: 70695:fc282e375703
>> user:Brett Cannon
>> date:Mon Jun 06 20:20:36 2011 -0700
>> summary:
>> Remove some extraneous parentheses and swap the comparison o
Dear Python Developers,
for the upcoming language summit at EuroPython, I'd like to
try out whether streaming such meetings would work. I'll setup
a webcam and stream the event live to a private channel on ustream.tv.
These are the details in case you want to watch:
URL: http://www.ustream.tv/ch
Victor Stinner wrote:
> In Python 2, open() opens the file in binary mode (e.g. file.readline()
> returns a byte string). codecs.open() opens the file in binary mode by
> default, you have to specify an encoding name to open it in text mode.
>
> In Python 3, open() opens the file in text mode by d
Victor Stinner wrote:
> Le mardi 28 juin 2011 à 16:02 +0200, M.-A. Lemburg a écrit :
>> How about a more radical change: have open() in Py3 default to
>> opening the file in binary mode, if no encoding is given (even
>> if the mode doesn't include 'b') ?
>
Victor Stinner wrote:
> Le mercredi 29 juin 2011 à 10:18 +0200, M.-A. Lemburg a écrit :
>> Victor Stinner wrote:
>>> Le mardi 28 juin 2011 à 16:02 +0200, M.-A. Lemburg a écrit :
>>>> How about a more radical change: have open() in Py3 default to
>>>> openi
Victor Stinner wrote:
> Hi,
>
> Last may, I proposed to deprecate open() function, StreamWriter and
> StreamReader classes of the codecs module. I accepted to keep open()
> after the discussion on python-dev. Here is a more complete proposition
> as a PEP. It is a draft and I expect a lot of comme
Victor Stinner wrote:
> Hi,
>
> Three weeks ago, I posted a draft on my PEP on this mailing list. I
> tried to include all remarks you made, and the PEP is now online:
>
>http://www.python.org/dev/peps/pep-0400/
>
> It's now unclear to me if the PEP will be accepted or rejected. I don't
> kn
Victor Stinner wrote:
> Le 28/07/2011 11:28, Victor Stinner a écrit :
>>> Please do keep the original implementation
>>> around (e.g. renamed to codecs.open_stream()), though, so that it's
>>> still possible to get easy-to-use access to codec StreamReader/Writers.
>>
>> I will add your alternative
On 2007-05-21 12:30, Kristján Valur Jónsson wrote:
>>
>> [Py_UNICODE being #defined as "unsigned short" on Windows]
>>
>> I'd rather make it a platform-specific definition (for platform=Windows
>> API). Correct me if I'm wrong, but isn't wchar_t also available in VS
>> 2003 (and even in VC6?). And
On 2007-05-21 00:07, Talin wrote:
> Phillip J. Eby wrote:
>> I wanted to get this in before the Py3K PEP deadline, since this is a
>> Python 2.6 PEP that would presumably impact 3.x as well. Feedback welcome.
>>
>>
>> PEP: 365
>> Title: Adding the pkg_resources module
>
> I'm really surprised th
On 2007-05-21 16:05, Phillip J. Eby wrote:
> At 01:43 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
>> On 2007-05-21 00:07, Talin wrote:
>>> Phillip J. Eby wrote:
>>>> I wanted to get this in before the Py3K PEP deadline, since this is a
>>>> Python 2.6 PEP th
On 2007-05-21 20:01, Phillip J. Eby wrote:
> At 06:28 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
>> However, since this is not egg-specific it should probably be
>> moved to pkgutil and get a separate PEP with detailed documentation
>> (the link you provided doesn't r
On 2007-05-21 22:48, Phillip J. Eby wrote:
> At 08:56 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
>> On 2007-05-21 20:01, Phillip J. Eby wrote:
>> > At 06:28 PM 5/21/2007 +0200, M.-A. Lemburg wrote:
>> >> However, since this is not egg-specific it should probably be
&g
Hi Mark,
>> +1 from me.
>>
>> I think this is simply a bug introduced with the UCS4 patches in
>> Python 2.2.
>>
>> unicodeobject.h already has this code:
>>
>> #ifndef PY_UNICODE_TYPE
>>
>> /* Windows has a usable wchar_t type (unless we're using UCS-4) */
>> # if defined(MS_WIN32) && Py_UNICODE_
On 2007-06-19 14:40, Walter Dörwald wrote:
> Georg Brandl wrote:
A minuscule nit: the rot13 codec has no library equivalent, so it won't be
supported anymore :)
>>> Given that there are valid use cases for bytes-to-bytes translations,
>>> and a common API for them would be nice, does it
Nick Maclaren wrote:
>> Ah, the makefile. I don't think you use it create the Unicode database.
>>
>> It's only good for generating the codecs (Lib/encodings)
>
> Yes, but it DOES attempt to download the mappings, and is the ONLY
> script which attempts to do so.
Of course it does. The Tools/unic
On 2007-10-26 05:41, Barry Warsaw wrote:
> On Oct 22, 2007, at 11:30 PM, [EMAIL PROTECTED] wrote:
>
>> It's not clear that any of these implementations is going to be
>> perfect.
>> Maybe none ever will be.
>
> I would agree with this. You write a program and know you need to
> implement som
On 2007-11-09 14:10, Walter Dörwald wrote:
> Martin v. Löwis wrote:
Yes, an XML parser should be able to use UTF-8, UTF-16, UTF-32, etc
codecs to do the encoding. There's no need to create a magical
mystery codec to pick out which though.
>>> So the code is good, if it is inside an
Martin v. Löwis wrote:
>> It makes working with XML data a lot easier: you simply don't have to
>> bother with the encoding of the XML data anymore and can just let the
>> codec figure out the details. The XML parser can then work directly
>> on the Unicode data.
>
> Having the functionality indee
Martin v. Löwis wrote:
>> Not really, but the codec has more control over what happens to
>> the stream, ie. it's easier to implement look-ahead in the codec
>> than to do the detection and then try to push the bytes back onto
>> the stream (which may or may not be possible depending on the
>> natu
On 2007-11-10 09:54, Martin v. Löwis wrote:
>> A non-seekable stream is not all that uncommon in network processing.
>
> Right. But what is the relationship to XML encoding autodetection?
It pops up whenever you need to detect the encoding of the
incoming XML data on the network connection, e.g.
On 2007-11-11 14:51, Martin v. Löwis wrote:
A non-seekable stream is not all that uncommon in network processing.
>>> Right. But what is the relationship to XML encoding autodetection?
>> It pops up whenever you need to detect the encoding of the
>> incoming XML data on the network connection,
On 2007-11-11 18:56, Martin v. Löwis wrote:
>> First, XML-RPC is not the only mechanism using XML over a network
>> connection. Second, you don't want to do this if you're dealing
>> with several 100 MB of data just because you want to figure
>> out the encoding.
>
> That's my original claim/quest
On 2007-11-11 23:22, Martin v. Löwis wrote:
First, XML-RPC is not the only mechanism using XML over a network
connection. Second, you don't want to do this if you're dealing
with several 100 MB of data just because you want to figure
out the encoding.
>>> That's my original clai
On 2007-11-23 18:40, Christian Heimes wrote:
> M.-A. Lemburg wrote:
>> Why not include the prebuilt libraries of all external libs in SVN
>> as well ?
>
> For one I'm still using Beta 2 of the standard edition and I'm not
> allowed to distribute binaries build
On 2007-11-23 16:59, Christian Heimes wrote:
> Paul Moore wrote:
>> _ssl
>>
>>
>> Christian has been making changes to allow this to build without Perl,
>> so I gave it a try. I used openssl 0.9.8g, which I extracted to the
>> build directory (I noticed afterwards that this is the same version
On 2007-11-23 23:12, Paul Moore wrote:
> On 23/11/2007, Christian Heimes <[EMAIL PROTECTED]> wrote:
>> bsddb is automatically build by a build step. But you have to convert
>> the project files in build_win32 to VS 2008 first. Simply open the
>> solution file and let VS convert the projects.
>
> V
On 2007-11-29 11:52, Titus Brown wrote:
> Hi all,
>
> is there a good, or standard memory benchmarking system for Python?
> pybench doesn't return significantly different results when Python 2.6
> is compiled with pymalloc and without pymalloc. Thinking on it, I'm not
> too surprised -- pybench p
On 2008-01-06 16:33, Christian Heimes wrote:
> Hello!
>
> We are discussing name space packages on the stdlib reorg list. For
> Python 3.0 we plan to organize the packages by purpose, e.g. put all
> database related packages like sqlite and shelve in a 'databases' name
> space.
Regardless of whet
On 2008-01-07 14:57, Fred Drake wrote:
> On Jan 7, 2008, at 7:48 AM, M.-A. Lemburg wrote:
>> Next, we add a per-user site-packages directory to the standard
>> sys.path, and then we could get rid of most of the setuptools
>> import and sys.path hackery, making it a lot cleane
On 2008-01-07 17:24, Barry Warsaw wrote:
> On Jan 7, 2008, at 10:12 AM, Guido van Rossum wrote:
>
>> On Jan 7, 2008 6:32 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>>> On Jan 7, 2008, at 9:01 AM, M.-A. Lemburg wrote:
>>>> We could easily resolve that is
On 2008-01-10 14:31, Eric Smith wrote:
> (I'm posting to python-dev, because this isn't strictly 3.0 related.
> Hopefully most people read it in addition to python-3000).
>
> I'm working on backporting the changes I made for PEP 3101 (Advanced
> String Formatting) to the trunk, in order to meet th
501 - 600 of 1090 matches
Mail list logo
