Jeffrey Yasskin wrote:
> On 10/11/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
>> if (mangled == "utf8")
>
> FYI, this is always going to be false. It compares the pointer values,
> rather than the strings.
Doh! I've done too much Python programming in the past. I forgot that
I've to use s
Dnia 11-10-2007, Cz o godzinie 13:11 -0700, Gregory P. Smith pisze:
> Are there OSes and filesystems out there that'd store in anything
> other than one of the popular codecs (UTF-8, 16, 32, latin1, mbcs)?
I've been using ISO-8859-2 by default on my Linux until February 2007.
Most filenames were
Greg Ewing wrote:
> How about just using ascii if the codec system isn't fully
> operational? It would just mean that files needed during
> bootstrapping would need to have pure-ascii filenames,
> which doesn't seem like a serious restriction.
The file names aren't the issue but the directory name
Christian Heimes wrote:
> I like to perform
>
> filename = PyString_AsDecodedObject(filename,
> Py_FileSystemDefaultEncoding ? Py_FileSystemDefaultEncoding : "UTF-8",
> NULL);
>
> in order to decode the string with either the fs encoding or UTF-8 but
> it's not possible. It's way too early in the
Gregory P. Smith wrote:
> Should a pep3118 buffer api supporting object that produces a length 1
> buffer also work for append and remove?
My thought is -- only if such an object is also usable in
any *other* context expecting an integer. And I don't think
that would be a good idea at all.
You c
Gregory P. Smith wrote:
> Thats pretty much what Christian pondered at the start of this thread but
> with a defined "failure" mode.
>
> +1 from me, give it a try and see what 3.0a2 testers say. Are there OSes
> and filesystems out there that'd store in anything other than one of the
> popular co
On 10/11/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> On 10/11/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> > Guido van Rossum wrote:
> > > Um, where does the filename object in that expression come from? It
> > > appears to be a PyString object. Who created it? That could should be
> >
On 10/11/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Um, where does the filename object in that expression come from? It
> > appears to be a PyString object. Who created it? That could should be
> > changed to create a PyUnicode instead (using the filesystem encodi
Fred Drake wrote:
> hotshot should no longer be a problem for this.
Thanks Fred!
Unfortunately the anon svn server is down again. It's the second time
this week. Something must be wrong with the Apache server for
svn.python.org.
Christian
___
Python-30
On Oct 11, 2007, at 11:21 AM, Christian Heimes wrote:
> PS: The patch for __file__ and co_filename is causing a minor problem
> with the hotspot profiler and filenames. I remember a plan to remove
> hotspot from Python 3.x. Shall I leave the problem alone?
hotshot should no longer be a problem for
Guido van Rossum wrote:
> Um, where does the filename object in that expression come from? It
> appears to be a PyString object. Who created it? That could should be
> changed to create a PyUnicode instead (using the filesystem encoding).
Python/compile.c:makecode()
filename = PyString_FromString(
Um, where does the filename object in that expression come from? It
appears to be a PyString object. Who created it? That could should be
changed to create a PyUnicode instead (using the filesystem encoding).
On 10/11/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Hm
Guido van Rossum wrote:
> Please file this in the bug tracker.
>
> Thanks for finding this -- I kew there was a problem with the debugger
> losing control but I never traced it down to the with statement!
Already done! http://bugs.python.org/issue1265
Christian
__
Guido van Rossum wrote:
> Hm, can't we make co_filename a PyUnicode instance?
I already did it in my patch but doesn't it cause a problem when the
encoding isn't UTF-8? I may understand
PyUnicode_FromString(PyString_AS_STRING(filename)) wrong. Doesn't it
decode filename from UTF-8?
Christian
Hm, can't we make co_filename a PyUnicode instance?
On 10/11/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> Hello Python!
>
> I've written a patch that removes basestring from py3k:
> http://bugs.python.org/issue1258 During the testing of the patch I hit a
> problem with __file__ and codeobject
On 10/11/07, Fred Drake <[EMAIL PROTECTED]> wrote:
> On Oct 11, 2007, at 11:21 AM, Christian Heimes wrote:
> > PS: The patch for __file__ and co_filename is causing a minor problem
> > with the hotspot profiler and filenames. I remember a plan to remove
> > hotspot from Python 3.x. Shall I leave th
Please file this in the bug tracker.
Thanks for finding this -- I kew there was a problem with the debugger
losing control but I never traced it down to the with statement!
On 10/11/07, Christian Heimes <[EMAIL PROTECTED]> wrote:
> I found a pretty annoying bug caused by with blocks. A with block
On Oct 11, 2007, at 11:21 AM, Christian Heimes wrote:
> PS: The patch for __file__ and co_filename is causing a minor problem
> with the hotspot profiler and filenames. I remember a plan to remove
> hotspot from Python 3.x. Shall I leave the problem alone?
I asked about the removal of hotshot a fe
I found a pretty annoying bug caused by with blocks. A with block
terminates the debugging session and the program keeps running. It's not
possible to go to the next line with 'n'. 's' steps into the open() call.
# pdbtest.py
import pdb
pdb.set_trace()
print("before with")
with open("/etc/passwd")
PS: The patch for __file__ and co_filename is causing a minor problem
with the hotspot profiler and filenames. I remember a plan to remove
hotspot from Python 3.x. Shall I leave the problem alone?
___
Python-3000 mailing list
Python-3000@python.org
http:
Hello Python!
I've written a patch that removes basestring from py3k:
http://bugs.python.org/issue1258 During the testing of the patch I hit a
problem with __file__ and codeobject.co_filename. Both __file__ and
co_filename are byte strings and not unicode which is causing some
trouble. Guido asked
Okay, here's another patch:
http://bugs.python.org/issue1263
Using unicode-string-eq-false-r3.patch, str8/str comparison will now
return False instead of attempting to convert. Unfortunately this breaks
about 30 tests. In attempting to fix test_unicode (the obvious starting
point for all this)
Guido van Rossum wrote:
> On 10/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
>> Which reminds me of a task I forgot to add to the list:
>>
>> - change the constructor for PyString to match the one for PyBytes.
>>
>
> And another pair of forgotten tasks:
>
> - change PyBytes so that i
I was having weird problems with the codec registry too - specifically
the assertion checking unidata_version == "3.2.0" mysteriously failing
after forcing string/unicode equality checks to return false. Thought
maybe unidata_version somehow got a str8 version or something weird like
that ... h
Guido van Rossum wrote:
>
> The point is that a bytes and a str instance are never considered equal...
>
>
Sorry. I understand now. My brain must have been on a holiday earlier.
:) Just pushed an updated patch to the bug tracker.
>> str8() == str() -> False
>> str8() != str() -> True
>>
>> Corr
Guido van Rossum wrote:
>>>
- make == and != between PyBytes and PyUnicode return False instead of
raising TypeError
Just thinking about it I'm pretty sure my initial patch is wrong -
forgive my ignorance. To remove the ambiguity, is it fair to state the
follow
On 10/11/07, Gregory P. Smith <[EMAIL PROTECTED]> wrote:
>
> Guido -
>
> One tiny question has come up while working on this one:
>
> Should the PyBytes buffer (mutable bytes) object's .append(val) and
> .remove(val) methods accept anything other than an int in the 0..255 range?
>
> I believe the a
Guido -
One tiny question has come up while working on this one:
Should the PyBytes buffer (mutable bytes) object's .append(val) and
.remove(val) methods accept anything other than an int in the 0..255 range?
I believe the answer to be no based on the previous long thread on this but
these two w
28 matches
Mail list logo
