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
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 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
-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:
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")
> "
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.
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
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:
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
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
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
> 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
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscrib
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
> 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
> 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
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
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 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
> 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
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
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
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
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
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
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
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
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 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
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.
32 matches
Mail list logo
