>>> OTOH, IDLE ran w/o this error in p3yk...
>> Yes. Somebody would have to study what precisely the problem is: is it
>> that there is a None key in that dictionary, and that you must not use
>> None as a tag name? In that case: where does the None come from?
>> Or else: is it that you can use Non
I wonder if a lot of the refleaks may have the same cause as this one:
b'\xff'.decode("utf8", "ignore")
No leaks jumped out at me. Here is the rest of the leaks that have
been reported so far. I don't know how many have the same cause.
test_multibytecodec leaked [72, 72, 72] references, sum=
Georg Brandl schrieb:
> Well, subject says it all. While 2.5 sets sys.std*.encoding correctly to
> UTF-8, 3k sets it to 'latin-1', breaking output of Unicode strings.
And not surprisingly so: io.py says
if encoding is None:
# XXX This is questionable
encoding = sys
On 8/9/07, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Neal Norwitz schrieb:
> > On 8/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >> This is done. The new py3k branch is ready for business.
> >>
> >> Left to do:
> >>
> >> - switch the buildbot and the doc builder to use the new branch (Neal)
Neal Norwitz schrieb:
> On 8/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> This is done. The new py3k branch is ready for business.
>>
>> Left to do:
>>
>> - switch the buildbot and the doc builder to use the new branch (Neal)
Shouldn't there be a py3k buildbot at http://www.python.org/dev/
On 8/9/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> This is done. The new py3k branch is ready for business.
>
> Left to do:
>
> - switch the buildbot and the doc builder to use the new branch (Neal)
I've updated to use the new branch. I got the docs building, but
there are many more problem
Well, subject says it all. While 2.5 sets sys.std*.encoding correctly to
UTF-8, 3k sets it to 'latin-1', breaking output of Unicode strings.
Georg
--
Thus spake the Lord: Thou shalt indent with four spaces. No more, no less.
Four shall be the number of spaces thou shalt indent, and the number of
Joel Bender wrote:
> Jason Orendorff wrote:
>
>> Hooks would help with that, or even eliminate the need altogether.
>
> IMHO, having a __bytes__ method would go a long way.
This would be better done with generic functions once we have them.
I general, I feel it's better not to embed knowledge o
Greg Ewing wrote:
> Ron Adam wrote:
>> The way to think of 'repr' and 'str' is that of a general "object" format
>> type/specifier. That puts str and repr into the same context as the rest
>> of the format types. This is really a point of view issue and not so much
>> of a semantic one. I t
I'm just getting back from vacation and trying to catch up. I think
I've caught the sense of the discussion, but forgive me if I haven't.
Talin wrote:
> The reason is that for some types, the __format__ method can define its
> own interpretation of the format string which may include the letter
Ron Adam wrote:
> The way to think of 'repr' and 'str' is that of a general "object" format
> type/specifier. That puts str and repr into the same context as the rest
> of the format types. This is really a point of view issue and not so much
> of a semantic one. I think {0:r} and {0:s} are t
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
>> OTOH, IDLE ran w/o this error in p3yk...
>
> Yes. Somebody would have to study what precisely the problem is: is it
> that there is a None key in that dictionary, and that you must not use
> None as a tag name? In that case: where does the None come
Ron Adam wrote:
> Would some sort of an indirect reference type help. Possibly an
> object_id_based_reference as keys instead of using or hashing the object
> itself? This wouldn't change if the object mutates between accesses and
> could be immutable.
But if the object did mutate, the cached
Martin v. Löwis wrote:
> Perhaps using "I suggest" instead of asking "why not" would
> have clued me; English is not my native language, and I take
> questions as literally asking something.
Well, it's really a suggestion and a question. If
there's some reason the suggestion is a bad idea,
there's
> Talin wrote:
>>In other words, other than the special case of 'repr', we find that
>>pretty much everything can fit into a single specifier string;
I think there might still be merit in separating the
field width and alignment spec, at least syntactically,
since all format specs will have it an
>> I'm not convinced. The actual failure is that "tag configure" is invoked
>> with a None tagname (which then gets stripped through flatten, apparently).
>
> OTOH, IDLE ran w/o this error in p3yk...
Yes. Somebody would have to study what precisely the problem is: is it
that there is a None key i
On 8/9/07, Kurt B. Kaiser <[EMAIL PROTECTED]> wrote:
> "Martin v. Löwis" <[EMAIL PROTECTED]> writes:
>
> > I'm not convinced. The actual failure is that "tag configure" is invoked
> > with a None tagname (which then gets stripped through flatten, apparently).
>
> OTOH, IDLE ran w/o this error in p3
I've checked a band-aid fix for this (r56878). The band-aid works by
pre-importing the latin-1 codec (and also the utf-8 codec, just to be
sure) *before* setting sys.stdout and sys.stderr (this happens in
site.py, in installnewio()).
This is a horrible hack though, and only works because, as long
Martin v. Löwis wrote:
> Jason Orendorff schrieb:
>> On 8/7/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>>> My concern is that people need to access existing databases. It's
>>> all fine that the code accessing them breaks, and that they have
>>> to actively port to Py3k. However, telling th
"Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> I'm not convinced. The actual failure is that "tag configure" is invoked
> with a None tagname (which then gets stripped through flatten, apparently).
OTOH, IDLE ran w/o this error in p3yk...
--
KBK
___
Jason Orendorff schrieb:
> On 8/9/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>>> Too true. Offhand, why not provide hooks for serializing and
>>> deserializing keys?
>
> It was just a suggestion. I wish this could occasionally
> go without saying.
Perhaps using "I suggest" instead of askin
On 8/9/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > But the reason we got here was that an AsString() call failed. Why?
>
> The only reason I can see is that PyObject_Str failed; that may happen
> if PyObject_Str fails. That, in turn, can happen for bytes objects
> if they are not UTF-8.
>
> I get the same failure on OSX (PPC) and on Linux (x86 Ubuntu). It has
> to do with the Tcl/Tk wrapping code, in particular it's in the
> LEAVE_PYTHON macro on line 1995 on _tkinter.c.
I'm not convinced. The actual failure is that "tag configure" is invoked
with a None tagname (which then gets st
> But the reason we got here was that an AsString() call failed. Why?
The only reason I can see is that PyObject_Str failed; that may happen
if PyObject_Str fails. That, in turn, can happen for bytes objects
if they are not UTF-8.
I think _tkinter should get rid of AsString, and use the Tcl objec
>> I prefer str8 which looks to be a good candidate for "frozenbytes" type.
>>
>
> I love this idea! Leave str8 as it is, maybe extend Python so that it
> understands
> the s"..." literals and we are done.
Please, no. Two string-like types with literals are enough.
Regards,
Martin
On 8/9/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> > Too true. Offhand, why not provide hooks for serializing and
> > deserializing keys?
>
> Perhaps YAGNI? We already support pickling values (dbshelve),
> and I added support for encoding/decoding strings as either
> keys or values (though
I've checked in a fix for the immediate cause of the fatal error: an
error path in PythonCmd() was passign through the LEAVE_PYTHON macro
twice. This bug was present even on the trunk, where I fixed it too
(and probably in 2.5 as well, but I didn't check).
But the reason we got here was that an As
Jason Orendorff schrieb:
> On 8/7/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> My concern is that people need to access existing databases. It's
>> all fine that the code accessing them breaks, and that they have
>> to actively port to Py3k. However, telling them that they have to
>> represe
On 8/9/07, Victor Stinner <[EMAIL PROTECTED]> wrote:
> re module uses a dictionary to store compiled expressions and the key is a
> tuple (pattern, flags) where pattern is a bytes (str8) or str and flags is an
> int.
So why not just skip caching for anything that doesn't hash()? If
you're really
Martin v. Löwis schrieb:
>>> It's in Modules/timemodule.c, line 691:
>>> PyModule_AddObject(m, "tzname",
>>>Py_BuildValue("(zz)", tzname[0], tzname[1]));
>>>
>>> According to MSDN, tzname is a global variable; the contents is somehow
>>> derived from the TZ envir
On 8/9/07, Kurt B. Kaiser <[EMAIL PROTECTED]> wrote:
> What platform are you using? On
>
> Linux trader 2.6.18-ARCH #1 SMP PREEMPT Sun Nov 19 09:14:35 CET 2006 i686
> Intel(R) Pentium(R) 4 CPU 2.40GHz GenuineIntel GNU/Linux
>
> (and whatever GvR is running) IDLE isn't starting at all in py3k.
I
Helmut Jarausch <[EMAIL PROTECTED]> writes:
> probably, I am too impatient.
> I've just installed py3k (the new branch).
> Trying
> idle3.0
>
> I get
>
> Traceback (most recent call last):
> File "/usr/local/bin/idle3.0", line 3, in
> from idlelib.PyShell import main
> File "/usr/local/l
Victor Stinner schrieb:
>
> I prefer str8 which looks to be a good candidate for "frozenbytes" type.
>
I love this idea! Leave str8 as it is, maybe extend Python so that it
understands
the s"..." literals and we are done.
Thomas
___
Python-3000 mai
Hi,
probably, I am too impatient.
I've just installed py3k (the new branch).
Trying
idle3.0
I get
Traceback (most recent call last):
File "/usr/local/bin/idle3.0", line 3, in
from idlelib.PyShell import main
File "/usr/local/lib/python3.0/idlelib/PyShell.py", line 26, in
from .Edi
On 8/9/07, Kurt B. Kaiser <[EMAIL PROTECTED]> wrote:
>
> After a clean checkout in py3k, IDLE fails even w/o subprocess...
>
> trader ~/PYDOTORG/projects/python/branches/py3k$ ./python Lib/idlelib/idle.py
> Fatal Python error: PyEval_SaveThread: NULL tstate
> Aborted
>
> trader ~/PYDOTORG/projects/
On Thursday 09 August 2007 17:40:58 I wrote:
> My attached patch fix both bugs:
> - convert bytes to str8 in _compile() to be able to hash it
> - add a special version of escape() for bytes
My first try was buggy for this snippet code:
import re
assert type(re.sub(b'', b'', b'')) is bytes
On 8/9/07, Joel Bender <[EMAIL PROTECTED]> wrote:
> Jason Orendorff wrote:
>
> > Hooks would help with that, or even eliminate the need altogether.
>
> IMHO, having a __bytes__ method would go a long way.
I've heard this before, but there are many different, equally
attractive ways to serialize ob
On 8/9/07, Joel Bender <[EMAIL PROTECTED]> wrote:
> Jason Orendorff wrote:
> > Hooks would help with that, or even eliminate the need altogether.
>
> IMHO, having a __bytes__ method would go a long way.
Well, it would go halfway--you also need to deserialize.
__bytes__ alone would be useless.
Of
After a clean checkout in py3k, IDLE fails even w/o subprocess...
trader ~/PYDOTORG/projects/python/branches/py3k$ ./python Lib/idlelib/idle.py
Fatal Python error: PyEval_SaveThread: NULL tstate
Aborted
trader ~/PYDOTORG/projects/python/branches/py3k$ ./python
Python 3.0x (py3k:56858, Aug 9 200
Jason Orendorff wrote:
> Hooks would help with that, or even eliminate the need altogether.
IMHO, having a __bytes__ method would go a long way.
Joel
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-30
On 8/7/07, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> My concern is that people need to access existing databases. It's
> all fine that the code accessing them breaks, and that they have
> to actively port to Py3k. However, telling them that they have to
> represent the keys in their dbm disk f
Hi,
On Thursday 09 August 2007 06:07:12 Guido van Rossum wrote:
> A quick temporary hack is to use buffer(b'abc') instead. (buffer() is
> so incredibly broken that it lets you hash() even if the underlying
> object is broken. :-)
I prefer str8 which looks to be a good candidate for "frozenbytes"
This is done. The new py3k branch is ready for business.
If you currently have the py3k-struni branch checked out (at its top
level), *don't update*, but issue the following commands:
svn switch svn+ssh://[EMAIL PROTECTED]/python/branches/py3k
svn update
Only a small amount of activity shoul
I am starting now. Please, no more checkins to either p3yk ot py3k-struni.
On 8/8/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I would like to move to a new branch soon for all Py3k development.
>
> I plan to name the branch "py3k". It will be branched from
> py3k-struni. I will do one last
Georg> When will that be? I think we should then switch over to the reST
Georg> tree before you start.
Georg,
Can you remind me how to get at your new doc tree?
Skip
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/ma
Talin wrote:
> Ron Adam wrote:
>> Talin wrote:
>>> Ron Adam wrote:
Now here's the problem with all of this. As we add the widths back
into the format specifications, we are basically saying the idea of
a separate field width specifier is wrong.
So maybe it's not really
I have needed to push my stack to teach REs (don't ask), and am
taking a look at the RE code. I may be able to extend it to support
RFE 694374 and (more importantly) atomic groups and possessive
quantifiers. While I regard such things as revolting beyond belief,
they make a HELL of a difference t
>> I see why a guarantee would help, but I don't think it's necessary.
>> Just provide UCS-4 binaries only on Linux, and when somebody complains,
>> tell them to recompile Python, or to recompile your software themselves.
>
> Won't recompiling Python break every other Python program on their syste
Ron Adam wrote:
> Talin wrote:
>> Ron Adam wrote:
>>> Now here's the problem with all of this. As we add the widths back
>>> into the format specifications, we are basically saying the idea of a
>>> separate field width specifier is wrong.
>>>
>>> So maybe it's not really a separate independent
On Wed, 08 Aug 2007 07:45:57 +0200, Martin v. Löwis wrote:
>>> Now, you seem to talk about different *Linux* systems. On Linux,
>>> use UCS-4.
>>
>> Yes, that's what we want. But Python 2.5 defaults to UCS-2 (at least
>> last time I tried), while many distros have used UCS-4. If Linux
>> always u
50 matches
Mail list logo
