On 6/1/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Neal Norwitz wrote:
>
> > Any ideas?
>
> this is a recent change, so it looks like the box simply didn't get
> around to rebuild the unicodeobject module.
That shouldn't be. make distclean should be called (it was make clean
until recently).
Looks pretty good, except for 1 cjk problem:
test_codecencodings_jp
Invalid read of size 1
at 0x110AEBC3: shift_jis_2004_decode (_codecs_jp.c:642)
by 0xBFCBDB7: mbidecoder_decode (multibytecodec.c:839)
Address 0xAEC376B is 0 bytes after a block of size 3 alloc'd
at 0x4A19B7E:
Neal Norwitz wrote:
> Any ideas?
this is a recent change, so it looks like the box simply didn't get
around to rebuild the unicodeobject module.
(I'm beginning to wonder if I didn't forget to add some header file
dependencies somewhere during the stringlib refactoring, but none of the
other b
Phillip J. Eby wrote:
> At 09:53 PM 5/31/2006 +0200, Collin Winter wrote:
>>Hi Phillip,
>>
>>Do you have any opinion on this patch (http://python.org/sf/1473257),
>>which is assigned to you?
>
> I didn't know it was assigned to me. I guess SF doesn't send any
> notifications, and neither did Geo
Any ideas?
http://www.python.org/dev/buildbot/all/MIPS%20Debian%20trunk/builds/176/step-test/0
==
FAIL: test_count (test.test_unicode.UnicodeTest)
--
Traceback (
On 2-jun-2006, at 5:31, Neal Norwitz wrote:
> I was about to remove Mac/IDE scripts, but it looks like there might
> be more stuff that is OS 9 related and should be removed. Other
> possibilities look like (everything under Mac/):
>
> Demo/* this is a bit more speculative
> IDE scripts/*
>
On 6/1/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> I didn't know it was assigned to me. I guess SF doesn't send any
> notifications, and neither did Georg, so your email is the very first time
> that I've heard of it.
This is a longstanding SF bug. (One of the reasons why we should move
away
I was about to remove Mac/IDE scripts, but it looks like there might
be more stuff that is OS 9 related and should be removed. Other
possibilities look like (everything under Mac/):
Demo/* this is a bit more speculative
IDE scripts/*
MPW/*
Tools/IDE/* this references IDE scripts, so pre
M.-A. Lemburg wrote:
> Seriously, I've been using and running pybench for years
> and even though tweaks to the interpreter do sometimes
> result in speedups or slow-downs where you wouldn't expect
> them (due to the interpreter using the Python objects),
> they are reproducable and often enough h
At 09:53 PM 5/31/2006 +0200, Collin Winter wrote:
>Hi Phillip,
>
>Do you have any opinion on this patch (http://python.org/sf/1473257),
>which is assigned to you?
I didn't know it was assigned to me. I guess SF doesn't send any
notifications, and neither did Georg, so your email is the very firs
On Friday 02 June 2006 02:21, Jack Diederich wrote:
> The CCP Games CEO said they have trouble retaining talent from more
> moderate latitudes for this reason. 18 hours of daylight makes
> them a bit goofy and when the Winter Solstice rolls around they are
> apt to go quite mad.
Obviously they ne
Phillip J. Eby writes:
> Yes, I think the whole concept of inspecting for this is broken.
> *Any* function can return a generator-iterator. A generator
> function is just a function that happens to always return one.
Just following up on Phillip's comments, consider the following functions:
On Wed, May 31, 2006 at 09:10:47PM -0400, Tim Peters wrote:
> [Martin Blais]
> > I'm still looking for a benchmark that is not amazingly uninformative
> > and crappy. I've been looking around all day, I even looked under the
> > bed, I cannot find it. I've also been looking around all day as well
At 09:26 AM 6/1/2006 +, Michele Simionato wrote:
>Terry Reedy udel.edu> writes:
> > To me, another obvious way is isinstance(object, gentype) where
> > gentype = type(i for i in []) # for instance
> > which should also be in types module.
>
>No, that check would match generator objects, not ge
"Michele Simionato" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Yep, this is the crux. types.GeneratorType refers to generator objects,
> which in an improper sense are "instances" of a "generator function".
> I.e.
>
> def g(): yield 1 # this is a generator
>
> go = g() # this
"Michele Simionato" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> No, that check would match generator objects, not generators tout court.
tout court?? is not English or commonly used at least in America
> On a related notes, inspect.isfunction gives True on a generator, such
>
The S/390 buildbot should be renamed. While the URLs
buildbot generates in its email messages work, the
ones that are on the overview page don't.
Georg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
[Neal]
> This is still in Lib/test/string_tests.py:
>
> #EQ("A", "", "replace", "", "A")
> # That was the correct result; this is the result we actually get
> # now (for str, but not for unicode):
> #EQ("", "", "replace", "", "A")
>
> Is this going to be fixed?
Done
Michele Simionato wrote:
> Georg Brandl gmx.net> writes:
>>
>> > Also, should one add
>> > a GeneratorType, perhaps as a subclass of FunctionType?
>>
>> Add GeneratorType where? There is already one in the types module.
>
> Yep, this is the crux. types.GeneratorType refers to generator objects,
Georg Brandl gmx.net> writes:
>
> > Also, should one add
> > a GeneratorType, perhaps as a subclass of FunctionType?
>
> Add GeneratorType where? There is already one in the types module.
Yep, this is the crux. types.GeneratorType refers to generator objects,
which in an improper sense are "ins
Michele Simionato wrote:
> Georg Brandl gmx.net> writes:
>
>> I'd say, go ahead and write a patch including docs, and I think there's no
>> problem with accepting it (as long as it comes before beta1).
>
> I was having a look at http://docs.python.org/dev/lib/inspect-types.html
> and it would se
Georg Brandl gmx.net> writes:
> I'd say, go ahead and write a patch including docs, and I think there's no
> problem with accepting it (as long as it comes before beta1).
I was having a look at http://docs.python.org/dev/lib/inspect-types.html
and it would seem that adding isgenerator would impl
Terry Reedy udel.edu> writes:
> To me, another obvious way is isinstance(object, gentype) where
> gentype = type(i for i in []) # for instance
> which should also be in types module.
No, that check would match generator objects, not generators tout court.
On a related notes, inspect.isfunction gi
"Michele Simionato" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Neal Norwitz gmail.com> writes:
>>
>> > I wonder whether a check shouldn't just return (co_flags & 0x20),
>> > which
>> > is CO_GENERATOR.
>>
>> Makes more sense.
>
> Okay, but my point is that the final user shou
Michele Simionato wrote:
> Neal Norwitz gmail.com> writes:
>>
>> > I wonder whether a check shouldn't just return (co_flags & 0x20), which
>> > is CO_GENERATOR.
>>
>> Makes more sense.
>
> Okay, but my point is that the final user should not be expected to know
> about those implementation deta
Neal Norwitz gmail.com> writes:
>
> > I wonder whether a check shouldn't just return (co_flags & 0x20), which
> > is CO_GENERATOR.
>
> Makes more sense.
Okay, but my point is that the final user should not be expected to know
about those implementation details. The one obvious way to me is to h
26 matches
Mail list logo
