[Python-Dev] 2to3 status, repositories and HACKING guide

[anatoly techtonik]

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
http://hg.python.org/cpython/file/default/Lib/lib2to3. So, what
version is more up-to-date?

In svn repository there is a HACKING guide advising to use
find_pattern.py script for writing new fixer. However, there is no
find_pattern.py in CPython repository, no HACKING guide, no any
documentation about how to write fixers or description of PATTERN
format. Did I miss something?
--
anatoly t.
___
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] I am now lost - committed, pulled, merged, what is "collapse"?

[Dirkjan Ochtman]

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 Linux kernel pace if you only ask for
> centralized authoritative.  DVCS is "No Silver Bullet", it only
> helps with some accidental costs of development.  It doesn't help with
> the costs of review and testing.

Yeah, Linux employs the other solution here (which Mercurial also
uses, in fact, for development of Mercurial itself): only one person
pushes to the central repository, that person pulls from other
"staging" repositories as he is aware of changes being made.

> There are in fact problems with the current generation of DVCSes.
> Lack of plists on commits, for example.  You'd like to have a "tested"
> property, in fact two of them (one for the committer, one for the
> buildbots).  You'd like to have a "checkpoint" property, which commits
> would by default be ignored by "log" and "bisect".  You'd like to have
> an "issues" property, a list of issues applicable to this commit.  But
> again, these would only reduce accidental costs.

Mercurial does in fact have a mechanism to attach arbitrary metadata
to changesets (the extra dictionary), but there's no easy access from
the command-line. One could also argue that this is basically just a
special case of smart commit message formatting, which python-dev
already does, and could extend. (For example, Mozilla sometimes closes
their tree to general commits, but then has a CLOSED tag that can be
put in a commit message to override that.)

Cheers,

Dirkjan
___
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] I am now lost - committed, pulled, merged, what is "collapse"?

[Dirkjan Ochtman]

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 by a little bit?).
>
> How about splitting the documentation and the code into separate
> repositories (I believe that is the proper term, though perhaps "clone" is -
> Dirkjan is the expert)?

That might work. I guess the stdlib/interpreter split should also
think about how to split up the docs.

And yes, clone might be a better word to use in this context. The
repository word is slightly overloaded, in that it can be used both
for clone, or to distinguish the .hg part from the working dir part of
a clone, for example.

> Moving onto something related, but different, I find that people bandy about
> terms which I just can't seem to find defined very well anywhere I've
> looked.  The Mercurial Glossary (http://mercurial.selenic.com/wiki/Glossary)
> would seem to be the obvious place to look, but it doesn't define the terms
> "branch" or "clone" (nor does it obviously differentiate a "named branch"
> from any other kind of "branch").  I hesitate to overload those words with
> the meanings I've acquired using Subversion and CVS, because they will
> probably be wrong in subtle ways.  Also, "rebase" is not defined in the
> glossary.

One problem with branches in DVCS is that there are so many kinds of
them. The SVN repository, for example, would now be reflected by all
of the clones of python-dev lineage (starting with the same changeset)
everywhere. Each of these clones represent a branch, in the sense that
someone can commit there and thus deviate from all other repositories.
If you commit twice from the same parent changeset in your clone, you
end up with two heads (on the same named branch), which are also
separate branches in the distributed global python-dev DAG. And all of
these are "unnamed" branches, possibly residing on the same named
branch...

> There are clearly lots of Mercurial-related documents on the web.  There is
> no editorial  review of their quality other than Google page rank.  Is there a
> prioritized list of stuff one should read?

The hg wiki is a good resource, but can be a bit disorganized. You
might also want to read the hgbook, which is slightly outdated but
should have thorough explanations. It's also available in dead-tree
form.

Cheers,

Dirkjan
___
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] Python3: speed efficiency vs user friendliness (my first experience)

[Lennart Regebro]

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 is a massive improvement.

> but what I really
> didn't expect is to see that choice is made not in user's favor, but
> in a favor of speed.

I'm not sure what choice you are talking of here... And in this case
Python 2 behaved differently on different platforms and Python 3
doesn't. That seems to be an improvement to me...

//Lennart
___
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] Python3: speed efficiency vs user friendliness (my first experience)

[Stefan Behnel]

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 even for basic user input/output.


Do you have any examples other than print?

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.
Fortunately looping is about 90% of my use-cases for the dict methods, but
the other 10% nearly always requires a list().


Sounds like Python 3 has the perfect default behaviour then.

Stefan

___
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] Submitting changes through Mercurial

[skip]

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 haven't made the mental leap to a public sandbox.

One other question.  You wrote:

Nick> My public sandbox is a server-side clone of cpython that lives at
Nick> hg.python.org/sandbox/ncoghlan I create feature branches there to
Nick> work on things that I am developing myself (when applying patches
Nick> created by others I'll work in the main repos)

What do you mean by "main repos" in this statement?  Is "repos" singular and
short for "repository" or is it the plural of "repo"?  Neither quite makes
sense to me because I guess I don't know what you mean by "main".  What
is/are the "main repos"?  hg.python.org/sandbox/ncoghlan?
hg.python.org/cpython? 

Skip
___
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] Submitting changes through Mercurial

[skip]

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> less about everything else.

Nick's message about his personal setup cleared up much of this for me.

Skip
___
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] Workflow proposal

[John Arbash Meinel]

-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 average hg command.
> 
> So what you're saying is that Mercurial by itself can't support the
> recommended workflow, because any "collapsing" of commits requires
> stripping, whether done by hg strip or implicitly by some other
> "non-average" hg command.
> 

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 least, that is from what I can tell. Which is that it has to rewrite
each file history to omit the revisions you are stripping, and then
rewrite the revision history to do the same. It would be possible to be
'stable' if you wrote a write-ahead-log and did all the work on the
side, and then any client that tries to read or write to the repository
finishes up the steps. But the individual file histories refer to the
global revision history (by index), so you don't have a 'top-down' view
that makes it all atomic by changing the top level object to point to
the new lower level objects.

It is possible that they only rewrite the revisions file, leaving blanks
for the old references. But the statement "it rewrites the numbers"
means it is collapsing the offsets in the index.
http://mercurial.selenic.com/wiki/Strip

I definitely would be very leery of putting that in any sort of
recommended documentation. It also makes me understand more why hg folks
value having "hg check" run very quickly...

John
=:->
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2J2/0ACgkQJdeBCYSNAAPFCACfeGHMB3/td31EuyateqzcoNFx
87sAoKxDt8i1rqllHogRBMxTGUDzSsdd
=RgPe
-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] Python3: speed efficiency vs user friendliness (my first experience)

[Steven D'Aprano]

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 than just looking
at the keys.


Oh, I didn't mean to imply that it was a bad thing. But it certainly is 
less convenient.



--
Steven
___
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] I am now lost - committed, pulled, merged, what is "collapse"?

[John Arbash Meinel]

-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 get tripped up on the merge dance floor.  When that happens,
>>> you could run your localized tests, and then a set of tests that run in 
>>> just a
>>> minute or two.
>>
>> What would such a smoke test cover, though? It's hard to think of
>> anything particularly useful in the middle ground between "Can you run
>> regrtest *at all*?" and "make quicktest".
> 
> make quicktest runs 340 tests, and I'm certain many don't need to be run in a
> smoke test.  E.g. 
> 
> test_aifc
> test_colorsys
> test_concurrent_futures
> (that's as far as it's gotten so far ;)
> 
> Or you could time each individual test, choose a cut off for total test run
> and then run whatever you can within that time (on some reference machine).
> Or maybe just remove the longest running 50% of the quick tests.
> 
> -Barry

bzr can run its 30,000 tests in about 15-30min depending on your
specific hardware and platform (it also supports parallel running of the
test suite). I think it takes about 1hr running single-threaded on
Windows because "os.rename()" is a fairly slow operation and we do it a
lot in most tests (it is part of our locking primitive).


Unit-tests (tests directly on a function without setting up lots of
external state) generally can execute in milliseconds.

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.

John
=:->
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2J3WUACgkQJdeBCYSNAAMI2ACgl6obH9WKlmRiK4K4ib1g6SR7
KqkAn1LNrlBaUTf/sc5s30tZq3F3hmNl
=DtQ8
-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] Python3: speed efficiency vs user friendliness (my first experience)

[Steven D'Aprano]

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 return generators, which is a massive improvement.


Well, yes, that's what I meant when I said other than looping. (I'm 
aware that there are uses for lazy iterators other than for-loops.)


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 a list or an iterator. But if you want to 
take those items away and do something with them, you need a list, and 
that's ever-so-slightly less convenient now than it was.


To be clear, I'm *not* objecting to this state of affairs. I think the 
trade-off in this case is the right thing to do. But Anatoly seems to 
think that Python3 has generally made the wrong trade-off, and I was 
hoping he would mention some other concrete examples.



For the record, this next double-quoted >> statement is not by me. It 
was actually from Anatoly Techtonik:



but what I really
didn't expect is to see that choice is made not in user's favor, but
in a favor of speed.


I'm not sure what choice you are talking of here... And in this case
Python 2 behaved differently on different platforms and Python 3
doesn't. That seems to be an improvement to me...



Lennart, please be a little more careful with your attributions.




--
Steven
___
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] Workflow proposal

[Dirkjan Ochtman]

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 least, that is from what I can tell. Which is that it has to rewrite
> each file history to omit the revisions you are stripping, and then
> rewrite the revision history to do the same. It would be possible to be
> 'stable' if you wrote a write-ahead-log and did all the work on the
> side, and then any client that tries to read or write to the repository
> finishes up the steps. But the individual file histories refer to the
> global revision history (by index), so you don't have a 'top-down' view
> that makes it all atomic by changing the top level object to point to
> the new lower level objects.

The reason that shouldn't happen is the ordering. If we strip the
changelog first (what you call the global revision history), other
clients won't be able to "find" the any file-level revisions only
referenced by the revision just stripped, so it should be atomic.

Cheers,

Dirkjan
___
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] Submitting changes through Mercurial

[Nick Coghlan]

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 the local setup similar to what
> you describe, but haven't made the mental leap to a public sandbox.

My personal setup is just a combination of two existing sections in
the devguide:
http://docs.python.org/devguide/committing.html#using-several-working-copies
http://docs.python.org/devguide/committing.html#long-term-development-of-features

I could probably skip the personal sandbox if I used Mercurial queues
to manage changes I didn't want to commit yet, but I'm currently
liking the sandbox for the offsite backup and ease of synchronisation
between my own machines.

> One other question.  You wrote:
>
>    Nick> My public sandbox is a server-side clone of cpython that lives at
>    Nick> hg.python.org/sandbox/ncoghlan I create feature branches there to
>    Nick> work on things that I am developing myself (when applying patches
>    Nick> created by others I'll work in the main repos)
>
> What do you mean by "main repos" in this statement?  Is "repos" singular and
> short for "repository" or is it the plural of "repo"?  Neither quite makes
> sense to me because I guess I don't know what you mean by "main".  What
> is/are the "main repos"?  hg.python.org/sandbox/ncoghlan?
> hg.python.org/cpython?

By "main repos" I meant the 4 local repos that I have set up to
(ultimately) push to hg.python.org/cpython. That should answer the
singular-or-plural question, too :)

So far I haven't found it necessary to use my sandbox to try out
patches - I'll just try them as uncommitted changes in my main working
copy for the relevant branch and then use "hg revert" to abandon them
if I decide not to commit them.

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

Re: [Python-Dev] Workflow proposal

[John Arbash Meinel]

-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 be
>> atomic. So if you kill it at the wrong time, it will have corrupted your
>> repository.
>>
>> At least, that is from what I can tell. Which is that it has to rewrite
>> each file history to omit the revisions you are stripping, and then
>> rewrite the revision history to do the same. It would be possible to be
>> 'stable' if you wrote a write-ahead-log and did all the work on the
>> side, and then any client that tries to read or write to the repository
>> finishes up the steps. But the individual file histories refer to the
>> global revision history (by index), so you don't have a 'top-down' view
>> that makes it all atomic by changing the top level object to point to
>> the new lower level objects.
> 
> The reason that shouldn't happen is the ordering. If we strip the
> changelog first (what you call the global revision history), other
> clients won't be able to "find" the any file-level revisions only
> referenced by the revision just stripped, so it should be atomic.
> 
> Cheers,
> 
> Dirkjan

http://mercurial.selenic.com/wiki/Strip

Thats only true if you are stripping only from the top. According to the
strip page, you also might re-order the numbers.

Also, even with stripping the changelog first, it still leaves you with
data in your repo that is going to suddenly think it is associated with
the *next* commit you do. (So I make a change to 'foo.txt' commit it,
then strip, the next commit I only change 'bar.txt'. If the strip was
canceled 'hg log foo.txt' would include the latest revision as modifying
foo.txt)

John
=:->
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2J6dYACgkQJdeBCYSNAAMQMQCfXvD4dGOVV8LB9LmtMNqXeHys
5xkAoJBWAXXVbZcCKC1GXDPjUMSNbVtn
=k1FG
-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

[Python-Dev] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

[Nick Coghlan]

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*, rather than individual tests. We only have 359 of those in
total though (not counting those in subdirectories), so a "quicktest"
that omits less than 6% of them doesn't sound particularly quick (even
if it does leave out the slowest ones).

We should probably do another pass and add a few more tests to the
blacklist in the Makefile template (starting with
test_concurrent_futures).

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

Re: [Python-Dev] Python3: speed efficiency vs user friendliness (my first experience)

[Nick Coghlan]

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 want to output some progress to user. I
> am surprised to know this never worked on Linux, but what I really
> didn't expect is to see that choice is made not in user's favor, but
> in a favor of speed. This way we'll be writing in a cross-platform
> assembly language named 'Python' soon. =)

Python 3 actually chose *cross-platform consistency* over user
convenience when switching away from the platform IO implementations.

That means things like line buffering of stdout is now the default on
all platforms, including Windows, and there is now a meaningful
distinction between files opened in binary mode (returning bytes) and
files opened in text mode (returning strings) on all platforms, rather
than *just* on Windows (where the "b" mode flag was historically
always needed to avoid corrupting binary files that happened to
contain CRLF sequences).

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 that's only true until the lack of speed
becomes intolerably slow.

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

Re: [Python-Dev] Workflow proposal

[Jesus Cea]

-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 has the branches ALWAYS merged. This
must be enforced by the push hooks.

2. We need a way to test code in the buildbots, without committing the
patch to the "real" repository.

How to do "2" and how to solve the push race in "1", are not the point
:-). I do an approach suggestion for both, just for the sake of
completeness, for I want to stress that the my actual contribution is
"1" and "2" :).

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYnwD5lgi5GaxT1NAQKxVAP7BelEjoSz91zCQodvmdP8E03pP+W6xJhR
DAwMcerrqGfV/XP45HvMk8kjwHuGQvA4jmvi+M/8QWnpJ3g3YoTR7ADHzzpF1ngq
Fx0D3bAxwPFJQhiEMbFOrH3v5+9vbo5T26pUHUlDbF+/rcEY82m7GWAv4QqmceQ8
nbJ3PETIYf8=
=m9qH
-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] Workflow proposal

[Antoine Pitrou]

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 what you're saying is that Mercurial by itself can't support the
> recommended workflow, because any "collapsing" of commits requires
> stripping,

Not really. It requires that you either:
- work on your long-term features in a separate repo (and produce a
  diff at the end that you will apply to the main repo)
- use mq
- use a non-committing equivalent of mq (iterate on a patch which you
  periodically save with "hg di", for example; that's what I do for
  most patches)

Apparently some of you think "collapsing" should involve some specific
hg command. It doesn't. Perhaps the devguide should be rephrased there.

Regards

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] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

[Antoine Pitrou]

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 counts Barry is referring to there are actually counting test
> *files*, rather than individual tests. We only have 359 of those in
> total though (not counting those in subdirectories), so a "quicktest"
> that omits less than 6% of them doesn't sound particularly quick (even
> if it does leave out the slowest ones).
> 
> We should probably do another pass and add a few more tests to the
> blacklist in the Makefile template (starting with
> test_concurrent_futures).

Does anyone use "make quicktest" for something useful?
There is a reason the regression test suite has many tests...
"Blacklisting" some of them sounds like a bad thing to do.

Regards

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] Python3: speed efficiency vs user friendliness (my first experience)

[Victor Stinner]

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 that's only true until the lack of speed
> becomes intolerably slow.

Amaury proposed in the issue (#11633) that print does flush if the end
option is used. I vote +0, but only if we do that for the default file
(sys.stdout).

I only vote +0 because I think that it is easy to modify the code to add
a explicit call to sys.stdout.flush(). Sorry, but programming is hard:
you have to learn things! A better idea would be to *document* that
print() may not display immediatly the message if it doesn't contain a
newline (eg. if end=''), and give the solution (sys.stdout.flush()).

Victor

___
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] Workflow proposal

[Nick Coghlan]

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 experimented
>>  > developer/admin. Not the average hg command.
>>
>> So what you're saying is that Mercurial by itself can't support the
>> recommended workflow, because any "collapsing" of commits requires
>> stripping,
>
> Not really. It requires that you either:
> - work on your long-term features in a separate repo (and produce a
>  diff at the end that you will apply to the main repo)
> - use mq
> - use a non-committing equivalent of mq (iterate on a patch which you
>  periodically save with "hg di", for example; that's what I do for
>  most patches)
>
> Apparently some of you think "collapsing" should involve some specific
> hg command. It doesn't. Perhaps the devguide should be rephrased there.

What you've written here would actually make a pretty good start on a
definition of what we mean by collapsing changesets.

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

Re: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

[Nick Coghlan]

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* longer than simple smoke tests would
>> > have to be.
>>
>> The counts Barry is referring to there are actually counting test
>> *files*, rather than individual tests. We only have 359 of those in
>> total though (not counting those in subdirectories), so a "quicktest"
>> that omits less than 6% of them doesn't sound particularly quick (even
>> if it does leave out the slowest ones).
>>
>> We should probably do another pass and add a few more tests to the
>> blacklist in the Makefile template (starting with
>> test_concurrent_futures).
>
> Does anyone use "make quicktest" for something useful?
> There is a reason the regression test suite has many tests...
> "Blacklisting" some of them sounds like a bad thing to do.

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 the buildbots to discover.

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.

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

[Python-Dev] python -m test -jN

[Antoine Pitrou]

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 ;)

(on a dual-core 4-thread machine:

./python -m test -j4
[...]
600.34user 26.36system 4:13.44elapsed 247%CPU (0avgtext+0avgdata
871456maxresident)k 110544inputs+152624outputs
(72major+6806058minor)pagefaults 0swaps

)

Regards

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] Trimming "make quicktest"

[Antoine Pitrou]

> 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 the buildbots to discover.

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" :)

> 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 precisely help cover the duration of these long tests. By the
way, you should use a higher "-j" number than you have CPUs, since some
tests spend most of their time sleeping and waiting.

"make quicktest" already skips test_io and test_socket, which test
fundamental parts of Python. I would vote for removing "make quicktest"
rather than promote such a questionable command.

Regards

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] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

[Barry Warsaw]

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 'make quicktest' were actually quick - say could run in 1/10 the current
time, it could be used as a smoke test for merge-dance cases.  OTOH, running
some localized test for the feature or bug you're trying to land might be
enough.

In any case 'make quicktest' isn't really being honest with us .  We
should fix it or remove it.

-Barry


signature.asc
Description: 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] Python3: speed efficiency vs user friendliness (my first experience)

[Victor Stinner]

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 immediatly Test, even with "python -u".

python -u is only useful if the output is redirected to a pipe/a file,
if you would like a line buffering (instead of a full buffering).

Victor

(This email thread begins to be a little bit redundant with the issue on
the bug tracker)

___
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] new blog

[Antoine Pitrou]

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.


___
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] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

[Antoine Pitrou]

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 threading).

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.

Regards

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

[Python-Dev] Issue 9523: Ask for a review on C code

[Ray Allen]

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 very
much for help! :)

-- 
Ray Allen
Best wishes!
___
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] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

[Nick Coghlan]

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 second time" trick, so we could halve the run time right there.

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

Re: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

[Nick Coghlan]

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 "none" to "some" in a merge-dance case
would still be an improvement. And if it encourages more pre-push
testing when people aren't currently taking the time to run the full
test suite (even though they're meant to), so much the better.

And the quick test does exercise quite a few significant things like
threading, sockets and threaded import.

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 don't want to dedicate the
whole machine to the run). I keep forgetting to include the -j4 when I
run the tests manually, so the tests take nearly 4 times as long as
they need to (and of course, the test targets in the make file don't
use it at all, either).

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

Re: [Python-Dev] new blog

[Jesse Noller]

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?
>
> Regards
>
> Antoine.
>

The initial announcement is here antoine:

http://blog.python.org/2011/03/welcome-to-python-insider.html

Doug can expand more on the how: but everyone is welcome.
___
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] Trimming "make quicktest"

[Nick Coghlan]

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 precisely help cover the duration of these long tests. By the
> way, you should use a higher "-j" number than you have CPUs, since some
> tests spend most of their time sleeping and waiting.
>
> "make quicktest" already skips test_io and test_socket, which test
> fundamental parts of Python. I would vote for removing "make quicktest"
> rather than promote such a questionable command.

I'd be fine with that if we change the -j default to something other
than "1" (e.g. as I suggested elsewhere, the number of cores in the
machine).

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

Re: [Python-Dev] Trimming "make quicktest"

[Antoine Pitrou]

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 the "-j" switch might make for a usable
> >> option.
> >
> > "-j" will precisely help cover the duration of these long tests. By the
> > way, you should use a higher "-j" number than you have CPUs, since some
> > tests spend most of their time sleeping and waiting.
> >
> > "make quicktest" already skips test_io and test_socket, which test
> > fundamental parts of Python. I would vote for removing "make quicktest"
> > rather than promote such a questionable command.
> 
> I'd be fine with that if we change the -j default to something other
> than "1" (e.g. as I suggested elsewhere, the number of cores in the
> machine).

You mean in the "-j" option itself or in "make test"?


___
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] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

[Barry Warsaw]

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.0s
test_concurrent_futures: 105.0s
test_fork1: 12.0s
test_threading: 8.8s
test_signal: 8.4s
test_warnings: 8.0s
test_threaded_import: 6.1s

If I disable down to and including test_concurrent_futures, quicktest runs in
3m20s wall clock.  *That's* what I'm talkin' 'bout!  And the run time is
totally reasonable without halving the test run.  I don't think those 5
slowest tests would be missed in a smoke test.

Any objections to adding those slowest 5 tests to the blacklist, and -j5 to
quicktest for Python 3.3?

-Barry


signature.asc
Description: 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] Second draft: PEP397: Python launcher for Windows

[Mike Driscoll]

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/issue11629.
>
>
> Hey Mark,
>
> One way of supporting alternative implementations (that may not even have a
> standard install directory) is allowing configuration. e.g. config.ini
>
>     [paths]
>     ironpython = c:\Program Files\IronPython 2.7\ipy.exe
>     ironpython2.7 = c:\Program Files\IronPython 2.7\ipy.exe
>     jython = c:\Users\foobar\jython2.5\jython.exe
>
> Pythons specified in this way should be recognised in the shebang line using
> any of the formats:
>
>     #! ironpython
>     #! /usr/bin/ironpython
>     #! /usr/bin/env ironpython
>
> This would also permit alternative install locations. (And it would be nice
> if the launcher could use the config file to *automatically* do the right
> thing for the 'w' variants.)
>
> All the best,
>
> Michael
>

Oops...I accidentally sent this off-list:

The main problem I can think of for the config file is that those hard
coded paths probably won't work about 10% of the time. I install my
Python stuff in a different location then the C drive, for example.

- Mike
___
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] Trimming "make quicktest"

[Antoine Pitrou]

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 "-j" switch might make for a usable
> >> option.
> >
> > "-j" will precisely help cover the duration of these long tests. By the
> > way, you should use a higher "-j" number than you have CPUs, since some
> > tests spend most of their time sleeping and waiting.
> >
> > "make quicktest" already skips test_io and test_socket, which test
> > fundamental parts of Python. I would vote for removing "make quicktest"
> > rather than promote such a questionable command.
> 
> I'd be fine with that if we change the -j default to something other
> than "1" (e.g. as I suggested elsewhere, the number of cores in the
> machine).

http://bugs.python.org/issue11651
___
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] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

[skip]

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 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 blazingly fast and will be fully covered by a "make nanotest",
while some really important stuff (anything which forks or creates sockets)
will have very poor nanotest coverage because many of its tests cases won't
be run.  The odds that someone breaks syntax or basic arithmetic
functionality (or even changes those parts of the system) are pretty low, so
repeatedly running those tests simply because they run fast gives a false
sense of security.

Skip
___
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] Trimming "make quicktest"

[Nick Coghlan]

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   |   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

Re: [Python-Dev] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

[Barry Warsaw]

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 (especially when we're talking about things like socket
>or threading).
>
>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.

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.

-Barry


signature.asc
Description: 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] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

[Barry Warsaw]

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 don't want to dedicate the
>whole machine to the run). I keep forgetting to include the -j4 when I
>run the tests manually, so the tests take nearly 4 times as long as
>they need to (and of course, the test targets in the make file don't
>use it at all, either).

It can't without some refactoring, and you can't set EXTRATESTOPTS=-j4 either
because TESTOPTS includes -l and regrtest complains that -l and -j are
incompatible.

But I agree it would be nice if the test suite automatically took advantage of
more cores where available.

-Barry


signature.asc
Description: 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

[Python-Dev] __reduce__

[Kristján Valur Jónsson]

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/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Trimming "make quicktest"

[Barry Warsaw]

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 messages in the thread regarding -j.)

>> 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 precisely help cover the duration of these long tests. By the
>way, you should use a higher "-j" number than you have CPUs, since some
>tests spend most of their time sleeping and waiting.
>
>"make quicktest" already skips test_io and test_socket, which test
>fundamental parts of Python. I would vote for removing "make quicktest"
>rather than promote such a questionable command.

Better to rename it than remove it.  If 'quicktest' is misleading people into
running it rather than 'test' (which frankly, I doubt), then rename it
'smoketest' which seems entirely appropriate to its use case and indicates its
value in the spectrum of tests:

http://en.wikipedia.org/wiki/Smoketest

Because this also rebuilds Python if needed, I think it's entirely appropriate
for the push-race use case, where you've already extensively tested your
change with a mostly up-to-date tree and now just need to quickly verify that
Python won't crash and burn after your local merge.

-Barry


signature.asc
Description: 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] Second draft: PEP397: Python launcher for Windows

[Michael Foord]

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
tracked athttp://bugs.python.org/issue11629.


Hey Mark,

One way of supporting alternative implementations (that may not even have a
standard install directory) is allowing configuration. e.g. config.ini

 [paths]
 ironpython = c:\Program Files\IronPython 2.7\ipy.exe
 ironpython2.7 = c:\Program Files\IronPython 2.7\ipy.exe
 jython = c:\Users\foobar\jython2.5\jython.exe

Pythons specified in this way should be recognised in the shebang line using
any of the formats:

 #! ironpython
 #! /usr/bin/ironpython
 #! /usr/bin/env ironpython

This would also permit alternative install locations. (And it would be nice
if the launcher could use the config file to *automatically* do the right
thing for the 'w' variants.)

All the best,

Michael


The main problem I can think of for the config file is that those hard
coded paths probably won't work about 10% of the time. I install my
Python stuff in a different location then the C drive, for example.


The whole point of a config file is that you put the paths in there 
yourself...


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.


Michael


- Mike



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessinghttp://www.sqlite.org/different.html

___
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] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

[Antoine Pitrou]

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_mmap: 221.6s
> test_shelve: 184.4s
> test_posix: 156.3s
> test_largefile: 150.0s
> test_concurrent_futures: 105.0s
> test_fork1: 12.0s
> test_threading: 8.8s
> test_signal: 8.4s
> test_warnings: 8.0s
> test_threaded_import: 6.1s
> 
> If I disable down to and including test_concurrent_futures, quicktest runs in
> 3m20s wall clock.  *That's* what I'm talkin' 'bout!  And the run time is
> totally reasonable without halving the test run.  I don't think those 5
> slowest tests would be missed in a smoke test.
> 
> Any objections to adding those slowest 5 tests to the blacklist, and -j5 to
> quicktest for Python 3.3?

For me, the same objections as to blacklisting any tests at all.
If some tests are too slow, individual issues about them should be
opened.

Also, there may be some issues with your system.
test_mmap, test_shelve, test_posix all take 1-2 seconds each here.
Again, please open issues on the tracker.

Regards

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] Second draft: PEP397: Python launcher for Windows

[Ethan Furman]

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.org/issue11629.


Hey Mark,

One way of supporting alternative implementations (that may not even have a
standard install directory) is allowing configuration. e.g. config.ini

[paths]
ironpython = c:\Program Files\IronPython 2.7\ipy.exe
ironpython2.7 = c:\Program Files\IronPython 2.7\ipy.exe
jython = c:\Users\foobar\jython2.5\jython.exe

Pythons specified in this way should be recognised in the shebang line using
any of the formats:

#! ironpython
#! /usr/bin/ironpython
#! /usr/bin/env ironpython

This would also permit alternative install locations. (And it would be nice
if the launcher could use the config file to *automatically* do the right
thing for the 'w' variants.)

All the best,

Michael



Oops...I accidentally sent this off-list:

The main problem I can think of for the config file is that those hard
coded paths probably won't work about 10% of the time. I install my
Python stuff in a different location then the C drive, for example.


How is that a problem?  Just update your config for your locations.

~Ethan~
___
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] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

[Barry Warsaw]

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 blazingly fast and will be fully covered by a "make nanotest",
>while some really important stuff (anything which forks or creates sockets)
>will have very poor nanotest coverage because many of its tests cases won't
>be run.  The odds that someone breaks syntax or basic arithmetic
>functionality (or even changes those parts of the system) are pretty low, so
>repeatedly running those tests simply because they run fast gives a false
>sense of security.

Not if you keep in mind the appropriate use case for each of the separate make
test targets.

-Barry


signature.asc
Description: 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] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

[Antoine Pitrou]

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 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 random and call it done)

If you think that some tests are more significant than others (why?)
then perhaps we can devise a limited test suite with these tests.
But these tests should be chosen on the basis of their nature, *not* of
their runtime.

Regards

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] python -m test -jN

[skip]

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 run a simple "make test" only distutils fails.

This is on my Macbook Pro running Leopard.

Skip
___
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] Trimming "make quicktest"

[Antoine Pitrou]

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" :)
> 
> Well, that's a social problem, not a technical problem.

Isn't this whole thread about a social problem?
You are complaining that the test suite is too slow, which *is* a
social problem (the buildbots (mostly) don't care about runtime, for
example).

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.

If you insist on that, I suggest that you also vow to take care of
the buildbot fleet and individually track regressions and notify people
who are responsible for them.

Regards

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] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

[skip]

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 flaky.)

Barry> Any objections to adding those slowest 5 tests to the blacklist,
Barry> and -j5 to quicktest for Python 3.3?

Convince me that you haven't so horribly skewed the coverage that the result
is no longer meaningful.

Skip
___
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 -m test -jN

[Antoine Pitrou]

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_imp test_peepholer test_pydoc
> test_unicode test_unittest
> 
> OTOH, when I run a simple "make test" only distutils fails.

I would suggest adding the -W option to re-run the failing tests in
verbose mode, and then open individual issues about them.

Regards

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] Trimming "make quicktest"

[Barry Warsaw]

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 I'm not
promoting a quicker way of running the tests in lieu of the more thorough test
suite.  I'm looking to fill a very specific use case.

Anyway, there's issue 11651 now too.

-Barry


signature.asc
Description: 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] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

[skip]

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 smoketest" and see that all the test_X stuff
passes.  Don't notice that key test_Y tests are not even run, push, then
head out to lunch.  Come back to (hopefully) a bunch of red buildbots.
Still, it would have been good to catch that problem before heading out to
Buffalo Wild Wings to watch football players trip over sprinkler heads.

How many of us really and truly can't wait a few minutes for the test suite
to complete?  Especially once Antoine (or whoever) gets -j working properly.
There are plenty of things we can do:

* Hang out on IRC
* Update your Facebook status
* Grab a cup of coffee
* Read python-dev
* Try out a few new bass lines you heard on Pinetop Perkins' last album
  (may he RIP).

Skip

___
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] Trimming "make quicktest"

[skip]

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 definitely in agreement with him.

Skip
___
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] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

[Barry Warsaw]

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 random and call it done)

If you promote the full test suite as the thing to run when resolving merge
races, then I predict no one will run them, because doing so increases your
chances of hitting *another* push race.  This whole thread came up in the
context of trying to find a quick test you could run in that case which didn't
increase that race window.  I think the practical effect of not having a
simple, fast smoke test will be to do *less* testing when you hit the merge
race, and just let the buildbots sort it all out.  You'll probably win most of
the time anyway.

-Barry


signature.asc
Description: 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] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

[Ethan Furman]

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 module Y.  Run "make smoketest" and see that all the test_X stuff
passes.  Don't notice that key test_Y tests are not even run, push, then
head out to lunch.  Come back to (hopefully) a bunch of red buildbots.
Still, it would have been good to catch that problem before heading out to
Buffalo Wild Wings to watch football players trip over sprinkler heads.

How many of us really and truly can't wait a few minutes for the test suite
to complete?  Especially once Antoine (or whoever) gets -j working properly.


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 tests six, eight, or 12 times because of push races in 
a sprint?  I can see losing a good portion of your sprinting day.


Which tests are included in the smoketest definitely needs careful 
reviewing.


Perhaps a better solution for sprints is to clone, have the sprinters 
clone from that clone, have one person responsible for running full 
tests, have the others push to the sub-sub-clone.


~Ethan~
___
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] Second draft: PEP397: Python launcher for Windows

[Mike Driscoll]

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 PEP397.  The reference implementation is currently being
>>> tracked at http://bugs.python.org/issue11629.
>>>
>>>
>>> Hey Mark,
>>>
>>> One way of supporting alternative implementations (that may not even have
>>> a
>>> standard install directory) is allowing configuration. e.g. config.ini
>>>
>>>    [paths]
>>>    ironpython = c:\Program Files\IronPython 2.7\ipy.exe
>>>    ironpython2.7 = c:\Program Files\IronPython 2.7\ipy.exe
>>>    jython = c:\Users\foobar\jython2.5\jython.exe
>>>
>>> Pythons specified in this way should be recognised in the shebang line
>>> using
>>> any of the formats:
>>>
>>>    #! ironpython
>>>    #! /usr/bin/ironpython
>>>    #! /usr/bin/env ironpython
>>>
>>> This would also permit alternative install locations. (And it would be
>>> nice
>>> if the launcher could use the config file to *automatically* do the right
>>> thing for the 'w' variants.)
>>>
>>> All the best,
>>>
>>> Michael
>>>
>>
>> Oops...I accidentally sent this off-list:
>>
>> The main problem I can think of for the config file is that those hard
>> coded paths probably won't work about 10% of the time. I install my
>> Python stuff in a different location then the C drive, for example.
>
> How is that a problem?  Just update your config for your locations.
>
> ~Ethan~

Sorry...I thought Foord was implying that they would be defaults or
that the launcher would put them in there. I think I mis-read it.
Nevermind.

- Mike
___
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] new blog

[Doug Hellmann]

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?

Both!

If you want to write for the blog, just send me your Blogger account name so I 
can give you authorship permission. There are also a few volunteers who are 
going to be posting, but we would LOVE to have developers writing their own 
posts.

Doug

> 
> Regards
> 
> 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/doug.hellmann%40gmail.com

___
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] sprints and pushes

[Antoine Pitrou]

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 tests six, eight, or 12 times because of push races in 
> a sprint?  I can see losing a good portion of your sprinting day.

Well, keep in ming hg is a *distributed* version control system. You
don't have to push your changes right now. You can keep your changesets
for yourself, make several of them (different bug fixes, for example),
and push them (after a single merge) at the end of day.

Regards

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] new blog

[Antoine Pitrou]

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 blog? (how?)
> > Or is there an editorial team dedicated to writing posts?
> 
> Both!
> 
> If you want to write for the blog, just send me your Blogger account
> name so I can give you authorship permission.

I don't know yet if I will write for the blog (I would imagine posting
about new features or interesting fixes), but I definitely don't have a
Blogger account - and would like not to create one.

(or does it work with Google accounts)

Regards

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] Second draft: PEP397: Python launcher for Windows

[Ethan Furman]

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 could end up being a shebang-script-launching tool for 
other scripting languages as well.


~Ethan~
___
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] new blog

[Michael Foord]

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 allowed to post on this blog? (how?)
Or is there an editorial team dedicated to writing posts?

Both!

If you want to write for the blog, just send me your Blogger account
name so I can give you authorship permission.

I don't know yet if I will write for the blog (I would imagine posting
about new features or interesting fixes), but I definitely don't have a
Blogger account - and would like not to create one.

(or does it work with Google accounts)



Yep, a blogger account is a google account (and vice-versa).

Michael


Regards

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/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
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] new blog

[Paulo Nuin]

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 2011-03-23, 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 python-dev.
>>> 
>>> Is any core dev allowed to post on this blog? (how?)
>>> Or is there an editorial team dedicated to writing posts?
>> 
>> Both!
>> 
>> If you want to write for the blog, just send me your Blogger account
>> name so I can give you authorship permission.
> 
> I don't know yet if I will write for the blog (I would imagine posting
> about new features or interesting fixes), but I definitely don't have a
> Blogger account - and would like not to create one.
> 
> (or does it work with Google accounts)
> 
> Regards
> 
> 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/paulo.nuin%40gmail.com

___
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] Second draft: PEP397: Python launcher for Windows

[Michael Foord]

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.python.org/issue11629.



Hey Mark,

One way of supporting alternative implementations (that may not even
have a standard install directory) is allowing configuration. e.g.
config.ini

[paths]
ironpython = c:\Program Files\IronPython 2.7\ipy.exe
ironpython2.7 = c:\Program Files\IronPython 2.7\ipy.exe
jython = c:\Users\foobar\jython2.5\jython.exe


Hi Michael,

I'd have no problem with that in general, but how would you feel about 
letting the PEP stand as it is without this additional requirement and 
then treat this as an additional feature to be thrashed out 
separately?  I intentionally worded the PEP to specifically allow 
these kinds of features to be added outside the PEP process.


For example, I guess the name of the INI file wouldn't be config.ini, 
and I guess there might need to be a strategy to allow it to exist in 
multiple places for when users want this feature but don't have write 
access to the location of py.exe.  Then people might want it to be in 
the cwd, or in any parent of the cwd, etc... Further, it might also be 
possible to support this with simple environment variables which might 
wind up being just as (or more) reasonable (the concept of per-user 
environment variables already exist and a UI already exists for 
editing them, and it would allow different cmd-prompts to have 
different "rules" with minimal complexity) - not that I am necessarily 
advocating this - I'd just prefer the PEP to not get bogged down with 
those kinds of issues.




Well... I'd rather see the pep implemented as is than not implemented. 
On the other hand I think it would be a great shame for it to be 
implemented in a way that excludes-until-someone-else-fixes-it the other 
implementations. (i.e. I think built-in support for other 
implementations would be vastly preferable.) It's your PEP though, and 
I'm still +1 on the idea.


I'm not married to it being a config file - registry entries would be 
fine (implementations could modify their installers or ship scripts to 
create the correct entries). I'm not sure about environment variables, I 
suppose it would be ok - but modifying a single environment variable 
with multiple paths / interpreters could get icky.


All the best,

Michael


Cheers,

Mark



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
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] new blog

[Doug Hellmann]

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 python-dev.
>>> 
>>> Is any core dev allowed to post on this blog? (how?)
>>> Or is there an editorial team dedicated to writing posts?
>> 
>> Both!
>> 
>> If you want to write for the blog, just send me your Blogger account
>> name so I can give you authorship permission.
> 
> I don't know yet if I will write for the blog (I would imagine posting
> about new features or interesting fixes), but I definitely don't have a
> Blogger account - and would like not to create one.
> 
> (or does it work with Google accounts)

As far as I understand, those are the same thing. If you have a gmail address, 
you can use it to login to blogger.

Doug

___
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] sprints and pushes

[Tres Seaver]

-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, but 
>> seriously, are you willing to spend an hour or more re-running the 
>> complete suite of tests six, eight, or 12 times because of push races in 
>> a sprint?  I can see losing a good portion of your sprinting day.
> 
> Well, keep in ming hg is a *distributed* version control system. You
> don't have to push your changes right now. You can keep your changesets
> for yourself, make several of them (different bug fixes, for example),
> and push them (after a single merge) at the end of day.

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:

 http://c2.com/cgi/wiki?TestSpeed

Maybe we need to chop the problem up as:

- - Pure documentation changes never require running any test suite
  (this includes true comments in code, as well as docstrings which
  are not used to drive doctests or other tested output).

- - "core" language changes always require running the full test suite.

- - We compute an import-dependency map for the stdlib (maybe during
  build?), and add support for running tests of a named module and its
  dependents. Any non-documentation change to a stdlib module requires
  running this new kind of test against that module.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk2KNMcACgkQ+gerLs4ltQ7yCwCfbqhYut0F4L3f92mXwB5SZZ8s
qLUAoNpchNrkPPnjbXkqWDrIqW9NQdWr
=tCRR
-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] funky buildbot

[Bill Janssen]

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 whatever version of Twisted
comes with Snow Leopard, and the latest buildslave.  The machine is in a
server room with conditioned power supply and pretty good network
access.  The two other PPC machines next to it have no problems, but
they're running older versions of OS X.

Bill

[...]
2011-03-22 19:44:07-0700 [Broker,client] RunProcess._startCommand
2011-03-22 19:44:07-0700 [Broker,client]  make buildbottest TESTOPTS= 
TESTPYTHONOPTS=
2011-03-22 19:44:07-0700 [Broker,client]   in dir 
/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build (timeout 3600 secs)
2011-03-22 19:44:07-0700 [Broker,client]   watching logfiles {}
2011-03-22 19:44:07-0700 [Broker,client]   argv: ['make', 'buildbottest', 
'TESTOPTS=', 'TESTPYTHONOPTS=']
2011-03-22 19:44:07-0700 [Broker,client]  environment: {'LANG': 'en_US.UTF-8', 
'TERM': 'xterm-color', 'Apple_PubSub_Socket_Render': 
'/tmp/launch-c3R8Zl/Render', 'TMPDIR': 
'/var/folders/3M/3MMiDEqmEiGyT5q5zPW31TM/-Tmp-/', 
'VERSIONER_PYTHON_VERSION': '2.6', 'SHLVL': '1', 
'VERSIONER_PYTHON_PREFER_32_BIT': 'no', 'SSH_AUTH_SOCK': 
'/tmp/launch-Nl3TOy/Listeners', '__CF_USER_TEXT_ENCODING': '0x1F6:0:0', 'PWD': 
'/Users/buildbot/buildarea/3.x.parc-snowleopard-1/build', 'SHELL': '/bin/bash', 
'LOGNAME': 'buildbot', 'TERM_PROGRAM_VERSION': '273', 'PATH': 
'/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin', 'HOME': 
'/Users/buildbot', 'TERM_PROGRAM': 'Apple_Terminal', 'COMMAND_MODE': 
'unix2003', 'DISPLAY': '/tmp/launch-iaSAFg/org.x:0', '_': 
'/usr/local/bin/buildslave', 'USER': 'buildbot'}
2011-03-22 19:44:07-0700 [Broker,client]   closing stdin
2011-03-22 19:44:07-0700 [Broker,client]   using PTY: False
2011-03-22 19:46:17-0700 [-] sending app-level keepalive
2011-03-22 19:56:17-0700 [-] sending app-level keepalive
2011-03-22 19:58:33-0700 [Broker,client] SlaveBuilder._ackFailed: 
SlaveBuilder.sendUpdate
2011-03-22 19:58:33-0700 [Broker,client] Unhandled Error
Traceback (most recent call last):
Failure: twisted.spread.pb.PBConnectionLost: [Failure instance: 
Traceback (failure with no frames): : Connection to the other side was lost 
in a non-clean fashion.
]

2011-03-22 19:58:33-0700 [Broker,client] lost remote
2011-03-22 19:58:33-0700 [Broker,client] lost remote
2011-03-22 19:58:33-0700 [Broker,client] lost remote
2011-03-22 19:58:33-0700 [Broker,client] lost remote
2011-03-22 19:58:33-0700 [Broker,client] lost remote step
2011-03-22 19:58:33-0700 [Broker,client] stopCommand: halting current command 

2011-03-22 19:58:33-0700 [Broker,client] command interrupted, killing pid 90085
2011-03-22 19:58:33-0700 [Broker,client] trying os.kill(-pid, 9)
2011-03-22 19:58:33-0700 [Broker,client] trying process.signalProcess('KILL')
2011-03-22 19:58:33-0700 [Broker,client]  signal KILL sent successfully
2011-03-22 19:58:33-0700 [Broker,client] Lost connection to 
dinsdale.python.org:9020
2011-03-22 19:58:33-0700 [Broker,client]  will retry in 2 seconds
2011-03-22 19:58:33-0700 [Broker,client] Stopping factory 

2011-03-22 19:58:33-0700 [-] command finished with signal 9, exit code None, 
elapsedTime: 865.868813
2011-03-22 19:58:33-0700 [-] SlaveBuilder.commandComplete None
2011-03-22 19:58:35-0700 [-] Starting factory 
2011-03-22 19:58:35-0700 [-] Connecting to dinsdale.python.org:9020
2011-03-22 19:58:36-0700 [Uninitialized] Connection to dinsdale.python.org:9020 
failed: Connection Refused
2011-03-22 19:58:36-0700 [Uninitialized]  will retry in 7 seconds
2011-03-22 19:58:36-0700 [Uninitialized] Stopping factory 

2011-03-22 19:58:43-0700 [-] Starting factory 
2011-03-22 19:58:43-0700 [-] Connecting to dinsdale.python.org:9020
___
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] new blog

[Antoine Pitrou]

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
> 

___
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] sprints and pushes

[Antoine Pitrou]

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:
> 
>  http://c2.com/cgi/wiki?TestSpeed
> 
> Maybe we need to chop the problem up as:
> 
> - - Pure documentation changes never require running any test suite
>   (this includes true comments in code, as well as docstrings which
>   are not used to drive doctests or other tested output).
> 
> - - "core" language changes always require running the full test suite.
> 
> - - We compute an import-dependency map for the stdlib (maybe during
>   build?), and add support for running tests of a named module and its
>   dependents. Any non-documentation change to a stdlib module requires
>   running this new kind of test against that module.

I agree that finding ways to speedup running tests *without* reducing
the necessary coverage is the right way to go.
Part of that is obviously about optimizing the tests themselves
(something which I and others have been doing repeatedly, including the
addition of the "-j" switch).
The dependency map is another idea.

All this needs work and is therefore more difficult than blacklisting
some "slow" tests, but is much more productive in the long run.

Regards

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] Trimming "make quicktest"

[David Bolen]

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 one request - if there are changes in this direction (e.g.,
trying to make regrtest use all cores by default), please include the
ability to configure/override this for individual builders (or at
least slaves) since otherwise I won't be able to disable it.

I, for example, have cases where I may not automatically want all
cores that regrtest happens to "see" get used, as the slave is doing
other things too.  Command line options to regrtest won't help since
that's not something I, as a slave owner, can override for test
builds.

-- David

___
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] Trimming "make quicktest"

[Antoine Pitrou]

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 option to turn it off or force a particular number of
> > processes.
> 
> Just one request - if there are changes in this direction (e.g.,
> trying to make regrtest use all cores by default), please include the
> ability to configure/override this for individual builders (or at
> least slaves) since otherwise I won't be able to disable it.

I think "-j" should remain a manual setting. I've posted a patch to
enable it automatically in "make test" for convenience, but it would
be enabled for neither "-m test" nor "make buildbottest".

Regards

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] Hg: inter-branch workflow

[xiscu]

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 thread of discussion interesting and well, it's just an idea:

Why not to TAG the final feature ? May be in a “parsable”, standard form ?

Ej:

>> hg tag -m “Feature : Templates for code generation, status: Done”

So If one doesn't want to see the “in between”, a tag filter can be 
applied, or something similar …


Of course there are 2 types of info here: “private” and “public” and 
well, like in python, use some kind of “underline” for private names 
here (def _do_my_thing(self): pass)


May be can be somehow automated …

Cheers / Saludos

francis


___
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] Trimming "make quicktest"

[Michael Foord]

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 regrtest itself,
with an option to turn it off or force a particular number of
processes.

Just one request - if there are changes in this direction (e.g.,
trying to make regrtest use all cores by default), please include the
ability to configure/override this for individual builders (or at
least slaves) since otherwise I won't be able to disable it.

I think "-j" should remain a manual setting. I've posted a patch to
enable it automatically in "make test" for convenience, but it would
be enabled for neither "-m test" nor "make buildbottest".


-j doesn't pass on several of the flags to its subprocesses (e.g. 
warning settings I believe), so it shouldn't be the default. It's still 
very useful though.


All the best,

Michael

Regards

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/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
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] Trimming "make quicktest"

[Antoine Pitrou]

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 "-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 one request - if there are changes in this direction (e.g.,
> >> trying to make regrtest use all cores by default), please include the
> >> ability to configure/override this for individual builders (or at
> >> least slaves) since otherwise I won't be able to disable it.
> > I think "-j" should remain a manual setting. I've posted a patch to
> > enable it automatically in "make test" for convenience, but it would
> > be enabled for neither "-m test" nor "make buildbottest".
> 
> -j doesn't pass on several of the flags to its subprocesses (e.g. 
> warning settings I believe)

It does (should):
http://hg.python.org/cpython/file/2f4865834695/Lib/test/support.py#l1375


___
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] Python 3.3 release schedule posted

[Georg Brandl]

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 changes,
at any time.  (If they aren't codified in PEP form, we should think about
whether they should be.)

The "Candidate PEPs" I listed are those open PEPs that in my opinion have
the highest chance to be accepted and implemented for 3.3.  It is by no
means binding.

cheers,
Georg

___
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] __reduce__

[Terry Reedy]

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 to pursue it, open a 
feature request on the tracker. This is a rather busy time on pydev for 
new threads to get much attention.


--
Terry Jan Reedy


___
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 3.3 release schedule posted

[Carl Meyer]

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 be.)

Over in distutils-sig there's been extensive discussion at and since
PyCon of a built-in Python virtual-environment tool, similar to
virtualenv, targeted hopefully for 3.3. This is something that's seen
some discussion on python-dev previously; I now have a working prototype
and am working on a PEP. When the PEP is ready I'll bring it up for
discussion on python-ideas and then python-dev; anyone interested in
checking it out sooner can go read the discussions at distutils-sig.

Carl
___
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] Python3: speed efficiency vs user friendliness (my first experience)

[Terry Reedy]

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, there were *two* 
choices, not just one, for consistency: the *nix way and the Windows 
way. In this case, I think the Windows way was/is better and that the 
wrong choice was made. We could and I hope can have *both* convenience 
and consistency.


The *nix choice introduced an new within-platform inconsistency, at 
least on Windows. When a program is run from an IDLE editor window, 
print to screen remaims unbuffered. (This is true on Windows, at least. 
I have no idea about *nix, and hope someone will test the code below). 
That means that I can develop a program like this:


import time

for c in 'Similated 10 cps teletype output':
print(c,end='')
time.sleep(.1)

print()

run it, see that it works, and ship it. But apparently, is will not work 
even for Windows users who run it 'normally'.


I would prefer that IDLE not be degraded and am not sure it could be.


Users may *say* they prefer
convenience over speed, but that's only true until the lack of speed
becomes intolerably slow.


Could speed ever really be an issue for print to screen?

--
Terry Jan Reedy

___
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] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

[Georg Brandl]

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 occured.  (or you might as well run 10
>>tests at random and call it done)
> 
> If you promote the full test suite as the thing to run when resolving merge
> races, then I predict no one will run them, because doing so increases your
> chances of hitting *another* push race.  This whole thread came up in the
> context of trying to find a quick test you could run in that case which didn't
> increase that race window.  I think the practical effect of not having a
> simple, fast smoke test will be to do *less* testing when you hit the merge
> race, and just let the buildbots sort it all out.  You'll probably win most of
> the time anyway.

FWIW, +1 to this.

Georg

___
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] sprints and pushes

[Simon Cross]

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 spend an hour or more re-running the
>> complete suite of tests six, eight, or 12 times because of push races in
>> a sprint?  I can see losing a good portion of your sprinting day.

Our sprint model has been to set up a throw-away sprint repository
somewhere accessible (github, bitbucket, wherever) and have everyone
commit madly to it however they want. Afterwards a few brace souls
take the result and commit it to the master repository in a more
orderly fashion.
___
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] sprints and pushes

[skip]

>>> 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 most, Barry's smoke
test) to a sprint-specific local repository?  One or more buildbots (or
similar) can just churn away running unit tests from that repository.  When
a problem is encountered, the people resposible are going to be right there.
They don't have to slow down their mad hacking until there is a problem.
Since there will be a fair amount of communication between sprinters, the
odds of something bad and horribly hard to fix should be low.  Pushes to the
global repository from that sprint repository can happen at a more leisurely
pace and be coordinated manually.  Say, everybody breaks for {morning snack,
lunch, dinner}.  When they return from the break if the local buildbots are
green you push out to cpython, then everyone starts banging on their
keyboards again.

Skip
___
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] Python3: speed efficiency vs user friendliness (my first experience)

[Lennart Regebro]

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 a list or an iterator. But if you want to take
> those items away and do something with them, you need a list, and that's
> ever-so-slightly less convenient now than it was.

But how often are you doing things with the results from items() and
values() that doesn't involve iterating over them? Sure, you can take
a slice, but there is no point in slicing a list that comes from a
dictionary because it's not ordered, so you won't know which item you
get. You could sort them of course, but sorted() takes an iterable and
returns a list anyway.

And in what way is it more convenient to default to what you usually
don't want? In most cases you do *not* want a list. So now, you in
most cases do not get a list. Before, if  you didn't want a lite you
used d.iteritems(). Now if you want a list you use list(d.items()).

So I don't agree that this is speed over convenience. It's speed *and*
convenience. Python 3 is *more* convenient here, because the most
common usecases are the most convenient. In Python 2 it was the other
way around. It just feels inconvenient because we were used to it
being the other way around.

> Lennart, please be a little more careful with your attributions.

Sorry!

//Lennart
___
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 3.3 release schedule posted

[Nick Coghlan]

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 be.)

I would add a note about a "standardised event loop interface" -
that's a PEP idea that came up at the language summit, and LvH plans
to write it with support from the Twisted crew and others.

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

Re: [Python-Dev] Python 3.3 release schedule posted

[Thomas Wouters]

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 codified in PEP form, we should think about
> > whether they should be.)
>
> I would add a note about a "standardised event loop interface" -
> that's a PEP idea that came up at the language summit, and LvH plans
> to write it with support from the Twisted crew and others.
>

It ended up that Jim Fulton is actually writing the PEP (with input from
Twisted people and others.)

-- 
Thomas Wouters 

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
___
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] Trimming the fat from "make quicktest" (was Re: I am now lost - committed, pulled, merged, what is "collapse"?)

[Nick Coghlan]

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 need the full test
>>>suite to assert that no regressions occured.  (or you might as well run 10
>>>tests at random and call it done)
>>
>> If you promote the full test suite as the thing to run when resolving merge
>> races, then I predict no one will run them, because doing so increases your
>> chances of hitting *another* push race.  This whole thread came up in the
>> context of trying to find a quick test you could run in that case which 
>> didn't
>> increase that race window.  I think the practical effect of not having a
>> simple, fast smoke test will be to do *less* testing when you hit the merge
>> race, and just let the buildbots sort it all out.  You'll probably win most 
>> of
>> the time anyway.
>
> FWIW, +1 to this.

To make it clear as to the use case Barry and I are trying to cover
here, when you get into a full push race for a bug fix, the current
work flow (in practice) is to just merge/commit/push. When you
multiply it by 3 branches, a useful smoke test needs to be *damn* fast
(i.e. less than a minute) because you're going to be running it three
times in quick succession (perhaps 3 if it applies to 2.7 as well).

The alternative is *not* a full test run, but at best simply running
the specific tests for whatever I'm fixing (or, more likely, not
running any tests at all).

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

Re: [Python-Dev] Python3: speed efficiency vs user friendliness (my first experience)

[Nick Coghlan]

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   |   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

Re: [Python-Dev] Python 3.3 release schedule posted

[Michael Foord]

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.  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 be.)

The "Candidate PEPs" I listed are those open PEPs that in my opinion have
the highest chance to be accepted and implemented for 3.3.  It is by no
means binding.


During the language summit we also discussed formalising in a pep the 
rule that all modules that have a pure python form and a C accelerator 
must keep the pure python and C form precisely in sync and the same 
tests must be run against both. Brett said he would write the pep after 
he has switched import to use importlib...


There was also the "compatibility warning", probably enabled by a 
command line flag, that would warn on the use of CPython specific 
implementation details (for example using non-string keys in class 
dicts). There is no owner for this as a PEP.


They're both mentioned in Nick Coghlan's summary:

http://www.boredomandlaziness.org/2011/03/python-language-summit-highlights.html

Another item discussed at the language summit was moving the standard 
library into its own repository. Jesse Noller started working on a PEP 
but it stalled waiting for the transition to mercurial and I don't know 
if he is volunteering to pick up the PEP again now that has happened.


All the best,

Michael Foord


cheers,
Georg

___
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/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
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] I plan to push faulthandler into Python 3.3 in one week

[Victor Stinner]

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 bugs and changed the API (function
names).

Even if faulthandler is very specific to CPython, I would like to keep
its original name: faulthandler (and not _faulthandler). I also plan to
maintain the module outside CPython for Python 2.5-3.2.

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.

---

faulthandler API is simple and small.

Fatal errors:

 * enable()
 * disable()
 * is_enabled()

Dump the traceback after a timeout:

 * dump_traceback_later(delay, repeat=False, 
file=sys.stderr, all_threads=False)
 * cancel_dump_traceback_later()

Dump the traceback on a user signal:

 * register(signum, file=sys.stderr, all_threads=False)
 * unregister(signum)

Explicit call to dump the traceback:

 * dump_traceback(file=sys.stderr, all_threads=False)

Read the README file for more information.

I don't know if I chose the best function names :-)

---

https://github.com/haypo/faulthandler/
http://bugs.python.org/issue11393
(see also my previous thread on python-dev, "Integrate the faulthandler
module into Python 3.3?")

Victor

___
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] I plan to push faulthandler into Python 3.3 in one week

[Martin v. Löwis]

> 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 project,
to be referenced from pcbuild.sln.

Contributions under the BSD license are not acceptable. You did provide
a contributor agreement, right? If so, you need to submit it under the
terms of that agreement, which means that the code will be licensed
under the PSF license (subject to PSF changes to the license). If you
accepted contributions of others into the code, make sure they also
filed a contributor agreement.

Regards,
Martin
___
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] I plan to push faulthandler into Python 3.3 in one week

[Michael Foord]

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. pythoncore.vcproj), or into a separate project,
to be referenced from pcbuild.sln.

Contributions under the BSD license are not acceptable. You did provide
a contributor agreement, right? If so, you need to submit it under the
terms of that agreement, which means that the code will be licensed
under the PSF license (subject to PSF changes to the license). If you
accepted contributions of others into the code, make sure they also
filed a contributor agreement.


Although note you are still free to distribute it under whatever license 
you want as an external project (you retain copyright). If you have 
already signed a contributor agreement then there is no need for further 
discussion of how your contributions are licensed for inclusion in 
Python, that is already dealt with.


All the best,

Michael Foord

Regards,
Martin
___
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/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
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] Second draft: PEP397: Python launcher for Windows

[Mark Hammond]

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 have this vague hope
where this tool could end up being a shebang-script-launching tool for
other scripting languages as well.


That is an explicit non-goal for the launcher - but if it happens to be 
able to work that way for you, that's great :)


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 insist that the format of the config file 
was such that the GetPrivateProfileString() Windows function could be 
used to extract the data (eg, only '=' can be used to separate the 
name/value pair, case-insensitive and no support for string 
interpolation) as I have no interest in writing my own config file 
parser in C :)


Cheers,

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] I plan to push faulthandler into Python 3.3 in one week

[Victor Stinner]

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 to go
> into pythonXY.dll (i.e. pythoncore.vcproj), or into a separate project,
> to be referenced from pcbuild.sln.

Antoine would like to enable faulthandler by default on fatal error. I
suppose that it would be more easy to do that if the module is a builtin
module, especially if we want to dump the traceback on fatal errors at
*startup* (during Py_InitializeEx).

But we can make it optional, and use a command line option (eg. python
-x faulthandler) or an environment variable to enable it
(PYTHONFAULTHANDLER=1). I am not sure that it is really useful to enable
it *by default*, and some people don't want it enabled by default
because it writes into file descriptor 2 (sys.stderr.fileno()) which may
have been replaced by something else.

Because the module is still a little bit experimental (well, it's stable
but it is not tested by enough people), I would prefer to disable it by
default and have it has an extension (use a dynamic module). But it
doesn't really matter to me :-)

(ok, I will also patch the Visual Studio project)

> Contributions under the BSD license are not acceptable. You did provide
> a contributor agreement, right?

If it is a paper thing, I don't think so. I only sent a paper to the
PSF, but I think that it is different. When I got my commit access one
year ago, I was only asked for a SSH public key. It looks like I will
need to sign this agreement :-)

I can distribute the module under two licenses, I am the only author (I
got two minor contributors).

Victor

___
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 3.3 release schedule posted

[Victor Stinner]

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 they should be.)

I am still working on the import machinery to fix last bugs related to
Unicode. So it will be possible to do an useless "import café" in Python
3.3, on any platform. But it is not really an huge change (for the user,
but an huge change in the code ;-)).

I will probably add my faulthandler module into 3.3.

Victor

___
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] Second draft: PEP397: Python launcher for Windows

[Dj Gilcrease]

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 insist that the format of the config file was such that the
> GetPrivateProfileString() Windows function could be used to extract the data
> (eg, only '=' can be used to separate the name/value pair, case-insensitive
> and no support for string interpolation) as I have no interest in writing my
> own config file parser in C :)

In the user directory much like TortoiseHG adds a murcurial.ini file
to the users directory for basic globa config the launch could look
for a python.ini there and use to to add known paths or version
overrides on a user by user basis.
___
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] sprints and pushes

[Stephen J. Turnbull]

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.

 > > Well, keep in ming hg is a *distributed* version control system. You
 > > don't have to push your changes right now.

s/push your changes right now/push your changes to the public repo/

 > 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*.

That's where the D in DVCS comes in.  It's a new world, friends.  All
you need to do is bring a $50 wireless router to the sprint, and have
some volunteer set up a shared repo for the sprinters.  Then some
volunteer *later* runs the tests and pilots the patches into the
public repo.  Where's the latency?

N.B.  The repo admin and test-running volunteers can be non-coders.
In fact, the tests can be running concurrently (gives those non-coders
an excuse to attend sprints!), but nobody need wait for the results.

 > Maybe we need to chop the problem up as:

"Violence is the last refuge of the incompetent." ObRef Asimov.
___
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 3.3 release schedule posted

[Jesus Cea]

-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 optional feature.

The idea would be, for instance, that smtplib could call an optional
constructor to create a socket-like object, if some is provided.

That would break the implicit dependency with sockets, reduce
monkey-patching need, and ease testing the libs.

I proposed this on the list like a year ago. Somebody else said he was
planning a PEP... not done yet, I guess.

Digging the archive:


- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYqnDplgi5GaxT1NAQJTxQP/U9dk4x9r9Fbwm7zEzEMydzxqqiY/FF6z
PA52YDRPUgyeiDnhmZwk1f9PqnwYWkgf2qmDi+v0eXLZJYqs/rBEcaY36yP1sgP+
+RrFp4aTpf6oqp7HSwrJMoOS2BmRZxLmzShfKecX+3q33Ix1C1EvcF8F8Yg4P4s6
Pd+jRaGvJRs=
=Ec5o
-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] Workflow proposal

[Jesus Cea]

-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 7-8 until all branches, up to and including default have been merged
> 10. Push.

Then you are merging to the newer branches, commits done by some other
developer that, maybe, doesn't want to merge yet for whatever reason.
For instance, because she is waiting for a buildbot cycle.

Also, you have to deal with whatever problem you have during the merge
yourself (for instance, the API changed and the merge is not trivial),
when this work should be done by the original committer.

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYqpS5lgi5GaxT1NAQK/6gP8C6lcTUqnvLE9+szJVLAWzjkwqt8lDCOq
a2Zqi9geOnvUfTYTJgChAL54MZXofzp9Xc/m6bHQV7H9KUuUngcttUkr30De2e4c
410+h9RJFjDBxgpVut+r2jptuH2aOtxaTVt7VLEluO9q8YXmPH1uQV241vtfe3HN
TXopfow/CXA=
=M1WJ
-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] dependency injection for testing [was Python 3.3 release schedule posted]

[Michael Foord]

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 creating sockets. This would be an optional feature.

The idea would be, for instance, that smtplib could call an optional
constructor to create a socket-like object, if some is provided.

That would break the implicit dependency with sockets, reduce
monkey-patching need, and ease testing the libs.



In general I dislike dependency injection if it's only done for 
testability. With monkey patching (if done right) you can safely test 
Python code without messing with your public interfaces just to make 
code testable.


A clean solution that does monkey patching correctly for us, for use 
within our own tests would be a better solution in my opinion.


All the best,

Michael Foord


I proposed this on the list like a year ago. Somebody else said he was
planning a PEP... not done yet, I guess.

Digging the archive:


- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/

j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYqnDplgi5GaxT1NAQJTxQP/U9dk4x9r9Fbwm7zEzEMydzxqqiY/FF6z
PA52YDRPUgyeiDnhmZwk1f9PqnwYWkgf2qmDi+v0eXLZJYqs/rBEcaY36yP1sgP+
+RrFp4aTpf6oqp7HSwrJMoOS2BmRZxLmzShfKecX+3q33Ix1C1EvcF8F8Yg4P4s6
Pd+jRaGvJRs=
=Ec5o
-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/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
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 3.3 release schedule posted

[Michael Foord]

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 creating sockets. This would be an optional feature.

The idea would be, for instance, that smtplib could call an optional
constructor to create a socket-like object, if some is provided.

That would break the implicit dependency with sockets, reduce
monkey-patching need, and ease testing the libs.

I proposed this on the list like a year ago. Somebody else said he was
planning a PEP... not done yet, I guess.

Digging the archive:



Although from this email it seems like it is for much more than just 
testability, in which case go ahead. :-)


Michael

- -- 
Jesus Cea Avion _/_/  _/_/_/_/_/_/

j...@jcea.es - http://www.jcea.es/ _/_/_/_/  _/_/_/_/  _/_/
jabber / xmpp:j...@jabber.org _/_/_/_/  _/_/_/_/_/
.  _/_/  _/_/_/_/  _/_/  _/_/
"Things are not so easy"  _/_/  _/_/_/_/  _/_/_/_/  _/_/
"My name is Dump, Core Dump"   _/_/_/_/_/_/  _/_/  _/_/
"El amor es poner tu felicidad en la felicidad de otro" - Leibniz
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQCVAwUBTYqnDplgi5GaxT1NAQJTxQP/U9dk4x9r9Fbwm7zEzEMydzxqqiY/FF6z
PA52YDRPUgyeiDnhmZwk1f9PqnwYWkgf2qmDi+v0eXLZJYqs/rBEcaY36yP1sgP+
+RrFp4aTpf6oqp7HSwrJMoOS2BmRZxLmzShfKecX+3q33Ix1C1EvcF8F8Yg4P4s6
Pd+jRaGvJRs=
=Ec5o
-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/fuzzyman%40voidspace.org.uk



--
http://www.voidspace.org.uk/

May you do good and not evil
May you find forgiveness for yourself and forgive others
May you share freely, never taking more than you give.
-- the sqlite blessing http://www.sqlite.org/different.html

___
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