>> __reduce__ currently does (O(s#)) with (ob_type, ob_bytes, ob_size).
>> Now, s# creates a Unicode object, and the pickling fails to round-trip
>> correctly.
>
> I thought that before your patch a bytes object roundtripped correctly
> with all three protocols. Or maybe it got broken when s# was
On 19/07/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> The only approach to retroactive generification that I approve of is
> replacing the entire object with a wrapper of sorts, e.g.
>
> foo = generify(foo)
Which (again, just to clarify) means that you would require that
generic functions b
On Fri, Jul 13, 2007 at 01:41:47PM -0400, Phillip J. Eby wrote:
> At 07:39 AM 7/13/2007 +0200, Michele Simionato wrote:
> >But I want to ask your opinion first, in order to understand if you
> >are willing to scale down your proposal or not. At EuroPython Guido
> >said that in private mail you ma
On 19/07/07, Aurélien Campéas <[EMAIL PROTECTED]> wrote:
> On Fri, Jul 13, 2007 at 01:41:47PM -0400, Phillip J. Eby wrote:
> > At 07:39 AM 7/13/2007 +0200, Michele Simionato wrote:
> > >But I want to ask your opinion first, in order to understand if you
> > >are willing to scale down your proposal
On 7/19/07, Paul Moore <[EMAIL PROTECTED]> wrote:
> On 19/07/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > The only approach to retroactive generification that I approve of is
> > replacing the entire object with a wrapper of sorts, e.g.
> >
> > foo = generify(foo)
>
> Which (again, just to
On 7/19/07, Aurélien Campéas <[EMAIL PROTECTED]> wrote:
> I would have liked to have input on this from other people using
> RuleDispatch features also (doesn't one of Django/Turbogears project
> use them extensively ?). Just so the BDFL & lieutenants don't argue
> too much in the direction of 'the
On 7/18/07, Benji York <[EMAIL PROTECTED]> wrote:
> Alexandre Vassalotti wrote:
> > I expect other tools, like pdb.py and trace.py could follow this
> > convention as well. For example:
>
> I used the time machine to convince the author of trace.py use this
> convention.
Uh⁈
> He didn't like your
On Thu, Jul 19, 2007 at 07:22:37AM -0700, Guido van Rossum wrote:
> On 7/19/07, Aurélien Campéas <[EMAIL PROTECTED]> wrote:
>> I would have liked to have input on this from other people using
>> RuleDispatch features also (doesn't one of Django/Turbogears project
>> use them extensively ?). Just so
At 07:22 AM 7/19/2007 -0700, Guido van Rossum wrote:
>On 7/19/07, Aurélien Campéas <[EMAIL PROTECTED]> wrote:
> > I would have liked to have input on this from other people using
> > RuleDispatch features also (doesn't one of Django/Turbogears project
> > use them extensively ?). Just so the BDFL &
At 11:58 AM 7/19/2007 +0100, Paul Moore wrote:
>1. The "Advanced" API - some people (including Guido?) do not see the
>need for the advanced features of the PEP such as method combinations.
>On the other hand, no-one has offered to write up of implement a
>reduced version.
Actually, two people hav
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
By the way, I recently came across a use case for @around that I
hadn't mentioned before. I'm in the process of re-implementing
RuleDispatch's expression features in PEAK-Rules, and as I was
defining the rules for inter
On 7/19/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> __reduce__ currently does (O(s#)) with (ob_type, ob_bytes, ob_size).
> >> Now, s# creates a Unicode object, and the pickling fails to round-trip
> >> correctly.
> >
> > I thought that before your patch a bytes object roundtripped correct
> But you can do it using bytes('\xff', 'latin-1'). I think that's a
> reasonable thing for bytes.__reduce__() to return.
That's certainly a choice. Another choice is that bytes defaults to
latin-1, rather than the system default encoding. This is roughly
equivalent, and gives a slightly more comp
Guido van Rossum wrote:
> FWIW, I think the Turbogears use you're thinking of is jsonify,
> a GF for converting arbitrary Python data into JSON (JavaScript
> Object Notation). But I'm not aware of it using any of the
> advanced features -- it seems to be using just the basic facility
> of overload
At 04:00 PM 7/19/2007 -0400, Jonathan LaCour wrote:
>I for one, as a committer on TurboGears, would absolutely love to see
>a good, solid generic function capability integrated into the standard
>library, and find PEP 3124 to completely cover my needs. There are
>certainly things in the PEP that I
On 7/19/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > But you can do it using bytes('\xff', 'latin-1'). I think that's a
> > reasonable thing for bytes.__reduce__() to return.
>
> That's certainly a choice. Another choice is that bytes defaults to
> latin-1, rather than the system default en
On 7/19/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> How about instead you help with fixing pickling of datetime objects?
> This broke when I fixed test_pickle. Rolling back your changes to
> datetime pickling didn't seem to help.
Never mind; this was shallow -- cPickle doesn't pickle bytes
c
FYI... another TurboGears developer speaks up re: their generic function use.
>Date: Thu, 19 Jul 2007 20:17:23 -0400
>From: "Mark Ramm"
>To: "Phillip J. Eby"
>Subject: Re: [Python-3000] pep 3124 plans
>
>>FYI, Jonathan, the version of PEAK-Rules that's in SVN implements
>>everything that's curren
So the state of the PEP? From the rest of the posts so far,
it sounds like there is no real objection to the basic end user API as
described in the PEP,
except for the case of retroactive generification, which GvR wants made
explict in the user's code, AIUI.
But there are concerns about the imp
"Lino Mastrodomenico" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>2007/7/1, BJörn Lindqvist <[EMAIL PROTECTED]>:
>> But I cannot see how it would solve the problem with to many image
>> classes. The reason why PIL, PyGame and wxPython has different image
>> classes is because eac
20 matches
Mail list logo
