On Jan 6, 2009 3:18pm, Simon Cross wrote:
On Tue, Jan 6, 2009 at 9:47 PM, Brett Cannon br...@python.org> wrote:
> This is a years-old problem that is not going to be fixed overnight
> (unfortunately). But it is known and is being worked on (moving to a
> DVCS, writing up docs on the developme
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jan 6, 2009, at 6:18 PM, Simon Cross wrote:
On Tue, Jan 6, 2009 at 9:47 PM, Brett Cannon wrote:
This is a years-old problem that is not going to be fixed overnight
(unfortunately). But it is known and is being worked on (moving to a
DVCS, writi
On Tue, Jan 6, 2009 at 9:47 PM, Brett Cannon wrote:
> This is a years-old problem that is not going to be fixed overnight
> (unfortunately). But it is known and is being worked on (moving to a
> DVCS, writing up docs on the development process to cut down on bad
> patches, etc.).
It's encouraging
On Mon, Jan 5, 2009 at 23:13, Simon Cross wrote:
> If there's going to be another bug day, I'd like to see the problem of
> getting patches from the bug tracker into Python addressed in some
> way. It's kinda frustrating to work on things and not actually get to
> close any issues because there a
On Tue, Jan 6, 2009 at 12:27 AM, Nick Coghlan wrote:
> DrKJam wrote:
>> Is this post long enough to be a candidate for a PEP?!
>
> A PEP will likely be needed eventually for the actual addition to the
> standard library - while the respective parties are still working on the
> "best of both worlds
Ulrich Eckhardt wrote:
> On Monday 05 January 2009 23:48:13 Malte Helmert wrote:
>> For people who are not core developers but would still like to
>> contribute, the Bug Days are quite exciting events. It would be great if
>> they could keep going.
>
> As a not core developer, I would like to know
2009/1/6 Simon Cross :
> It'd also be nice if there could be some committers around on IRC to
All those who are working in the bug day, should be in #python-dev
during the work...
--
.Facundo
Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/
_
The section of the documentation on slicings in 3.0 is substantially
different than in previous versions, including 2.6. In particular it
states that "The primary must evaluate to a maping object." I've
followed the grammar and the commentary around through a few paths
and cannot convince myse
Well, a lot of those asserts have to do with correct use of the crt (and cpprt)
For example, all of the iterator debugging for STL was disabled in our product
When run with python embedded, and I found some issues when I reenabled the crt
assertions. Python messing with the crt behavior for the who
On 2009-01-06 15:15, Kristján Valur Jónsson wrote:
> Only crt asserts, and those assertion features accessible through the
> file, such as _ASSERT and _ASSERTE.
Thanks.
In that case, I don't see much of a problem... after all, if someone
runs a Python debug build, they won't be trying to debug
Guido van Rossum python.org> writes:
>
> However, the semantics of interleaving
> reads and writes, with and without seek calls in between, should be
> well-defined and correct/useful, so that it behaves the same
> regardless of the buffer size.
Yes, the goal is to have reasonably intuitive, and
Only crt asserts, and those assertion features accessible through the
file, such as _ASSERT and _ASSERTE.
Kristj'an
-Original Message-
From: python-dev-bounces+kristjan=ccpgames@python.org
[mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf Of M.-A.
Lemburg
Sent
Simon Cross gmail.com> writes:
> It'd also be nice if there could be some committers around on IRC to
> have fast interactions with or perhaps to coordinate things
I was going to suggest #python-dev but I see you're already there...
___
Python-Dev m
On 2009-01-05 23:17, Mark Hammond wrote:
> On 5/01/2009 11:13 PM, M.-A. Lemburg wrote:
>
>> See above. Assertions are not meant to be checked in a production
>> build. You use debug builds for debugging such low-level things.
>
> Although ironically, assertions have been disabled in debug builds
On Mon, Jan 5, 2009 at 3:12 PM, Jim Jewett wrote:
> Our of curiousity, why are these constants for internal use only?
I don't think anyone ever thought about deliberately making them
public---I suspect they were introduced as a speed optimization.
I can see that having things like NaN = Decimal(
DrKJam wrote:
> Is this post long enough to be a candidate for a PEP?!
A PEP will likely be needed eventually for the actual addition to the
standard library - while the respective parties are still working on the
"best of both worlds" merger idea, a page on the Wiki is probably a
better idea.
Ch
16 matches
Mail list logo
