Ron Adam wrote:
> [...]
> M Lib/tokenize.py
> M Lib/test/tokenize_tests.txt
> M Lib/test/output/test_tokenize
> - Removed unicode literals from test results and tokenize.py. And make
> it pass again.
>
>
> M Lib/test/output/test_pep277
> - Removed unicode literals from test
Guido van Rossum wrote:
Thanks for the patches! Applied, except for the change to
tokenize.py; instead, I changed test_tokenize.py to use io.StringIO.
--Guido
Glad to have the opportunity to help make the future happen. ;-)
This next one converts unicode literals in tokenize.py and it's t
Thanks for the patches! Applied, except for the change to
tokenize.py; instead, I changed test_tokenize.py to use io.StringIO.
--Guido
On 6/16/07, Ron Adam <[EMAIL PROTECTED]> wrote:
>
>
> Guido van Rossum wrote:
> > On 6/13/07, Ron Adam <[EMAIL PROTECTED]> wrote:
> >> Attached both the str8 rep
Guido van Rossum wrote:
On 6/13/07, Ron Adam <[EMAIL PROTECTED]> wrote:
Attached both the str8 repr as s"..." and s'...', and the latest
no_raw_escape patch which I think is complete now and should apply
with no
problems.
I like the str8 repr patch enough to check it in.
I tracked the ran
Martin v. Löwis wrote:
>> This was in the context that it is decided by the community that a st8
>> type is needed and it does not go away.
>
> I think *that* context has not occurred. People wanted a read-only
> bytes type, not a byte-oriented character string type.
>
>> The alternative is for
> This was in the context that it is decided by the community that a st8
> type is needed and it does not go away.
I think *that* context has not occurred. People wanted a read-only
bytes type, not a byte-oriented character string type.
> The alternative is for str8 to be replaced by byte objects
Martin v. Löwis wrote:
Then bytes can be bytes, and unicode can be unicode, and str8 can be
encoded strings for interfacing with the outside non-unicode world. Or
something like that.
>>> Hm... Requiring each str8 instance to have an encoding might be a
>>> problem -- it means yo
>>> Then bytes can be bytes, and unicode can be unicode, and str8 can be
>>> encoded strings for interfacing with the outside non-unicode world. Or
>>> something like that.
>>
>> Hm... Requiring each str8 instance to have an encoding might be a
>> problem -- it means you can't just create one fro
Guido van Rossum wrote:
> On 6/13/07, Ron Adam <[EMAIL PROTECTED]> wrote:
>> Well I can see where a str8() type with an __incoded_with__ attribute
>> could
>> be useful. It would use a bit more memory, but it won't be the
>> default/primary string type anymore so maybe it's ok.
>>
>> Then bytes
On 6/13/07, Ron Adam <[EMAIL PROTECTED]> wrote:
> Well I can see where a str8() type with an __incoded_with__ attribute could
> be useful. It would use a bit more memory, but it won't be the
> default/primary string type anymore so maybe it's ok.
>
> Then bytes can be bytes, and unicode can be uni
Guido van Rossum wrote:
On 6/13/07, Ron Adam <[EMAIL PROTECTED]> wrote:
Looking at the overall structure of os.py makes me think the platform
specific code could be abstracted out a bit further. Possibly have one
public "platform" module (or package) that is an alias or built from
private _pl
On 6/13/07, Ron Adam <[EMAIL PROTECTED]> wrote:
> Looking at the overall structure of os.py makes me think the platform
> specific code could be abstracted out a bit further. Possibly have one
> public "platform" module (or package) that is an alias or built from
> private _platform package files.
Guido van Rossum wrote:
> On 6/13/07, Ron Adam <[EMAIL PROTECTED]> wrote:
>>
>>
>> Guido van Rossum wrote:
>> > I couldn't get this exact patch to apply, but I implemented something
>> > equivalent in the py3kstruni branch. See revisions 55964 and 55965.
>> > Thanks for the suggestion!
>>
>> This
On 6/13/07, Ron Adam <[EMAIL PROTECTED]> wrote:
>
>
> Guido van Rossum wrote:
> > I couldn't get this exact patch to apply, but I implemented something
> > equivalent in the py3kstruni branch. See revisions 55964 and 55965.
> > Thanks for the suggestion!
>
> This is actually closer to how I started
Guido van Rossum wrote:
> I couldn't get this exact patch to apply, but I implemented something
> equivalent in the py3kstruni branch. See revisions 55964 and 55965.
> Thanks for the suggestion!
This is actually closer to how I started to do it, but I wasn't sure if it
would catch everything.
I couldn't get this exact patch to apply, but I implemented something
equivalent in the py3kstruni branch. See revisions 55964 and 55965.
Thanks for the suggestion!
--Guido
On 6/12/07, Ron Adam <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > On 6/7/07, "Martin v. Löwis" <[EMAIL PROTECTED
Guido van Rossum wrote:
> On 6/7/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> >> The os.environ.get() method probably should return a unicode
>> string. (?)
>> >
>> > Indeed -- care to contribute a patch?
>>
>> Ideally, such a patch would make use of the Win32 Unicode API for
>> environment
On 6/7/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> >> The os.environ.get() method probably should return a unicode string. (?)
> >
> > Indeed -- care to contribute a patch?
>
> Ideally, such a patch would make use of the Win32 Unicode API for
> environment variables on Windows. People had al
>> The os.environ.get() method probably should return a unicode string. (?)
>
> Indeed -- care to contribute a patch?
Ideally, such a patch would make use of the Win32 Unicode API for
environment variables on Windows. People had already been complaining
that they can't have "funny characters" in
Guido van Rossum wrote:
>> The os.environ.get() method probably should return a unicode string. (?)
>
> Indeed -- care to contribute a patch?
I thought you might ask that. :-)
It looks like os.py module imports a 'envirion' dictionary from various
sources depending on the platform.
po
On 6/7/07, Ron Adam <[EMAIL PROTECTED]> wrote:
> Martin v. Löwis wrote:
>
> > FWIW, for me the build error goes away when I unset
> > LANG, so that the error occurs during build definitely
> > *is* a locale issue.
>
> Yes, and to pin it down a bit further...
>
> This avoids the problem by setting t
Martin v. Löwis wrote:
> FWIW, for me the build error goes away when I unset
> LANG, so that the error occurs during build definitely
> *is* a locale issue.
Yes, and to pin it down a bit further...
This avoids the problem by setting the language to the default "C" which is
a unicode string and
On 6/7/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> FWIW, for me the build error goes away when I unset
> LANG, so that the error occurs during build definitely
> *is* a locale issue.
Ah! You're right. I needed to do a `make clean` before, though.
My LANG variable was set to "en_CA.UTF-8".
On 6/7/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > It's time to look at the original traceback (attached as "tb", after
> > fixing the formatting problems). it looks like any call to
> > encodings.normalize_encoding() causes this problem.
>
> One problem with normalize_encoding is that it
> I've ran across the same zero arg split error a while back when attempting
> to run 'make test'. Below was the solution I came up with. Is there going
> to be an unicode equivalent to the str.translate() method?
The unicode type supports translate since 2.0.
Regards,
Martin
> It's time to look at the original traceback (attached as "tb", after
> fixing the formatting problems). it looks like any call to
> encodings.normalize_encoding() causes this problem.
One problem with normalize_encoding is that it might do
encoding = encoding.encode('latin-1')
return '_'.jo
Guido van Rossum wrote:
> On 6/7/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
>> On 6/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>>> It's time to look at the original traceback (attached as "tb", after
>>> fixing the formatting problems). it looks like any call to
>>> encodings.n
On 6/7/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> On 6/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > It's time to look at the original traceback (attached as "tb", after
> > fixing the formatting problems). it looks like any call to
> > encodings.normalize_encoding() causes this
On 6/7/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> It's time to look at the original traceback (attached as "tb", after
> fixing the formatting problems). it looks like any call to
> encodings.normalize_encoding() causes this problem.
Don't know if it will help to know that, but it seems add
On 6/7/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
On 6/7/07, Ron Adam <[EMAIL PROTECTED]> wrote:
> Well not the bug yet, but I did find the file. :-)
>
> The following clears it so make will work.
>
> rm ./build/lib.linux-i686-3.0/_struct.so
>
> So maybe something to do with Module
On 6/7/07, Ron Adam <[EMAIL PROTECTED]> wrote:
> Well not the bug yet, but I did find the file. :-)
>
> The following clears it so make will work.
>
> rm ./build/lib.linux-i686-3.0/_struct.so
>
> So maybe something to do with Modules/_struct.c, or would it be something
> else that uses it?
R
On 6/6/07, Neal Norwitz <[EMAIL PROTECTED]> wrote:
> This probably means there is a problem with marshalling the byte code
> out. The first run compiles the .pyc files. Theoretically this
> writes out the same thing in memory. This isn't always the case
> though (ie, when there are bugs).
>
> A
Neal Norwitz wrote:
> On 6/5/07, Ron Adam <[EMAIL PROTECTED]> wrote:
>> Alexandre Vassalotti wrote:
>> > On 6/5/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> >> If "make clean" makes the problem go away, it's usually because there
>> >> were old .pyc files with incompatible byte code. We don't
On 6/5/07, Ron Adam <[EMAIL PROTECTED]> wrote:
> Alexandre Vassalotti wrote:
> > On 6/5/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >> If "make clean" makes the problem go away, it's usually because there
> >> were old .pyc files with incompatible byte code. We don't change the
> >> .pyc magi
Alexandre Vassalotti wrote:
> On 6/5/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> If "make clean" makes the problem go away, it's usually because there
>> were old .pyc files with incompatible byte code. We don't change the
>> .pyc magic number for each change to the compiler.
>
> Nope. It i
On 6/5/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> If "make clean" makes the problem go away, it's usually because there
> were old .pyc files with incompatible byte code. We don't change the
> .pyc magic number for each change to the compiler.
Nope. It is still not working. I just did the f
If "make clean" makes the problem go away, it's usually because there
were old .pyc files with incompatible byte code. We don't change the
.pyc magic number for each change to the compiler.
--Guido
On 6/5/07, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Ubuntu linux, when I try ru
Hi,
On Ubuntu linux, when I try run make in the py3k-struni branch I get
an weird error about split(). However, I don't get this error when I
run ``make clean; make''.
Thanks,
-- Alexandre
% make
Traceback (most recent call last):
File "./setup.py", line 6, in
import sys, os, imp, re, opt
38 matches
Mail list logo
