On 30 Oct, 2007, at 19:05, Brett Cannon wrote:
On 10/29/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
2007/10/27, Bill Janssen <[EMAIL PROTECTED]>:
ISTR much of the plat-mac stuff was generated by Tools/bgen. If
so, that
would be the place to fix things.
Sure looks like generated code.
On 11/1/07, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
> For what it is worth: I agree that most of the mac libraries, such as
> the entire Carbon package, shouldn't be part of the standard library.
>
> The reason for that is simple: the release-cycle of the MacOS bindings
> are currently bound to
It's time to start thinking about pickle compatibility between 2.x and
3.0. The main problem is the 2.x str type -- it doesn't have a true
equivalent in 3.0.
When 3.0 encounters a 'str' object in a pickle written by 2.x, it has
two choices: trying to convert it to a 3.0 (unicode) str object by
app
On 1 Nov, 2007, at 15:06, Guido van Rossum wrote:
On 11/1/07, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
For what it is worth: I agree that most of the mac libraries, such as
the entire Carbon package, shouldn't be part of the standard library.
The reason for that is simple: the release-cycle
On 11/1/07, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
> I'm volunteering to keep improving PyObjC, but I won't promise that
> PyObjC will be complete enough to replace the Carbon tree by the time
> Python 3.0 goes into beta. Heck, just commiting the version of PyObjC
> that is in Leopard into a pu
On 1 Nov, 2007, at 15:22, Guido van Rossum wrote:
On 11/1/07, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
I'm volunteering to keep improving PyObjC, but I won't promise that
PyObjC will be complete enough to replace the Carbon tree by the time
Python 3.0 goes into beta. Heck, just commiting the
I know; right before 3.0a1 was released I fixed all encoders to return
PyBytes. IMO they should return PyString though. The best place to fix
this quickly is in the wrapper function(s) -- if the codec returned
PyBytes, just change it to PyString again. Then we can fix the codecs
later (or leave it
I'm trying to fix some of the errors in the py3k-pep3137 branch and I
stumbled over an issue with encode().
TypeError: encoder did not return a bytes object (type=bytes)
The sentence "... encoding always takes a Unicode string and returns a
bytes sequence, and decoding always takes a bytes sequen
Guido van Rossum wrote:
> To avoid us doing double work, can you just submit any straightforward
> fixes you might already have made, and email me about projects you
> have underway? I expect to be getting back to this in about two hours.
> :-)
I'm walking through Lib/ and Lib/test/ and I'm fixing
OK, after I'm done with the merge from hell (I decided to merge from
the trunk to py3k).
On 11/1/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > To avoid us doing double work, can you just submit any straightforward
> > fixes you might already have made, and email me
> I could leave this all up to the 3.0 application, which would have to
> "fix up" any bytes in the pickle it receives explicitly if it wants
> to. Alternatively, I could add an encoding option to the pickle
> loading APIs (and for full flexibility an errors option as well) so
> that at least simpl
> On the bright side: Carbon is basicly dead: there will be no new
> development on Carbon and it also not supported in 64-bit mode (at
> least the GUI bits).
Unfortunately, the "gotcha" is that some existing functionality is not
available via Objective-C (yet?); I looked at this when writing
2007/11/1, Guido van Rossum <[EMAIL PROTECTED]>:
> I could leave this all up to the 3.0 application, which would have to
> "fix up" any bytes in the pickle it receives explicitly if it wants
> to. Alternatively, I could add an encoding option to the pickle
> loading APIs (and for full flexibility
On 11/1/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > On the bright side: Carbon is basicly dead: there will be no new
> > development on Carbon and it also not supported in 64-bit mode (at
> > least the GUI bits).
>
> Unfortunately, the "gotcha" is that some existing functionality is not
> avail
> if you need Carbon, you stick with
> 2.x, otherwise Py3K is requiring you modernize your Mac code and move
> to Cocoa and PyObjC.
Brett,
It's not just Carbon and Cocoa, which are primarily different bindings
for developing Apple-style "applications", and primarily in my mind
for GUI functionali
> Does anyone have suggestions on how to mobilize people for this without
> scaring them away when explaining what needs to be done? People,
> including myself to be honest, seem to find other things to do when the
> realize that fixing the Carbon wrappers involves working with and
> hacking on bg
On Nov 1, 2007 7:31 AM, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
>
> On 1 Nov, 2007, at 15:22, Guido van Rossum wrote:
>
> > On 11/1/07, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
> >> I'm volunteering to keep improving PyObjC, but I won't promise that
> >> PyObjC will be complete enough to repla
> Should any of the Apple changes be merged into the 2.5 branch?
Not without the Apple authors signing a contributor form.
Regards,
Martin
___
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscrib
Guido van Rossum wrote:
> I could add an encoding option to the pickle
> loading APIs
That sounds like the right thing to me. Or at least I
can't think of anything better.
Applications wanting to deal with pickles containing
strings of binary data would just have to specify
latin1 and translate t
Ronald Oussoren wrote:
>
> People,
> including myself to be honest, seem to find other things to do when the
> realize that fixing the Carbon wrappers involves working with and
> hacking on bgen :-(
Perhaps a volunteer could be found to re-do them in Pyrex?
(No, I'm not volunteering for th
Currently (in 3.0), "".join() automatically applies str() to the
items of , *except* if the item is a bytes instance -- then it
raises a TypeError. Is that proper behavior? The alternative is to
uniformly apply str(), which for bytes returns a string of the form
"b'...'" or "buffer(b'...')" (depend
On 11/1/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
> > uniformly apply str(), which for bytes returns a string of the form
> > "b'...'" or "buffer(b'...')" (depending on whether the bytes are
>
> Don't understand... From the trunk:
>
> Python 3.0a1+ (py3k:58762, Nov 1 2007, 21:17:44)
> [GCC 4.
People wanted it for convenience. I agree it's debatable. OTOH "
".join([...]) could behave similarly to print(...) and there's
something to say for that. print(b"") will print b'' too once PEP 3137
is fully implemented.
On 11/1/07, Jeffrey Yasskin <[EMAIL PROTECTED]> wrote:
> I'd naïvely vote for
I'd naïvely vote for having "".join([non-strings]) raise a TypeError
unconditionally like it did in 2.5. I agree that it doesn't make sense
to special-case bytes here, but I don't know the reasons for changing
it to call str() in other cases.
On 11/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
2007/11/1, Guido van Rossum <[EMAIL PROTECTED]>:
> Currently (in 3.0), "".join() automatically applies str() to the
> items of , *except* if the item is a bytes instance -- then it
> raises a TypeError. Is that proper behavior? The alternative is to
I'd prefer to *always* apply the str() function
2007/11/2, Guido van Rossum <[EMAIL PROTECTED]>:
> Ah, but now try it in the py3k-pep3137 trunk...
>
> Python 3.0a1+ (py3k-pep3137, Nov 1 2007, 19:17:57)
> [GCC 4.0.3 (Ubuntu 4.0.3-1ubuntu5)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
> >>> str(b"hola")
> "
-1 on having "".join() call str at all. yuck. shouldn't the caller just
write:
"".join((str(x) for x in thing))
when they desire guaranteed stringification instead of a TypeError?
Anyways others disagree and this was already implemented so I assume my -1
is rejected, I at least agree on this:
On Nov 2, 2007, at 12:37 AM, Gregory P. Smith wrote:
> Or is that too much work and not enough context in the callable to
> be useful? People could just as easily write code to recurse
> through the unpickled output converting the appropriate bytes
> objects as needed.
Not enough context to
On 11/1/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
>
> 2007/11/1, Guido van Rossum <[EMAIL PROTECTED]>:
>
> > I could leave this all up to the 3.0 application, which would have to
> > "fix up" any bytes in the pickle it receives explicitly if it wants
> > to. Alternatively, I could add an encod
On 11/1/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> Currently (in 3.0), "".join() automatically applies str() to the
> items of , *except* if the item is a bytes instance -- then it
> raises a TypeError. Is that proper behavior? The alternative is to
> uniformly apply str(), which for bytes r
On 1 Nov, 2007, at 22:51, Neal Norwitz wrote:
On Nov 1, 2007 7:31 AM, Ronald Oussoren <[EMAIL PROTECTED]>
wrote:
On 1 Nov, 2007, at 15:22, Guido van Rossum wrote:
On 11/1/07, Ronald Oussoren <[EMAIL PROTECTED]> wrote:
I'm volunteering to keep improving PyObjC, but I won't promise that
PyO
On 1 Nov, 2007, at 18:24, Brett Cannon wrote:
On 11/1/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
On the bright side: Carbon is basicly dead: there will be no new
development on Carbon and it also not supported in 64-bit mode (at
least the GUI bits).
Unfortunately, the "gotcha" is that some
32 matches
Mail list logo
