Jim Jewett wrote:
> I would prefer that x.split(":") work.
>
> If that happens because bytes.split does the conversion for me (so
> that x.split(sep) also works), then great. But I realize that would
> require an assumption about the proper encoding.
If you're going to do things like that, why s
> If it works because the bytecode compiler changes x.split(":") into
> the moral equivalent of
>
> try:
> x.split(":")
> except StrNotBytesError:
> x.split(b":")
>
> that is good enough.
And how do you propose to implement that?
Regards,
Martin
_
Jim Jewett wrote:
> On 8/31/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > x = "abc"
> > f(x)
>
> I suppose consistency with that sort of use ... is
> the main argument against this.
I'd be *very* upset if Python started behaving differently
depending on whether I wrote a literal direct
On 8/31/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> Yuck, yuck about the source file encoding part. Also, there is no way
> >> to tell that a particular argument was passed a literal.
> > There is when compiling to bytecode; it goes in co_consts.
> >> The very
> >> definition of "this w
>> Yuck, yuck about the source file encoding part. Also, there is no way
>> to tell that a particular argument was passed a literal.
>
> There is when compiling to bytecode; it goes in co_consts.
>
>> The very
>> definition of "this was a literal" is iffy -- is x a literal when
>> passed to f bel
On 8/31/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/31/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > (1) Allow bytes methods to take a literal string (which will
> > obviously be in the source file's encoding).
> Yuck, yuck about the source file encoding part. Also, there is no way
>
> (1) Allow bytes methods to take a literal string (which will
> obviously be in the source file's encoding).
To rephrase Guido's comment: do you have the slightest idea on
how to specify and implement that?
Regards,
Martin
___
Python-3000 mailing list
On 8/31/07, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 8/31/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > > For me on OS X, I'm still getting a failure in test_plistlib and an
>
> > No worry, I cracked it, just in time before the release.
>
> Seeing the recent changes to plistlib does
On 8/31/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > For me on OS X, I'm still getting a failure in test_plistlib and an
> No worry, I cracked it, just in time before the release.
Seeing the recent changes to plistlib does make me think that bytes is
more awkward than it should be.
On 8/31/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> On Aug 31, 2007, at 8:17 AM, Eric Smith wrote:
> > Martin v. Löwis wrote:
> For me on OS X, I'm still getting a failure in test_plistlib and an
> unexpected skip in test_ssl.
> >>> If it helps, the test_plistlib errors follow.
> >>
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 31, 2007, at 8:17 AM, Eric Smith wrote:
> Martin v. Löwis wrote:
For me on OS X, I'm still getting a failure in test_plistlib and an
unexpected skip in test_ssl.
>>> If it helps, the test_plistlib errors follow.
>>
>> In case it isn't
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 31, 2007, at 7:25 AM, Thomas Wouters wrote:
> On 8/31/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> For me on OS X, I'm still getting a failure in test_plistlib and an
> unexpected skip in test_ssl.
>
> The skip is intentional; the ssl module i
Martin v. Löwis wrote:
>>> For me on OS X, I'm still getting a failure in test_plistlib and an
>>> unexpected skip in test_ssl.
>> If it helps, the test_plistlib errors follow.
>
> In case it isn't clear: test_plistlib will fail *only* on OS X, because
> it isn't run elsewhere. So somebody with
>> For me on OS X, I'm still getting a failure in test_plistlib and an
>> unexpected skip in test_ssl.
>
> If it helps, the test_plistlib errors follow.
In case it isn't clear: test_plistlib will fail *only* on OS X, because
it isn't run elsewhere. So somebody with OS X needs to fix it.
Regard
Barry Warsaw wrote:
> For me on OS X, I'm still getting a failure in test_plistlib and an
> unexpected skip in test_ssl.
If it helps, the test_plistlib errors follow.
$ ./python.exe Lib/test/test_plistlib.py -v
test_appleformatting (__main__.TestPlistlib) ... ERROR
test_appleformattingfromlit
On 8/31/07, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> For me on OS X, I'm still getting a failure in test_plistlib and an
> unexpected skip in test_ssl.
The skip is intentional; the ssl module is in a state of flux, having the
latest changes from the trunk applied, but not adjusted to the new la
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 31, 2007, at 12:52 AM, Guido van Rossum wrote:
> I'm pretty happy where we stand now -- I just squashed the last two
> failing tests (test_mailbox and test_oldmailbox). It is 9:30 pm here
> and I'm tired, so I'm going to try and get a good nigh
I'm pretty happy where we stand now -- I just squashed the last two
failing tests (test_mailbox and test_oldmailbox). It is 9:30 pm here
and I'm tired, so I'm going to try and get a good night's sleep and do
the release as early as I can tomorrow.
Remember, I'll freeze the branch (not a real lock,
18 matches
Mail list logo
