-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Amaury Forgeot d'Arc wrote:
| I suppose you just copied the _bsddb.c file from trunk, right? Here is
| the problem.
| The current version of _bsddb.c in the py3k branch contains the lines:
| {
| PyObject *builtin_mod = PyImport_ImportMod
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Amaury Forgeot d'Arc wrote:
| I think you were close, you just have to be careful to call
| PyType_Ready in the module init function,
| to create the descriptors for each tp_methods and tp_members entries.
Already done :). Thanks for answering.
My d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Working on the 3.0 version of bsddb, I have the following issue.
Until 3.0, keys and values were strings. For bsddb, they are opaque, and
stored unchanged.
In 3.0 the string type is replaced by unicode. A new "byte" type is
added. So, code like "db.
Jesus Cea wrote:
> Amaury Forgeot d'Arc wrote:
> | I think you were close, you just have to be careful to call
> | PyType_Ready in the module init function,
> | to create the descriptors for each tp_methods and tp_members entries.
>
> Already done :). Thanks for answering.
>
> My doubt now is how d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Amaury Forgeot d'Arc wrote:
|> My doubt now is how do write a *clever* "getattr" routine without
|> "Py_FindMethod".
|
| Well, I'd write a "tp_getattro" member function,
| which would do its "clever" things before it falls back to
| PyObject_GenericGe
Jesus Cea wrote:
> Amaury Forgeot d'Arc wrote:
> |> My doubt now is how do write a *clever* "getattr" routine without
> |> "Py_FindMethod".
> |
> | Well, I'd write a "tp_getattro" member function,
> | which would do its "clever" things before it falls back to
> | PyObject_GenericGetAttr to get the
Jesus Cea wrote:
>
> Working on the 3.0 version of bsddb, I have the following issue.
>
> Until 3.0, keys and values were strings. For bsddb, they are opaque, and
> stored unchanged.
>
> In 3.0 the string type is replaced by unicode. A new "byte" type is
> added. So, code like "db.put('key','value'
Hi,
> In 3.0 the string type is replaced by unicode. A new "byte" type is
> added. So, code like "db.put('key','value')" needs to be changed to
> "db.put(bytes('key', 'utf-8'), bytes('value', 'utf-8'))", or something
> similar.
Why not "db.put(b'key', b'value')"?
> This is ugly and generates in
On Tue July 29 2008 8:42:08 am Jesus Cea wrote:
> Amaury Forgeot d'Arc wrote:
> |> My doubt now is how do write a *clever* "getattr" routine without
> |> "Py_FindMethod".
> |
> | Well, I'd write a "tp_getattro" member function,
> | which would do its "clever" things before it falls back to
> | PyOb
> So, I'm thinking seriously in accepting *ONLY* "bytes" in the bsddb API
> (when working under Python 3.0), and do the proxy thing *ONLY* in the
> testsuite, to be able to reuse it.
>
> What do you think?.
I think you should write the test suite in terms of bytes.
Regards,
Martin
__
Georg Brandl schrieb:
Someone just wrote to the docs mailing list and reported that the itertools
documentation for Py3k contains this recipe:
def grouper(n, iterable, fillvalue=None):
args = [iter(iterable)] * n
return zip_longest(*args, fillvalue=fillvalue)
It is currently a syntax
On Tue, Jul 29, 2008 at 1:48 PM, Georg Brandl <[EMAIL PROTECTED]> wrote:
> Georg Brandl schrieb:
>>
>> Someone just wrote to the docs mailing list and reported that the
>> itertools
>> documentation for Py3k contains this recipe:
>>
>> def grouper(n, iterable, fillvalue=None):
>> args = [iter(i
On 29-Jul-08, at 7:32 AM, Jesus Cea wrote:
Working on the 3.0 version of bsddb, I have the following issue.
Until 3.0, keys and values were strings. For bsddb, they are opaque,
and
stored unchanged.
In 3.0 the string type is replaced by unicode. A new "byte" type is
added. So, code like "d
.../Python-3.0b2/Python-3.0b2/Doc/build/html/reference/datamodel.html#object.__hash__
"""If a class defines mutable objects and implements a __cmp__() or __eq__()
method, it should not implement __hash__(), since the dictionary
implementation requires that a key’s hash value is immutable (if the
Your question isn't really Python-3000-specific, and belongs more on
the comp.lang.python list.
That said, whether it's right for your object really depends on how
you're defining equality for it. Are you defining equality as merely
identity (i.e. are they pointers to the same spot in memory) or d
Sounds good to me. Less cruft is the tagline for Py3k!
On Mon, Jul 21, 2008 at 7:32 AM, Lars Gustäbel <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I just had a look at issue 3039 that reports a bug in tarfile.py's
> TarFileCompat class and I came to the conclusion that I really would like to
> remove the
Georg Brandl wrote:
Georg Brandl schrieb:
Someone just wrote to the docs mailing list and reported that the
itertools
documentation for Py3k contains this recipe:
def grouper(n, iterable, fillvalue=None):
args = [iter(iterable)] * n
return zip_longest(*args, fillvalue=fillvalue)
It
Charles Hixson wrote:
.../Python-3.0b2/Python-3.0b2/Doc/build/html/reference/datamodel.html#object.__hash__
"""If a class defines mutable objects and implements a __cmp__() or __eq__()
method, it should not implement __hash__(), since the dictionary
implementation requires that a key’s hash va
On Tue, Jul 29, 2008 at 3:51 PM, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Georg Brandl wrote:
>>
>> Georg Brandl schrieb:
>>>
>>> Someone just wrote to the docs mailing list and reported that the
>>> itertools
>>> documentation for Py3k contains this recipe:
>>>
>>> def grouper(n, iterable, fillva
Did anyone come up with a fix for these?
It's true that OverflowError and MemoryError are returned pretty
randomly when we detect that an allocation is not going to fit. I
think MemoryError is better though, so perhaps those uses of
OverflowError should be fixed. I doubt that there are any apps (e
Nick Coghlan wrote:
With keyword-only parameters allowed now, I think it makes sense to be
able to supply the keywords arguments after the variable length argument
as well.
I'm confused -- I thought that keyword-only arguments were
supposed to let you do exactly that. Or is that only in the
d
Nick Coghlan wrote:
Objects which compare equal must also end up in the same hash bucket in
order for dictionaries to work correctly.
And, if its equality with another object can change during
its lifetime, it will never work properly in a dictionary.
So in that case you should leave __hash__
With keyword-only parameters allowed now, I think it makes sense to be able
to supply the keywords arguments after the variable length argument as well.
Agreed. I doubt that this will be a simple enough change to allow it
in 3.0 though.
Sure would be nice if it could go in. IMO, the functional
On Tue, Jul 29, 2008 at 7:05 PM, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Did anyone come up with a fix for these?
>
> It's true that OverflowError and MemoryError are returned pretty
> randomly when we detect that an allocation is not going to fit. I
> think MemoryError is better though, so p
>Another approach would be to add a new bsddb method to specify the
>default encoding to use to convert unicode->bytes, and to do the
>conversion internally when getting unicode data as a parameter. The
>issue here is that "u'hi' != b'hi'", so the translation must be done
>both when storing and whe
On Tue, Jul 29, 2008 at 6:19 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
>>> With keyword-only parameters allowed now, I think it makes sense to be able
>>> to supply the keywords arguments after the variable length argument as
>>> well.
>>
>> Agreed. I doubt that this will be a simple enough
> What about a new keyword argument to the constructor, "encoding". If
> specified, *only* accept unicode (and do the conversion internally).
Would that apply to keys, values, or both?
Regards,
Martin
___
Python-3000 mailing list
Python-3000@python.org
> +1 OverflowErrors should probably by reserved for numeric overflows.
In a sense, passing sys.maxsize as a string size *is* a numeric
overflow - the size can't be represented in the available variable.
Regards,
Martin
___
Python-3000 mailing list
Pytho
>> What about a new keyword argument to the constructor, "encoding". If
>> specified, *only* accept unicode (and do the conversion internally).
>
>Would that apply to keys, values, or both?
I admit that I deliberately glossed over that. 8-)
One option is to say "both", just to keep it simple: if
def grouper(n, iterable, fillvalue=None):
"grouper(3, 'abcdefg', 'x') --> abc def gxx"
args = [iter(iterable)] * n
kwds = dict(fillvalue=fillvalue)
return izip_longest(*args, **kwds)
[GvR]
If you reverse the two parts it will work:
izip_longest(fillvalue=fillvalue, *
30 matches
Mail list logo
