<[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>
>
> On Sat, 15 Jul 2006 00:13:35 -0400, Terry Reedy <[EMAIL PROTECTED]> wrote:
>>Other developers do the same. Periodically (once a week?), when PAT is
> ^
>
[Neal Norwitz]
> ...
> That leaves 1 unexplained failure on a Windows bot.
It wasn't my Windows bot, but I believe test_profile has failed
(rarely) on several of the bots, and in the same (or very similar)
way. Note that the failure went away on the Windows bot in question
the next time the tests
On 7/15/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Terry Reedy wrote:
> > That is the goal, but when I watched the buildbot results last spring, the
> > degree of stability (greenness) appeared to vary. Is it possible to tag
> > particular versions as a 'green' version, or the 'most recent
[EMAIL PROTECTED] wrote:
> A module with the given __future__ import could be written to expect that
> literals are unicode instances instead of str, and encode them appropriately
> when passing to modules that expect str.
Such changes might have to be reverted in Python 3, since the module
might
James Y Knight wrote:
> On Jul 15, 2006, at 3:15 PM, M.-A. Lemburg wrote:
>> Note that it also helps setting the default encoding
>> to 'unknown'. That way you disable the coercion of strings
>> to Unicode and all the places where this implicit conversion
>> takes place crop up, allowing you to tak
Stefan Rank wrote:
> Well, originally, I would have expected it to return a byte str(ing),
I'd assume unicode in, unicode out, and str in, str out, but since it's
always going to produce ASCII-range characters, it wouldn't matter.
Moot point anyway.
> BUT
> I am now converted and think it is best
On Jul 15, 2006, at 3:15 PM, M.-A. Lemburg wrote:
> Note that it also helps setting the default encoding
> to 'unknown'. That way you disable the coercion of strings
> to Unicode and all the places where this implicit conversion
> takes place crop up, allowing you to take proper action (i.e.
> expl
[EMAIL PROTECTED] wrote:
> On Sat, 15 Jul 2006 14:35:08 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> [EMAIL PROTECTED] wrote:
>>> A __future__ import would allow these behaviors to be upgraded module-by-
>>> module.
>> No it wouldn't.
>
> Yes it would! :)
>
>> __future__ works solely on the
At 03:38 PM 7/15/2006 -0300, Johan Dahlin wrote:
>In an effort to reduce the memory usage used by GTK+ applications
>written in python I've recently added a feature that allows attributes
>to be lazy loaded in a module namespace. The gtk python module contains
>quite a few attributes (around 850) o
Johan Dahlin wrote:
> My point is that I consider this to be a valid use case, the amount of
> saved memory is significan, and I could not find another way of doing
> it and still keep the gtk interface (import gtk; gtk.Button) to still be
> backwards compatible.
You may want to have a look at SI
On Sat, 15 Jul 2006 10:43:22 +0200, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]>
wrote:
>People can use [-U] to improve the Unicode support in the Python standard
>library. When they find that something doesn't work, they can study the
>problem, and ponder possible solutions. Then, they can contribu
In an effort to reduce the memory usage used by GTK+ applications
written in python I've recently added a feature that allows attributes
to be lazy loaded in a module namespace. The gtk python module contains
quite a few attributes (around 850) of which many are classes or
interfaces (150+)
Th
On Sat, 15 Jul 2006 14:35:08 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] wrote:
>>A __future__ import would allow these behaviors to be upgraded module-by-
>>module.
>
>No it wouldn't.
Yes it would! :)
>__future__ works solely on the semantics of different pieces of syntax,
On Sat, 15 Jul 2006 00:13:35 -0400, Terry Reedy <[EMAIL PROTECTED]> wrote:
>Is the following something like what you are suggesting?
Something like it, but...
>A Python Application Testing (PAT) machine is set up with buildbot and any
>needed custom scripts. Sometime after that and after 2.5
On Thu, Jul 13, 2006, Talin wrote:
>
> Actually - can we make new-style classes the default, but allow a
> way to switch to old-style classes if needed? Perhaps a command-line
> argument to set the default back to old-style?
Nope. Python 3.0 will have new-style classes as the default, but there
w
On 7/15/06, Stephen Thorne <[EMAIL PROTECTED]> wrote:
> When testing some 'real world' code using pypy, an inconsistancy with
> the way __init__ works between lists and dicts.
>
> The assumption was made when implementing __init__ for pypy that
> list.__init__ and dict.__init__ would both wipe the
On 7/14/06, Nick Maclaren <[EMAIL PROTECTED]> wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> >
> > OK, then I propose that we wait to see which things you end up having
> > to provide to sandboxed code, rather than trying to analyze it to
> > death in abstracto.
>
> However, the ORIGINAL
Jeroen Ruigrok van der Werven wrote:
>> Are you aware of http://www.python.org/dev/buildbot/ ?
>
> Yes. And it does not seem to be open for all
Ah, ok. It indeed isn't open for anonymous participation; the test
results are open for all, though.
>
>> We are not just talking about buildbots here
On 7/15/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Are you aware of http://www.python.org/dev/buildbot/ ?
Yes. And it does not seem to be open for all, but then again, any
documentation with regard to it seems to be very sparse or hidden so I
can very well be wrong here. Ah, hidden away on
Hi,
When testing some 'real world' code using pypy, an inconsistancy with
the way __init__ works between lists and dicts.
The assumption was made when implementing __init__ for pypy that
list.__init__ and dict.__init__ would both wipe the contents of the
objects, but it seems that in cpython, thi
[EMAIL PROTECTED] wrote:
>>> python -U is a failure for obvious reasons and a
>>> __future__ import is clearly better.
>> I disagree.
>
> I am surprised that you do, since I thought that Chris's conclusion was
> pretty obvious. Python -U doesn't work, even on the standard library.
Sure, it does
Jeroen Ruigrok van der Werven wrote:
> This is what Xenofarm for Pike has done for a long time now. See for
> example: http://pike.ida.liu.se/development/pikefarm/7.7.xml
>
> This is also what Bitten (http://bitten.cmlenz.net/) has implemented
> for Trac (which is one of the bug/incident trackers
Terry Reedy wrote:
> That is the goal, but when I watched the buildbot results last spring, the
> degree of stability (greenness) appeared to vary. Is it possible to tag
> particular versions as a 'green' version, or the 'most recent green
> version' worth playing with?
Don't get confused by t
On 7/14/06, Anthony Baxter <[EMAIL PROTECTED]> wrote:
> The "community buildbot" idea is a good one, although it should just
> be possible to write something for buildbot that checks out and
> builds the latest Python SVN, then installs it to a temporary
> location, then adds that location to the f
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> OK, then I propose that we wait to see which things you end up having
> to provide to sandboxed code, rather than trying to analyze it to
> death in abstracto.
However, the ORIGINAL proposal in this thread (to split off argv[0]
and/or make that and
25 matches
Mail list logo
