Re: [Python-Dev] another Python Bug Day?
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 development process to cut down on bad > patches, etc.). It's encouraging to hear that it's been worked on. I assume the idea is that eventually leiutenanents will maintain their own Python trees in a similar way to what happens with the Linux kernel currently? No because Python is not developed with much sense of ownership like the Linux kernel; no one owns the dict object or all of the object code. And this is not about to change either. While some modules have obvious owners (eg I would defer to Raymond for itertools stuff if I wasn't sure of the best solution), the code base overall is considered "owned" by all of python-dev equally. An interim solution that occurred to me is to give a few more people enhanced access to the issue tracker We have slowly started to do this although we could probably expand this more than we have. and to create a ready-for-committing keyword that these new issue wranglers could apply to bugs that have patches and which they think are ready for committing. Already done; the Stage field takes care of this with the "commit review" stage. It also makes it more clear what is needed which could be helpful for Bug Days. If people feel comfortable writing tests, for instance, they could (theoretically) just look for issues at the Test Needed stage. But the field is so new that it is not consistently used yet. Probably going to need the docs on how the issue workflow is supposed to work before that happens. Actual committers could then come along and search for the given keyword to find things to examine for committing. This would also act as testing ground for potential developers -- once committers feel that the patches an issue wrangler approves really are consistently good enough, they can consider promoting the issue wrangler to a full developer. Right, that is one of the hopes of having more people have the Developer role on the issue tracker. This process just needs to get written down (which I am slowly doing; see http://www.python.org/dev/setup/ as the start of the docs I plan to write to document all of this). -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] another Python Bug Day?
-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, writing up docs on the development process to cut down on bad patches, etc.). It's encouraging to hear that it's been worked on. I assume the idea is that eventually leiutenanents will maintain their own Python trees in a similar way to what happens with the Linux kernel currently? FWIW, this is possible today. http://www.python.org/dev/bazaar/ (This really should go in the wiki so it's easier to update and so we can add information for other DVCSes.) (Note that this is experimental, and you'll still have to convince a core developer to commit your branch.) (Still, please experiment!) parenthetical-ly y'rs, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSWPn6XEjvBPtnXfVAQKq7QQAgWXtcm9zAhdnm11rAo9UhtDtEa1yBqi8 +Z7JYfUcKL+IQI0sCuCHzY6VNNoCMsbondtWavVH3/y9xO4ySq+HrylUzgSH6Gu/ b0E1UZiRQsV33hhhG/0WupEdBd18wTRLipesjNqY7DA1+iI8KbXYD7QwYjJYRXDv PDBI4DpWZWE= =yTlQ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] another Python Bug Day?
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 to hear that it's been worked on. I assume the idea is that eventually leiutenanents will maintain their own Python trees in a similar way to what happens with the Linux kernel currently? An interim solution that occurred to me is to give a few more people enhanced access to the issue tracker and to create a ready-for-committing keyword that these new issue wranglers could apply to bugs that have patches and which they think are ready for committing. Actual committers could then come along and search for the given keyword to find things to examine for committing. This would also act as testing ground for potential developers -- once committers feel that the patches an issue wrangler approves really are consistently good enough, they can consider promoting the issue wrangler to a full developer. Schiavo Simon ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] another Python Bug Day?
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 are not enough people with commit > access taking part. > 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.). -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] address manipulation in the standard lib
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" merger idea, a page on the Wiki is probably a > better idea. A PEP isn't necessary for addition of an existing 3rd party library to the stdlib. However a PEP would be useful if the plan is to design a new API (even if it's a merger of two existing ones). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] another Python Bug Day?
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 what exactly that means. > > ;) Well, it's an opportunity to fix some bugs and, with some luck, get the patches committed the same day. Also, there are developers around to answer questions about the process, etc. Rapid feedback => good. Malte ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] another Python Bug Day?
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/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Documentation of Slicings in 3.0
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 myself that the docmentation ever covers sequence slicing. I'm not sufficiently confident of this to post as a bug, so I decided to post here first. -- --- Mitchell L Model ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #ifdef __cplusplus?
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 whole process isn't a particularly nice thing to do. Kristján -Original Message- From: M.-A. Lemburg [mailto:m...@egenix.com] Sent: 6. janúar 2009 14:43 To: Kristján Valur Jónsson Cc: mhamm...@skippinet.com.au; python-dev@python.org Subject: Re: [Python-Dev] #ifdef __cplusplus? 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 the MS CRT, only Python ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #ifdef __cplusplus?
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 the MS CRT, only Python ;-) > 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: 6. janúar 2009 13:23 > To: mhamm...@skippinet.com.au > Cc: python-dev@python.org > Subject: Re: [Python-Dev] #ifdef __cplusplus? > > 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 >> Windows - http://bugs.python.org/issue4804 > > Does this only affect asserts defined in the CRT or also ones defined > in the Python C code ? (I was only referring to the latter) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2009) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Small question about BufferedRandom spec
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 meaningful, semantics. > Ditto for the flush call currently implied by a seek -- if you can > satisfy the seek by moving where you are in the buffer without > flushing, that's fine IMO, but it should be well documented. That's also part of what I've tried to optimize. The documentation is currently in the limbs, though. Thanks! Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #ifdef __cplusplus?
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: 6. janúar 2009 13:23 To: mhamm...@skippinet.com.au Cc: python-dev@python.org Subject: Re: [Python-Dev] #ifdef __cplusplus? 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 > Windows - http://bugs.python.org/issue4804 Does this only affect asserts defined in the CRT or also ones defined in the Python C code ? (I was only referring to the latter) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] another Python Bug Day?
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 mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] #ifdef __cplusplus?
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 > Windows - http://bugs.python.org/issue4804 Does this only affect asserts defined in the CRT or also ones defined in the Python C code ? (I was only referring to the latter) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jan 06 2009) >>> Python/Zope Consulting and Support ...http://www.egenix.com/ >>> mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] r68182 - in python/trunk: Lib/decimal.py Misc/NEWS
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('NaN') might be
handy for some users (though I actually suspect that the
intersection between Decimal users and those who care about
NaNs is rather small...), but they don't belong in the decimal
module, which is supposed to be kept very close to the standard
and, exactly as you say, keep the beyond-the-spec API small.
Maybe it's time for the "Add a decimal_utils module" PEP,
which could contain such constants? There are many
other definitions and conveniences that could go into such a module.
One thing in particular that I miss is a sqrt() *function* (as
opposed to Decimal method) that takes a Decimal, int or long
and returns a Decimal; similarly for exp, log, log10, ...
Another thing that has been requested recently on c.l.p.
is good implementations of trig functions for Decimal, which
are quite hard to do properly.
Mark
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] address manipulation in the standard lib
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. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
