Michael Bayer wrote:
[...]
It will be critical that we get DBAPI implementations going soon, other
than pysqlite I haven't perceived any activity in that area. It will
be interesting to see if we remain with the maintsays of MySQLdb,
psycopg2, cx_oracle, or if new 3.0-era contenders come on
Walter Dörwald wrote:
[...]
Sure, we could do that, but please use a different name,
e.g. .encodeall() and .decodeall() - .encode() and .decode()
are already stateles (and so would the new methods be), so
"stateless" isn't all that meaningful in this context.
I like the
M.-A. Lemburg wrote:
On 2008-06-13 11:32, Walter Dörwald wrote:
M.-A. Lemburg wrote:
On 2008-06-12 16:59, Walter Dörwald wrote:
M.-A. Lemburg wrote:
.transform() and .untransform() use the codecs to apply same-type
conversions. They do apply type checks to make sure that the
codec does
M.-A. Lemburg wrote:
On 2008-06-12 16:59, Walter Dörwald wrote:
M.-A. Lemburg wrote:
.transform() and .untransform() use the codecs to apply same-type
conversions. They do apply type checks to make sure that the
codec does indeed return the same type.
E.g. text.transform('xml-escape
M.-A. Lemburg wrote:
On 2008-06-11 17:15, Walter Dörwald wrote:
M.-A. Lemburg wrote:
On 2008-06-11 13:35, Barry Warsaw wrote:
So I had planned to do a bunch of work last night looking at the
release blocker issues, but nature intervened. A bunch of severe
thunderstorms knock out my
M.-A. Lemburg wrote:
On 2008-06-11 13:35, Barry Warsaw wrote:
So I had planned to do a bunch of work last night looking at the
release blocker issues, but nature intervened. A bunch of severe
thunderstorms knock out my 'net access until this morning.
I'll try to find some time during the day
Christian Heimes wrote:
> Barry Warsaw schrieb:
>> I proposed what I think is a better solution. Add
>>
>> from __future__ import unicode_strings
>>
>> to Py2.6. That would let you write Py3k compatible strings (and of
>> course byte literals) in 2.6. It would essential treat 'foo' as
>> u'f
Amaury Forgeot d'Arc wrote:
> Guido van Rossum:
>> I just changed PEP 3137 to rename the mutable bytes type 'bytearray'
>> instead of 'buffer', and implemented this change in the py3k branch.
>>
>> A lot of code in the Py3k branch still returns PyBytes instances
>> (i.e., bytearray) where it should
Guido van Rossum wrote:
> On Nov 19, 2007 3:06 PM, Amaury Forgeot d'Arc <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>> Is there anything that you (or anyone else!) would really like to see
>>> added to or fixed in 3.0a2? Now's the time!
>> I am currently having a look at http://bugs.pyth
Guido van Rossum wrote:
> Please comment.
> [...]
> Conversions between bytes or buffer objects and str objects must
> always be explicit, using an encoding. There are two equivalent APIs:
> ``str(b, [, ])`` is equivalent to
> ``b.encode([, ])``, and
> ``bytes(s, [, ])`` is equivalent to
> ``s.d
Walter Dörwald wrote:
> [...]
> However test_tarfile.py still segfaults for me in the py3k branch. The
> top of the stacktrace is:
>
> #0 0xb7eec07f in memcpy () from /lib/tls/libc.so.6
> #1 0xb7a905bc in s_pack_internal (soself=0xb77dc97c, args=0xb77cddfc,
> of
Guido van Rossum wrote:
> [...[
>
>> * On ia64, test_tarfile.PAXUnicodeTest.test_utf7_filename generates
>> this exception:
>> Objects/exceptions.c:1392: PyUnicodeDecodeError_Create: Assertion
>> `start < 2147483647' failed.
>
> That's probably an uninitialized variable 'startinpos' in one of th
Guido van Rossum wrote:
> On 8/16/07, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> Martin v. Löwis wrote:
>>
>>>> A simple merge won't work, because in 3.0 the codec uses bytes and in
>>>> 2.6 it uses str. Also the call to the decoding error
Guido van Rossum wrote:
> I see two new tests failing tonight:
>
> - test_xmlrpc fails on all platforms I have. This is due to several
> new tests that were merged in from the trunk; presumably those tests
> need changes due to str vs. bytes.
>
> - test_codecs fails on OSX PPC only. This is in t
Martin v. Löwis wrote:
>> A simple merge won't work, because in 3.0 the codec uses bytes and in
>> 2.6 it uses str. Also the call to the decoding error handler has
>> changed, because in 3.0 the error handler could modify the mutable input
>> buffer.
>
> So what's the strategy then? Block the tru
Martin v. Löwis wrote:
>> OK, then I'll check it into the py3k branch, and backport it to the trunk.
>
> This raises another procedural question: are we still merging from the
> trunk to the 3k branch, or are they now officially split?
>
> If we still merge, and assuming that the implementations
Guido van Rossum wrote:
> On 8/16/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> Walter Dörwald schrieb:
>>> I have a patch against the py3k branch (http://bugs.python.org/1775604)
>>> that adds UTF-32 codecs. On a narrow build it combines surroga
I have a patch against the py3k branch (http://bugs.python.org/1775604)
that adds UTF-32 codecs. On a narrow build it combines surrogate pairs
in the unicode object into one codepoint on encoding and creates
surrogate pairs for codepoints outside the BMP on decoding.
Should I apply this to the py3
Ron Adam wrote:
>
> Greg Ewing wrote:
>> Ron Adam wrote:
>>
>>> The digits value are number of digits before the decimal. This doesn't
>>> include the other symbols used in the field so it isn't the same as a field
>>> width.
>> How does this work with formats where the number of
>> digits befo
Neal Norwitz wrote:
> [...]
> Code to trigger a leak: b'\xff'.decode("utf8", "ignore")
This should be fixed in r56894.
> [...]
Servus,
Walter
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Martin v. Löwis wrote:
>>> I now tried, and it turned out that bytes.__reduce__ would break
>>> (again); I fixed it and changed it in r56755.
>>>
>>> It turned out that PyUnicode_FromString was even documented to
>>> accept latin-1.
>> Yes, that seemed to me to be the most obvious interpretion.
>
Martin v. Löwis wrote:
>> You mean if it were fixed it could fail, right? Code calling it should
>> be checking for errors anyway because it allocates memory.
>>
>> Have you tried making this particular change and seeing what fails?
>
> I now tried, and it turned out that bytes.__reduce__ would b
Guido van Rossum wrote:
> On 7/11/07, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> I guess for the final version of Py3000 type_set_name() in typeobject.c
>> will not downgrade unicode strings to str8, but instead upgrade str8
>> objects to unicode.
>
> Right,
t; Yeah, I'm looking in to this right now. What a mess! But I'm close to
>> a fix.
>>
>> There's more that causes test_descr to fail however. Bleh, what a
>> terrible unit test -- it doesn't use the unittest module, and a single
>> failure aborts
Christian Heimes wrote:
> I found a bug in the str type that may affect a lot of tests.
>
> In the py3k-struni branch the str() constructor doesn't use __str__ when
> the argument is an instance of a subclass of str. A user defined string
> can't change __str__(). The __repr__ method isn't affect
Ron Adam wrote:
> [...]
> M Lib/tokenize.py
> M Lib/test/tokenize_tests.txt
> M Lib/test/output/test_tokenize
> - Removed unicode literals from test results and tokenize.py. And make
> it pass again.
>
>
> M Lib/test/output/test_pep277
> - Removed unicode literals from test
Georg Brandl wrote:
> Walter Dörwald schrieb:
>> Georg Brandl wrote:
>>> Nick Coghlan schrieb:
>>>> Georg Brandl wrote:
>>>>> Guido van Rossum schrieb:
>>>>>> I've written up a comprehensive status report on Python 3000. Please
&
Georg Brandl wrote:
> Nick Coghlan schrieb:
>> Georg Brandl wrote:
>>> Guido van Rossum schrieb:
I've written up a comprehensive status report on Python 3000. Please read:
http://www.artima.com/weblogs/viewpost.jsp?thread=208549
>>> Thank you! Now I have something to show to interest
binascii.b2a_qp() in the p3yk branch is broken. What I get is:
$ gdb ./python
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Guido van Rossum wrote:
>> >> > I wonder if it would be possible to return the state as a pair
>> >> > (unread, flags) where unread is a (byte) string of unprocessed bytes
>> >> > and flags is some other state, with the constraint that in the
>> initial
>> >> > state the flags must be zero. Then I
Guido van Rossum wrote:
> On 4/12/07, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>> > On 4/11/07, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> >> Would it make sense to make the state of the decoder public, e.g. by
>> &
Guido van Rossum wrote:
> On 4/11/07, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> Would it make sense to make the state of the decoder public, e.g. by
>> adding setstate() and getstate() methods? This would give a cleaner API.
>
> I've been thinking of the same
guido.van.rossum wrote:
> Author: guido.van.rossum
> Date: Wed Apr 11 03:09:03 2007
> New Revision: 54742
>
> Modified:
>python/branches/p3yk/Lib/io.py
>python/branches/p3yk/Lib/test/test_io.py
> Log:
> Checkpoint so I can continue to work on this at a different box.
> There is somewhat w
Guido van Rossum wrote:
> On 2/27/07, Walter Dörwald <[EMAIL PROTECTED]> wrote:
> [...]
>> The basic principle is that these codecs can encode strings and decode
>> bytes in multiple chunks. If you want to encode a unicode string u in
>> UTF-16 you can do it in one g
Guido van Rossum wrote:
> On 2/27/07, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>
>> > The encoding/decoding behavior should be no different from that of the
>> > encode() and decode() methods on unicode strings and byte ar
Guido van Rossum wrote:
> The encoding/decoding behavior should be no different from that of the
> encode() and decode() methods on unicode strings and byte arrays.
Except that it must work in incremental mode. The new (in 2.5)
incremental codecs should be usable for that.
> Certainly no normal
Jack Diederich wrote:
> On Wed, Nov 22, 2006 at 09:36:09AM +0100, Georg Brandl wrote:
>> Terry Reedy schrieb:
>>> "Brett Cannon" <[EMAIL PROTECTED]> wrote in message
>>> news:[EMAIL PROTECTED]
>>>
>>> Why can't the fallback usage just pass the return value from __len__ to
>>> bool() (forget the
Guido van Rossum wrote:
> On 11/21/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> [...]
>> That's because some generic functions use if-isinstance checks (bad), while
>> others use custom __special__ methods (not bad, but not great), registries
>> (good), adaptation (okay), or generic function lib
Josiah Carlson wrote:
> Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>>
>> Le mercredi 13 septembre 2006 à 09:41 -0700, Josiah Carlson a écrit :
>>> And is generally ignored, as per unicode spec; it's a "zero width
>>> non-breaking space" - an invisible character with no effect on wrapping
>>> or othe
Jason Orendorff wrote:
> On 9/13/06, John S. Yates, Jr. <[EMAIL PROTECTED]> wrote:
>> It is a mistake on Microsoft's part to fail to strip the BOM
>> during conversion to UTF-8.
>
> John, you're mistaken about the reason this BOM is here.
>
> In Notepad at least, the BOM is intentionally generate
Paul Prescod wrote:
> I went based on the current setdefaultencoding. But it seems that we will
> accumulate 3 or 4 related functions so I'm pursuaded that there should be a
> module.
>
> encodingdetection.setdefaultfileencoding
> encodingdetection.registerencodingdetector
> encodingdetection.gues
tomer filiba wrote:
> [...]
> besides, encoding suffers from many issues. suppose you have a
> damaged UTF8 file, which you read char-by-char. when we reach the
> damaged part, you'll never be able to "skip" it, as we'll just keep
> read()ing bytes, hoping to make a character out of it , until we
Guido van Rossum wrote:
> I don't find the current attempts to come up with a better substring
> search API useful.
>
> [...]
>
> I appreciate the criticism on the patch -- clearly it's not ready to
> go in, and more work needs to be put in to actually *improve* the
> code, using [r]partition()
Guido van Rossum wrote:
> On 7/20/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> str and unicode don't have __iter__, list, tuple and dict do:
> [...]
>> Should that be fixed too?
>
> Yes, please. (In Python 2.6 if you can.)
Here's the patch: bu
Guido van Rossum wrote:
> On 7/18/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Andrew Koenig wrote:
>>
>>> I am uncomfortable about exposing the implementation this way, if only
>>> because it would require fixing the equivalence between callable() and
>>> hasattr(obj, '__call__') for all time.
>>
Nick Coghlan wrote:
> Thomas Wouters wrote:
>> It doesn't matter. Either case is confusing, one way or another, as Tim
>> has already argued. Changing it would be a big mistake. If you want me
>> to come with more comprehensive arguments (other than what Tim already
>> covered), please come with
Guido van Rossum wrote:
> On 4/20/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>
>> > Sorry, there's so much here that seems poorly thought out that I don't
>> > know where to start.
>>
>> Consider it a
Guido van Rossum wrote:
> Sorry, there's so much here that seems poorly thought out that I don't
> know where to start.
Consider it a collection of wild ideas.
> Getting rid of the existing import syntax in favor of the incredibly
> verbose and ugly
>
> foo = import("foo")
>
> just isn't acc
Guido van Rossum wrote:
> On 4/20/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> I'd like to be able to simply import a file if I have the filename. And
>> I'd like to be able to load sourcecode from an Oracle database and have
>> useful "filena
Greg Ewing wrote:
> Walter Dörwald wrote:
>
>> The "checking for NULL" scenario looks somewhat like this:
>>
>> And the "clearing the reference" scenario should look ike this:
>
> But only if the reference is a local to the function,
True P
Greg Ewing wrote:
> Walter Dörwald wrote:
>> Greg Ewing wrote:
>>> It would be less efficient in the cases where you don't
>>> need to check for NULL and/or clear the reference
>>> afterwards.
>>
>> Both should be optimized away by the comp
Greg Ewing wrote:
> Edward C. Jones wrote:
>
>> Can Py_CLEAR completely replace Py_DECREF and Py_XDECREF?
>
> It would be less efficient in the cases where you don't
> need to check for NULL and/or clear the reference
> afterwards.
Both should be optimized away by the compiler.
But what we gai
Guido van Rossum wrote:
> On 4/17/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> The rest of it was just suggesting that permitting keyword
>> parameters/arguments after *args should be the *only* change we make in this
>> area. I don't see any point in permitting positional arguments to come after
Guido van Rossum sagte:
> On 4/7/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> An Interface is an abstract class that you subclass to make it a concrete
>> implementation.
>
> That's not the view of most people who use the word interface these days. Not
> i
Guido van Rossum wrote:
> On 4/7/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>>> Using @overloaded functions I would create an explicit class variable
>>> which is the @overloaded adapter rather than trying to make the
>>> interface also *be* the adapter
Jim Jewett wrote:
> On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>
>> class Sequence(Interface):
>> def getitem(self, index): pass
>> def len(self): pass
>
>> class PythonSeqAsSequence(Sequence):
>> def __init__(self, obj):
>&g
Guido van Rossum wrote:
> On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> But might closes off one route we could take if we're adapting to
>> something that must provide more than one function/method (i.e. an
>> interface) and we'd like to have th
Guido van Rossum wrote:
> On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> The problem with this is that it looks in the base protocol only if the
>> the class can't be found in the registry of the subprotocol. This mean
>> that an adapter from the subprot
Tim Hochberg wrote:
> Walter Dörwald wrote:
>
>> Guido van Rossum wrote:
>>
>>> On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>>>
>>>> Guido van Rossum wrote:
>>>>
>>>>> On 4/5/06, Tim Hochberg <[EMAIL
Guido van Rossum wrote:
> On 4/5/06, Walter Dörwald <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>
>>> On 4/5/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
>>>> I'm hoping that Walter can give some more realistic examples since I
>&
Tim Hochberg wrote:
> Guido van Rossum wrote:
>
>> On 4/5/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
>>
>>
>>> Walter Dörwald wrote:
>>>
>>>
>>>> What's still missing IMHO is a way for an a
Guido van Rossum wrote:
> On 4/5/06, Tim Hochberg <[EMAIL PROTECTED]> wrote:
>> I'm hoping that Walter can give some more realistic examples since I
>> don't have real-world experience here. The basic idea is simply to let
>> an adapter give up and let the protocol try the next adapter. This could
Guido van Rossum wrote:
> Fascinating ideas in this thread!
>
> I spent some time blogging about this on artima:
> http://www.artima.com/weblogs/viewpost.jsp?thread=155123
>
> I have to write my slides for a talk about Py3K later today, but I'll
> be back. In the mean time I've rejected PEPs 245
Nick Coghlan wrote:
> [...]
> def default_adapter(self, *args):
> """Call result when no adapter was found"""
> raise TypeError("Can't adapt %s to %s" %
> (args[0].__class__.__name__, self.name))
+1 This makes it easy to add fallbacks:
class XReprP
Nick Coghlan wrote:
> [...]
> So your example would become:
>
> class MetaInterface(type):
> def __new__(mcl, name, bases, dict):
> # Give each class it's own registry
> cls = type.__new__(mcl, name, bases, dict)
> cls.registry = {}
> return cls
>
>
t Sequence.adapt([1,2,3]).len()
But if adapting is done via __call__() we have a problem: Sequence
already provides a __call__, the constructor. Of course if this worked
print Sequence([1,2,3]).len()
would look much better than
print Sequence.adapt([1,2,3]).len()
but I'm not sure if it's
Ian Bicking wrote:
> Walter Dörwald wrote:
>> What happens, if I do the following
>>
>> @PrettyPrinter.pformat.when(object=list)
>> def foo(...):
>>...
>>
>> @PrettyPrinter.pformat.when(object=object)
>> def foo(...):
>>...
&g
s, and other things I probably haven't
> thought of. But anyway, this allows:
>
> class PrettyPrinter:
> def pformat(self, object): ...
>
> # Without keyword arguments I have to give a wildcard for the self
> # argument..
Alex Martelli wrote:
> On Apr 2, 2006, at 4:39 PM, Walter Dörwald wrote:
>...
>> Why not make the registry identical to the protocol? The protocol is
>> just a convention anyway:
>
> Yes, a 1<->1 relationship between registries and protocols makes the
> &#
ings.
> 3 I am not arguing _against_ syntactic support, I am arguing _for_ a method;
>we can keep the syntactic support.
and it avoids one problem you might run into with %: If you have only
one argument, writing ``s % (x,)`` as ``s % x`` will break when the
argument x happens to be a tup
all sort of "cruft" to be piled on top.
I think you might be misinterpreting reactions. If the initial reaction
was "I don't understand it. Nobody needs this." (at least that was my
reaction), you're "strawman proposal" has put us past
I would
use this adaption module).
At the minimum this module should support inheritance of the adapted type, so a
simple dict won't work.
Defining an adaptor for the copy protocol might look like this:
@adaptor(Foo, "org.python.copy")
class CopyFoo:
def __init
72 matches
Mail list logo
