Hi,
Currently 2to3 page at http://wiki.python.org/moin/2to3 lists
http://svn.python.org/view/sandbox/trunk/2to3 as a repository for 2to3
tool. There is also an outdated repository at http://hg.python.org/
and the page says that the code is finally integrated into CPython 2.6
- you can see it at
ht
On Wed, Mar 23, 2011 at 03:12, Stephen J. Turnbull wrote:
> No, software engineering scales up to a point, then it breaks and you
> need a serialization scheme. The problem is not the DVCS, it's the
> demand for a *centralized*, authoritative, safe, stable version. DVCS
> can scale at least to L
On Wed, Mar 23, 2011 at 04:39, wrote:
>
> Dirkjan> The right solution here is to use different clones for
> Dirkjan> different projects/areas. The proposed interpreter/stdlib
> Dirkjan> split, for example, might reduce contention (although I imagine
> Dirkjan> it would reduce it only
On Tue, Mar 22, 2011 at 22:12, Steven D'Aprano wrote:
> The main one that comes to my mind is that other than looping, any time I
> want to process dict.items() etc I often need to call list() first.
"Process" no. If you want it to be a list, yes. This is because they
now return generators, which
Steven D'Aprano, 22.03.2011 22:12:
anatoly techtonik wrote:
I didn't touch Python3 until PyCon, and my first user experience is
not really good. I've got a feeling that Python3 became more ugly,
because it doesn't allow me to think about the logic anymore, and
requires more low-level workarounds
Nick> Now, consider my own current hg setup ...
This is the first soup-to-nuts description of an individual setup I've seen.
Is it documented somewhere? If not, could you maybe add it as a complete
example to the developer's guide? I have the local setup similar to what
you describe, but ha
Martin> Yes, it will turn into a giant bowl of spaghetti - that's the
Martin> whole point of "Distributed" version control systems.
skip> No, you don't understand. Just the repositories I will have to
skip> deal with will turn into a big bowl of spaghetti. I could care
skip>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/23/2011 4:30 AM, Stephen J. Turnbull wrote:
> Antoine Pitrou writes:
>
> > Now, "hg strip" should definitely be absent of any recommended or even
> > suggested workflow. It's a power user tool for the experimented
> > developer/admin. Not the
Greg Ewing wrote:
Steven D'Aprano wrote:
The main one that comes to my mind is that other than looping, any
time I want to process dict.items() etc I often need to call list()
first.
I don't think that's such a bad thing. It makes it clear that
you're performing a more expensive operation th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/22/2011 11:05 PM, Barry Warsaw wrote:
> On Mar 23, 2011, at 07:31 AM, Nick Coghlan wrote:
>
>> On Wed, Mar 23, 2011 at 4:25 AM, Barry Warsaw wrote:
>>> It probably wouldn't be a bad idea to add a very fast "smoke test" for the
>>> case where you
Lennart Regebro wrote:
On Tue, Mar 22, 2011 at 22:12, Steven D'Aprano wrote:
The main one that comes to my mind is that other than looping, any time I
want to process dict.items() etc I often need to call list() first.
"Process" no. If you want it to be a list, yes. This is because they
now r
On Wed, Mar 23, 2011 at 12:39, John Arbash Meinel
wrote:
> Just as an aside, and I might be wrong. But reading through what strip
> does, (and from my knowledge of the disk layout) it can't actually be
> atomic. So if you kill it at the wrong time, it will have corrupted your
> repository.
>
> At
On Wed, Mar 23, 2011 at 8:53 PM, wrote:
>
> Nick> Now, consider my own current hg setup ...
>
> This is the first soup-to-nuts description of an individual setup I've seen.
> Is it documented somewhere? If not, could you maybe add it as a complete
> example to the developer's guide? I have t
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 3/23/2011 1:23 PM, Dirkjan Ochtman wrote:
> On Wed, Mar 23, 2011 at 12:39, John Arbash Meinel
> wrote:
>> Just as an aside, and I might be wrong. But reading through what strip
>> does, (and from my knowledge of the disk layout) it can't actually b
On Wed, Mar 23, 2011 at 9:45 PM, John Arbash Meinel
wrote:
> I don't specifically know what is in those 340 tests, but 18min/340 =
> 3.2s for each test. Which is *much* longer than simple smoke tests would
> have to be.
The counts Barry is referring to there are actually counting test
*files*, ra
On Tue, Mar 22, 2011 at 9:57 PM, anatoly techtonik wrote:
> For example, now I need to remember that on Windows I need to flush
> output every time when I want the result of print() with end!='\n' to
> appear on the screen immediately. And for the most of my legacy
> scripts I used end='\n' when I
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 22/03/11 18:38, Jesus Cea wrote:
> Most of our problems are related to trying to keep a lineal history, and
> races with pull-patch-commit-push cycle. I propose the following workflow.
The points of my proposal are:
1. The hg.python.org repository
On Wed, 23 Mar 2011 12:30:17 +0900
"Stephen J. Turnbull" wrote:
> Antoine Pitrou writes:
>
> > Now, "hg strip" should definitely be absent of any recommended or even
> > suggested workflow. It's a power user tool for the experimented
> > developer/admin. Not the average hg command.
>
> So wha
On Wed, 23 Mar 2011 22:49:39 +1000
Nick Coghlan wrote:
> On Wed, Mar 23, 2011 at 9:45 PM, John Arbash Meinel
> wrote:
> > I don't specifically know what is in those 340 tests, but 18min/340 =
> > 3.2s for each test. Which is *much* longer than simple smoke tests would
> > have to be.
>
> The cou
Le mercredi 23 mars 2011 à 22:58 +1000, Nick Coghlan a écrit :
> There are several ways to get unbuffered IO back in a cross-platform
> manner, but efficient codec operation means working that way by
> default would be a really bad idea. Users may *say* they prefer
> convenience over speed, but tha
On Wed, Mar 23, 2011 at 11:30 PM, Antoine Pitrou wrote:
> On Wed, 23 Mar 2011 12:30:17 +0900
> "Stephen J. Turnbull" wrote:
>> Antoine Pitrou writes:
>>
>> > Now, "hg strip" should definitely be absent of any recommended or even
>> > suggested workflow. It's a power user tool for the experiment
On Wed, Mar 23, 2011 at 11:31 PM, Antoine Pitrou wrote:
> On Wed, 23 Mar 2011 22:49:39 +1000
> Nick Coghlan wrote:
>> On Wed, Mar 23, 2011 at 9:45 PM, John Arbash Meinel
>> wrote:
>> > I don't specifically know what is in those 340 tests, but 18min/340 =
>> > 3.2s for each test. Which is *much*
Hey Barry,
> Python sort of has that, but I guess it depends on your definition of "fast"
> :). Here are my run times.
>
> 'make quicktest': 18m
> 'make test' : 30m
> 'make testall' : 35m
Please take a look at http://docs.python.org/devguide/runtests.html
and learn about the -j option ;)
> Oops, lost a bit too much context when I changed the thread title.
>
> This discussion started with Barry looking for a "smoke test" that
> would be quick enough to run that more people would be willing to use
> it to pick up gratuitous breakage due to a bad merge rather than
> leaving it for t
On Mar 23, 2011, at 02:31 PM, Antoine Pitrou wrote:
>Does anyone use "make quicktest" for something useful?
Not currently. Can it be made useful? Should it be removed?
>There is a reason the regression test suite has many tests...
>"Blacklisting" some of them sounds like a bad thing to do.
If
Le mercredi 23 mars 2011 à 22:58 +1000, Nick Coghlan a écrit :
> There are several ways to get unbuffered IO back in a cross-platform
> manner, ...
Oh, by the way: TextIOWrapper doesn't support unbuffered mode. Only
fully buffered and line buffered modes. So print("Test", end='') doesn't
display i
On Mon, 21 Mar 2011 21:50:53 -0400
Doug Hellmann wrote:
> We are nearly ready to launch the new blog for python-dev.
Is any core dev allowed to post on this blog? (how?)
Or is there an editorial team dedicated to writing posts?
Regards
Antoine.
___
On Wed, 23 Mar 2011 09:53:37 -0400
Barry Warsaw wrote:
> OTOH, running
> some localized test for the feature or bug you're trying to land might be
> enough.
Might indeed. Quite often, though, some change in a library affects
another one (especially when we're talking about things like socket
or t
Hi all,
Currently I worked out a patch for http://bugs.python.org/issue9523,
which adds full support of Collections.MutableMapping interface to ndbm and
gdbm objects, as well as . And thanks for eric doing reviews mainly on
python code and doc! Could someone do a review on the C code? Thanks ve
On Wed, Mar 23, 2011 at 11:53 PM, Barry Warsaw wrote:
> In any case 'make quicktest' isn't really being honest with us . We
> should fix it or remove it.
It took about 11 minutes wall clock time for me. One thing I noticed
is that it does the "run it twice to ensure the .pyc files are there
the
On Thu, Mar 24, 2011 at 12:08 AM, Antoine Pitrou wrote:
> Really, people already don't run the test suite enough before
> committing/pushing (and ironically these same people often don't check
> the buildbots afterwards). I don't think we want to promote more laxism.
Encouraging a step up from "n
On Wed, Mar 23, 2011 at 10:03 AM, Antoine Pitrou wrote:
> On Mon, 21 Mar 2011 21:50:53 -0400
> Doug Hellmann wrote:
>> We are nearly ready to launch the new blog for python-dev.
>
> Is any core dev allowed to post on this blog? (how?)
> Or is there an editorial team dedicated to writing posts?
>
On Wed, Mar 23, 2011 at 11:52 PM, Antoine Pitrou wrote:
>> Currently even "make quicktest" takes too long to run to be suitable
>> for that task. Leaving out a couple more egregiously slow tests and
>> possibly updating it to use the "-j" switch might make for a usable
>> option.
>
> "-j" will pre
Le jeudi 24 mars 2011 à 00:31 +1000, Nick Coghlan a écrit :
> On Wed, Mar 23, 2011 at 11:52 PM, Antoine Pitrou wrote:
> >> Currently even "make quicktest" takes too long to run to be suitable
> >> for that task. Leaving out a couple more egregiously slow tests and
> >> possibly updating it to use
In IRC Antoine suggested -j5 (note that -j is not compatible with -l so you
have to override TESTOPTS not just EXTRATESTOPTS). Adding --slow here's what
I get:
$ make TESTOPTS="-j5 --slow" quicktest
...
10 slowest tests:
test_mmap: 221.6s
test_shelve: 184.4s
test_posix: 156.3s
test_largefile: 150
On Tue, Mar 22, 2011 at 2:12 PM, Michael Foord
wrote:
> On 22/03/2011 07:21, Mark Hammond wrote:
>
> Hi all,
> I've made some changes to the draft PEP and checked it into the PEP
> repository as PEP397. The reference implementation is currently being
> tracked at http://bugs.python.org/issue116
On Thu, 24 Mar 2011 00:31:46 +1000
Nick Coghlan wrote:
> On Wed, Mar 23, 2011 at 11:52 PM, Antoine Pitrou wrote:
> >> Currently even "make quicktest" takes too long to run to be suitable
> >> for that task. Leaving out a couple more egregiously slow tests and
> >> possibly updating it to use the
Antoine> Does anyone use "make quicktest" for something useful?
I don't use it at all.
Antoine> There is a reason the regression test suite has many tests...
Antoine> "Blacklisting" some of them sounds like a bad thing to do.
+1.
Eliminating tests based on the time it takes to run
On Thu, Mar 24, 2011 at 12:36 AM, Antoine Pitrou wrote:
> You mean in the "-j" option itself or in "make test"?
I was actually suggesting that -j be the *default* in regrtest itself,
with an option to turn it off or force a particular number of
processes.
Cheers,
Nick.
--
Nick Coghlan | nc
On Mar 23, 2011, at 03:08 PM, Antoine Pitrou wrote:
>On Wed, 23 Mar 2011 09:53:37 -0400
>Barry Warsaw wrote:
>> OTOH, running
>> some localized test for the feature or bug you're trying to land might be
>> enough.
>
>Might indeed. Quite often, though, some change in a library affects
>another one
On Mar 24, 2011, at 12:29 AM, Nick Coghlan wrote:
>Entirely independent of the "make quicktest" question, it would be
>nice if the default behaviour of regrtest was updated to check the
>number of cores a machine has and default to using that many processes
>(leaving people to turn it down if they
The __reduce__ protocol doesn't provide for keyword arguments to the
constructor.
Some constructor arguments are only available as keyword arguments. Annoying,
isn't it?
K
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman
On Mar 23, 2011, at 02:52 PM, Antoine Pitrou wrote:
>Then many people will start running the "smoke test" rather than the
>whole suite, which will create new kinds of problems. It's IMO a bad
>idea. Let Barry learn about "-j" :)
Well, that's a social problem, not a technical problem.
(See other
On 23/03/2011 14:52, Mike Driscoll wrote:
On Tue, Mar 22, 2011 at 2:12 PM, Michael Foord
wrote:
On 22/03/2011 07:21, Mark Hammond wrote:
Hi all,
I've made some changes to the draft PEP and checked it into the PEP
repository as PEP397. The reference implementation is currently being
tracke
On Wed, 23 Mar 2011 10:44:30 -0400
Barry Warsaw wrote:
> In IRC Antoine suggested -j5 (note that -j is not compatible with -l so you
> have to override TESTOPTS not just EXTRATESTOPTS). Adding --slow here's what
> I get:
>
> $ make TESTOPTS="-j5 --slow" quicktest
> ...
> 10 slowest tests:
> test
Mike Driscoll wrote:
On Tue, Mar 22, 2011 at 2:12 PM, Michael Foord
wrote:
On 22/03/2011 07:21, Mark Hammond wrote:
Hi all,
I've made some changes to the draft PEP and checked it into the PEP
repository as PEP397. The reference implementation is currently being
tracked at http://bugs.python
On Mar 23, 2011, at 10:02 AM, s...@pobox.com wrote:
>Eliminating tests based on the time it takes to run them suggests that the
>resulting smaller test run may have considerably different overall coverage
>quality than you might desire. Some tests (syntax, basic arithmetic, etc)
>probably run bla
On Wed, 23 Mar 2011 11:18:50 -0400
Barry Warsaw wrote:
>
> This is just the opposite. I'm not saying people shouldn't run the full(-ish)
> test suite before committing, I'm saying we should have a really fast minimal
> set of tests as a smoke test when dealing with push-races.
That's completely
Antoine> Please take a look at
Antoine> http://docs.python.org/devguide/runtests.html and learn about
Antoine> the -j option ;)
I just gave it a try. Several tests failed:
test_builtin test_distutils test_imp test_peepholer test_pydoc
test_unicode test_unittest
OTOH, when I
On Wed, 23 Mar 2011 11:26:13 -0400
Barry Warsaw wrote:
> On Mar 23, 2011, at 02:52 PM, Antoine Pitrou wrote:
>
> >Then many people will start running the "smoke test" rather than the
> >whole suite, which will create new kinds of problems. It's IMO a bad
> >idea. Let Barry learn about "-j" :)
>
Barry> If I disable down to and including test_concurrent_futures,
Barry> quicktest runs in 3m20s wall clock. *That's* what I'm talkin'
Barry> 'bout!
How do you know you didn't eliminate the most important tests? (That is,
the stuff which tests the code which is currently the most f
On Wed, 23 Mar 2011 11:10:29 -0500
s...@pobox.com wrote:
>
> Antoine> Please take a look at
> Antoine> http://docs.python.org/devguide/runtests.html and learn about
> Antoine> the -j option ;)
>
> I just gave it a try. Several tests failed:
>
> test_builtin test_distutils test_i
On Mar 23, 2011, at 05:16 PM, Antoine Pitrou wrote:
>If we start promoting a "quicker" way of running tests, then nobody
>will use the normal way. I'm sorry, I'm -1 on that. There are
>regressions often enough on the buildbots.
I'm not sure it's worth continuing this thread. I've explained that
Barry> Not if you keep in mind the appropriate use case for each of the
Barry> separate make test targets.
Programmers are lazy. They will often take the shortest path. Fix a small
bug in module X which seems innocent enough, fail to recognize that it
breaks module Y. Run "make smokete
Antoine> If we start promoting a "quicker" way of running tests, then
Antoine> nobody will use the normal way. I'm sorry, I'm -1 on
Antoine> that. There are regressions often enough on the buildbots.
It seems I frequently disagree with Antoine about various things, but on
this I am de
On Mar 23, 2011, at 05:09 PM, Antoine Pitrou wrote:
>That's completely bogus. There's no reason to believe that a push race would
>favour certain regressions over certain others. Again, you need the full test
>suite to assert that no regressions occured. (or you might as well run 10
>tests at ran
s...@pobox.com wrote:
Barry> Not if you keep in mind the appropriate use case for each of the
Barry> separate make test targets.
Programmers are lazy. They will often take the shortest path. Fix a small
bug in module X which seems innocent enough, fail to recognize that it
breaks modul
On Wed, Mar 23, 2011 at 10:39 AM, Ethan Furman wrote:
> Mike Driscoll wrote:
>>
>> On Tue, Mar 22, 2011 at 2:12 PM, Michael Foord
>> wrote:
>>>
>>> On 22/03/2011 07:21, Mark Hammond wrote:
>>>
>>> Hi all,
>>> I've made some changes to the draft PEP and checked it into the PEP
>>> repository as P
On Mar 23, 2011, at 10:03 AM, Antoine Pitrou wrote:
> On Mon, 21 Mar 2011 21:50:53 -0400
> Doug Hellmann wrote:
>> We are nearly ready to launch the new blog for python-dev.
>
> Is any core dev allowed to post on this blog? (how?)
> Or is there an editorial team dedicated to writing posts?
Bot
On Wed, 23 Mar 2011 10:25:01 -0700
Ethan Furman wrote:
>
> I think the use-case has been lost. Think sprints and multiple push
> races. No one is arguing that the smoke-test should be the default, but
> seriously, are you willing to spend an hour or more re-running the
> complete suite of te
Le mercredi 23 mars 2011 à 13:19 -0400, Doug Hellmann a écrit :
> On Mar 23, 2011, at 10:03 AM, Antoine Pitrou wrote:
>
> > On Mon, 21 Mar 2011 21:50:53 -0400
> > Doug Hellmann wrote:
> >> We are nearly ready to launch the new blog for python-dev.
> >
> > Is any core dev allowed to post on this
Michael Foord wrote:
To be honest I would be happy with registry entries instead as the
alternative implementations can then add to their installers (or provide
a script) to add the right registry entry.
I'm partial to the config file method myself. I have this vague hope
where this tool cou
On 23/03/2011 17:26, Antoine Pitrou wrote:
Le mercredi 23 mars 2011 à 13:19 -0400, Doug Hellmann a écrit :
On Mar 23, 2011, at 10:03 AM, Antoine Pitrou wrote:
On Mon, 21 Mar 2011 21:50:53 -0400
Doug Hellmann wrote:
We are nearly ready to launch the new blog for python-dev.
Is any core dev a
Hi Antoine
It does work with your Google account, so no need for a registration with a new
service.
Regards
Paulo
PS: I'm a member of the PSF communications team, supervised by Doug. Joined the
list in order to follow discussions in the list and be able to report and help
with blog postings.
On 23/03/2011 01:30, Mark Hammond wrote:
On 23/03/2011 6:12 AM, Michael Foord wrote:
On 22/03/2011 07:21, Mark Hammond wrote:
Hi all,
I've made some changes to the draft PEP and checked it into the PEP
repository as PEP397. The reference implementation is currently being
tracked at http://bugs.
On Mar 23, 2011, at 1:26 PM, Antoine Pitrou wrote:
> Le mercredi 23 mars 2011 à 13:19 -0400, Doug Hellmann a écrit :
>> On Mar 23, 2011, at 10:03 AM, Antoine Pitrou wrote:
>>
>>> On Mon, 21 Mar 2011 21:50:53 -0400
>>> Doug Hellmann wrote:
We are nearly ready to launch the new blog for pyth
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/23/2011 01:24 PM, Antoine Pitrou wrote:
> On Wed, 23 Mar 2011 10:25:01 -0700
> Ethan Furman wrote:
>>
>> I think the use-case has been lost. Think sprints and multiple push
>> races. No one is arguing that the smoke-test should be the default
My Intel Snow Leopard buildbot failed again last night.
Here's what I see in twistd.log. Any of this look familiar to some one?
Failed at about 19:58 (PST?). I don't see any reason for these
failures, but they seem to happen about once a week. This is the
standard Snow Leopard Python 2.6.1, and
Thank you, Michael and Brian (on IRC) for your answers.
Regards
Antoine.
On Wed, 23 Mar 2011 13:40:56 -0400
Paulo Nuin wrote:
> Hi Antoine
>
> It does work with your Google account, so no need for a registration with a
> new service.
>
> Regards
> Paulo
>
___
On Wed, 23 Mar 2011 13:58:31 -0400
Tres Seaver wrote:
>
> That doesn't work so well at a sprint, where the point is to maximize
> the value of precious face-time to get stuff done *now*. Long test
> latencies and nearly-real-time collaboration are not friendly, as the
> agile folks document:
>
Nick Coghlan writes:
> On Thu, Mar 24, 2011 at 12:36 AM, Antoine Pitrou wrote:
>> You mean in the "-j" option itself or in "make test"?
>
> I was actually suggesting that -j be the *default* in regrtest itself,
> with an option to turn it off or force a particular number of
> processes.
Just on
On Wed, 23 Mar 2011 14:29:22 -0400
David Bolen wrote:
> Nick Coghlan writes:
>
> > On Thu, Mar 24, 2011 at 12:36 AM, Antoine Pitrou
> > wrote:
> >> You mean in the "-j" option itself or in "make test"?
> >
> > I was actually suggesting that -j be the *default* in regrtest itself,
> > with an o
On 03/21/2011 11:35 PM, "Martin v. Löwis" wrote:
If people then complain about too much fine-grainedness, we could
tighten it again.
Hi to all for the first time,
I'm new to this list. First of all I would like to thank all you for the
great software and ideas you produce.
I found this
On 23/03/2011 18:42, Antoine Pitrou wrote:
On Wed, 23 Mar 2011 14:29:22 -0400
David Bolen wrote:
Nick Coghlan writes:
On Thu, Mar 24, 2011 at 12:36 AM, Antoine Pitrou wrote:
You mean in the "-j" option itself or in "make test"?
I was actually suggesting that -j be the *default* in regrtes
Le mercredi 23 mars 2011 à 18:51 +, Michael Foord a écrit :
> On 23/03/2011 18:42, Antoine Pitrou wrote:
> > On Wed, 23 Mar 2011 14:29:22 -0400
> > David Bolen wrote:
> >> Nick Coghlan writes:
> >>
> >>> On Thu, Mar 24, 2011 at 12:36 AM, Antoine Pitrou
> >>> wrote:
> You mean in the "-
I've posted a very preliminary Python 3.3 release schedule as PEP 398.
The final release is set to be about 18 months after 3.2 final, which
is in August 2012.
For 3.3, I'd like to revive the tradition of listing planned large-scale
changes in the PEP. Please let me know if you plan any such chan
On 3/23/2011 11:23 AM, Kristján Valur Jónsson wrote:
The __reduce__ protocol doesn‘t provide for keyword arguments to the
constructor.
Some constructor arguments are only available as keyword arguments.
Annoying, isn‘t it?
I suspect it is ;-).
If you think this could be changed and are ready t
Hi Georg,
On 03/23/2011 03:56 PM, Georg Brandl wrote:
> For 3.3, I'd like to revive the tradition of listing planned large-scale
> changes in the PEP. Please let me know if you plan any such changes,
> at any time. (If they aren't codified in PEP form, we should think about
> whether they should
On 3/23/2011 8:58 AM, Nick Coghlan wrote:
On Tue, Mar 22, 2011 at 9:57 PM, anatoly techtonik wrote:
Python 3 actually chose *cross-platform consistency* over user
convenience when switching away from the platform IO implementations.
Given that print acted differently on *nix and Windows, th
On 23.03.2011 18:10, Barry Warsaw wrote:
> On Mar 23, 2011, at 05:09 PM, Antoine Pitrou wrote:
>
>>That's completely bogus. There's no reason to believe that a push race would
>>favour certain regressions over certain others. Again, you need the full test
>>suite to assert that no regressions occu
On Wed, Mar 23, 2011 at 7:24 PM, Antoine Pitrou wrote:
> On Wed, 23 Mar 2011 10:25:01 -0700
> Ethan Furman wrote:
>>
>> I think the use-case has been lost. Think sprints and multiple push
>> races. No one is arguing that the smoke-test should be the default, but
>> seriously, are you willing to
>>> I think the use-case has been lost. Think sprints and multiple push
>>> races.
Tres> That doesn't work so well at a sprint, where the point is to
Tres> maximize the value of precious face-time to get stuff done *now*.
How about everybody pushes (without testing, or with, at
On Wed, Mar 23, 2011 at 13:01, Steven D'Aprano wrote:
> But the improvement is exactly what Anatoly is talking about: it's an
> improvement in speed over user convenience. If all you are doing is
> iterating over a moderately-sized dictionary, you probably don't care
> whether items() etc. returns
On Thu, Mar 24, 2011 at 5:56 AM, Georg Brandl wrote:
> For 3.3, I'd like to revive the tradition of listing planned large-scale
> changes in the PEP. Please let me know if you plan any such changes,
> at any time. (If they aren't codified in PEP form, we should think about
> whether they should
On Thu, Mar 24, 2011 at 00:12, Nick Coghlan wrote:
> On Thu, Mar 24, 2011 at 5:56 AM, Georg Brandl wrote:
> > For 3.3, I'd like to revive the tradition of listing planned large-scale
> > changes in the PEP. Please let me know if you plan any such changes,
> > at any time. (If they aren't codif
On Thu, Mar 24, 2011 at 7:07 AM, Georg Brandl wrote:
> On 23.03.2011 18:10, Barry Warsaw wrote:
>> On Mar 23, 2011, at 05:09 PM, Antoine Pitrou wrote:
>>
>>>That's completely bogus. There's no reason to believe that a push race would
>>>favour certain regressions over certain others. Again, you ne
On Thu, Mar 24, 2011 at 6:13 AM, Terry Reedy wrote:
> Could speed ever really be an issue for print to screen?
Definitely, especially on Windows. Just minimising the console window
can speed up a Windows console app enormously.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisb
On 23/03/2011 19:56, Georg Brandl wrote:
I've posted a very preliminary Python 3.3 release schedule as PEP 398.
The final release is set to be about 18 months after 3.2 final, which
is in August 2012.
For 3.3, I'd like to revive the tradition of listing planned large-scale
changes in the PEP. P
Hi,
If nobody complains, I plan to push my faulthandler module into Python
3.3 in one week. It's a module to display the Python backtrace on a
segfault, on a user signal or after a timeout.
I opened an issue (#11393) for that, 3 weeks ago, and I already got some
interesting comments. I fixed some
> What is the procedure to add a new module? Just add the code into
> Modules and patch setup.py? The module is distributed under the BSD
> (2-clause) license.
Also add it to the Visual Studio build process. It either needs to go
into pythonXY.dll (i.e. pythoncore.vcproj), or into a separate proje
On 24/03/2011 00:05, "Martin v. Löwis" wrote:
What is the procedure to add a new module? Just add the code into
Modules and patch setup.py? The module is distributed under the BSD
(2-clause) license.
Also add it to the Visual Studio build process. It either needs to go
into pythonXY.dll (i.e. py
On 24/03/2011 4:34 AM, Ethan Furman wrote:
Michael Foord wrote:
To be honest I would be happy with registry entries instead as the
alternative implementations can then add to their installers (or
provide a script) to add the right registry entry.
I'm partial to the config file method myself. I
Le jeudi 24 mars 2011 à 01:05 +0100, "Martin v. Löwis" a écrit :
> > What is the procedure to add a new module? Just add the code into
> > Modules and patch setup.py? The module is distributed under the BSD
> > (2-clause) license.
>
> Also add it to the Visual Studio build process. It either needs
Le mercredi 23 mars 2011 à 20:56 +0100, Georg Brandl a écrit :
> For 3.3, I'd like to revive the tradition of listing planned large-scale
> changes in the PEP. Please let me know if you plan any such changes,
> at any time. (If they aren't codified in PEP form, we should think about
> whether the
On Wed, Mar 23, 2011 at 8:14 PM, Mark Hammond wrote:
> If you guys (or anyone) would like to agree on some precise rules for both
> the location of the config file and its contents and express this as a patch
> to the PEP text, I have no problem supporting it in the implementations.
> I'd like to
Tres Seaver writes:
> On 03/23/2011 01:24 PM, Antoine Pitrou wrote:
> > On Wed, 23 Mar 2011 10:25:01 -0700
> > Ethan Furman wrote:
> >>
> >> I think the use-case has been lost. Think sprints and multiple push
> >> races.
I do, can't speak for others. So what? *sigh* ... read on.
> > W
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23/03/11 20:56, Georg Brandl wrote:
> For 3.3, I'd like to revive the tradition of listing planned large-scale
> changes in the PEP.
I want to integrate dependence injection in the stdlib, specially in
libs creating sockets. This would be an option
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 22/03/11 22:20, Nick Coghlan wrote:
> There's a third option (which is what I've been doing):
>
> 6. Pull
> 7. Merge the heads on the oldest branch that now has multiple heads
> 8. Merge that branch to the next branch in line as usual.
> 9. Repeat
On 24/03/2011 02:06, Jesus Cea wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23/03/11 20:56, Georg Brandl wrote:
For 3.3, I'd like to revive the tradition of listing planned large-scale
changes in the PEP.
I want to integrate dependence injection in the stdlib, specially in
libs crea
On 24/03/2011 02:06, Jesus Cea wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 23/03/11 20:56, Georg Brandl wrote:
For 3.3, I'd like to revive the tradition of listing planned large-scale
changes in the PEP.
I want to integrate dependence injection in the stdlib, specially in
libs crea
1 - 100 of 106 matches
Mail list logo
