The peps repo is the only other one that seems relevant
Actually, the stackless people also requested that their repository
gets converted.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
On Fri, Mar 04, 2011 at 12:56:16PM -0500, Fred Drake wrote:
On Fri, Mar 4, 2011 at 12:35 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
That (below) is not distutils it is setuptools. distutils just uses
`scripts=[...]`, which annoyingly *doesn't* work with setuptools.
Right;
On Sat, Mar 5, 2011 at 3:08 AM, Toshio Kuratomi a.bad...@gmail.com wrote:
Some of them can be annoying as hell when dealing with a system that also
installs multiple versions of a module. But one could argue that's the
fault of setuptools' version handling rather than the entry-points
On 05/03/2011 07:02, Nick Coghlan wrote:
On Sat, Mar 5, 2011 at 10:47 AM, Mark Hammondmhamm...@skippinet.com.au wrote:
I think this discussion should be divorced from this PEP and taken up with
the discussion about the PATH and the last installed wins issue Martin
mentions - only all of them
On Fri, 04 Mar 2011 13:01:02 -0800, Santoso Wijaya santoso.wij...@gmail.com
wrote:
As a mercurial user, I thank you for this effort! One question, where/how do
I send suggestion to what to add into .hgignore file? In particular, I found
these dynamically generated files after a build in
On 6 March 2011 00:44, R. David Murray rdmur...@bitdance.com wrote:
On Fri, 04 Mar 2011 13:01:02 -0800, Santoso Wijaya
santoso.wij...@gmail.com wrote:
As a mercurial user, I thank you for this effort! One question, where/how
do
I send suggestion to what to add into .hgignore file? In
On Sat, Mar 5, 2011 at 11:37 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
I don't think it would be good (or necessary) to split this into a separate
PEP. PyCon (sprints or language summit) would be a good place to talk about
this.
Sure. With a PEP to record decisions this time, we
On Sun, Mar 6, 2011 at 12:22 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Sat, Mar 5, 2011 at 11:37 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
I don't think it would be good (or necessary) to split this into a separate
PEP. PyCon (sprints or language summit) would be a good place to
On 05/03/2011 14:22, Nick Coghlan wrote:
[snip...]
Martin has also indicated that making appropriate changes to the Windows
installer would not be difficult if we agree that changing the 2.7
maintenance branch in this way is appropriate.
True, it's only the more exotic ideas (like trying to do
On 05/03/2011 00:47, Mark Hammond wrote:
On 5/03/2011 8:21 AM, Martin v. Löwis wrote:
...
As for Windows support: we currently don't install a python3.exe binary,
let alone python2.exe or pythonw2.exe (or is that python2w.exe?). I'll
adjust the installer if the PEP asks me to. For the reasons
On 04/03/2011 21:35, Martin v. Löwis wrote:
I don't think duplicating python.exe as python2.exe or python3.exe would
be very much work at all, if we decide it is a good thing. Sure it
doesn't resolve all the myriad problems of Python on Windows but I don't
think that is a good reason not to
Yesterday I cloned the hg cpython repository and made several local copies
for various maintenance releases. This morning I tried to hg pull my
cpython repo to get any changes (not really expecting any), but got this
output:
% hg pull
pulling from http://hg.python.org/cpython
On Sun, 06 Mar 2011 00:54:39 +1100, Tim Delaney timothy.c.dela...@gmail.com
wrote:
If those were to be removed from .hgignore then there would be a high
likelihood of someone doing hg addremove and inadvertently tracking them.
The purpose of .hgignore is to prevent inadventently tracking files
On 05.03.2011 17:14, s...@pobox.com wrote:
Yesterday I cloned the hg cpython repository and made several local copies
for various maintenance releases. This morning I tried to hg pull my
cpython repo to get any changes (not really expecting any), but got this
output:
% hg pull
On 04.03.2011 22:56, Antoine Pitrou wrote:
On Fri, 04 Mar 2011 22:45:24 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
It's not really needed; but since it works with 6+ hex digits there might
be false positives.
I searched the messages, and it turns out that primarily long numbers
On Sat, Mar 5, 2011 at 5:54 AM, Tim Delaney timothy.c.dela...@gmail.comwrote:
If those were to be removed from .hgignore then there would be a high
likelihood of someone doing hg addremove and inadvertently tracking them.
The purpose of .hgignore is to prevent inadventently tracking files that
On Sat, 5 Mar 2011 08:36:04 -0800
Daniel Stutzbach stutzb...@google.com wrote:
On Sat, Mar 5, 2011 at 5:54 AM, Tim Delaney
timothy.c.dela...@gmail.comwrote:
If those were to be removed from .hgignore then there would be a high
likelihood of someone doing hg addremove and inadvertently
I'm very happy to announce that the core Python repository switch
to Mercurial is complete and the new repository at
http://hg.python.org/cpython/ is now officially open for cloning,
and for commits by those who had commit access to SVN.
The developers' guide at http://docs.python.org/devguide/
On 5 March 2011 15:09, Michael Foord fuzzy...@voidspace.org.uk wrote:
On 04/03/2011 21:35, Martin v. Löwis wrote:
It would also be good if the PEP took a position on providing
pythonXY.exe binaries on Windows (with the related question of
whether it's python32w.exe, python3.2w.exe,
On Fri, Mar 4, 2011 at 11:56 PM, Antoine Pitrou solip...@pitrou.net wrote:
On Fri, 04 Mar 2011 22:45:24 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
It's not really needed; but since it works with 6+ hex digits there might
be false positives.
I searched the messages, and it turns out
On 03/05/2011 01:14 AM, Nick Coghlan wrote:
On Sat, Mar 5, 2011 at 2:40 PM, Ron Adamr...@ronadam.com wrote:
Fixing direct execution inside packages
+1 on both of these.
I don't see any major problems with these. Any minor issues can be worked
out.
I suggest separating these two items
On 02/03/2011 16:05, R. David Murray wrote:
On Wed, 02 Mar 2011 13:10:04 +, Mark
Smithmark.sm...@practicalpoetry.co.uk wrote:
The following is going to sound bitter...
I was fired with enthusiasm for working on Python after the sprints at
EuroPython last year. I submitted 3 (I think)
On 28/02/2011 21:59, Martin v. Löwis wrote:
That's one of the big advantages that Jenkins (nee Hudson) has over
buildbot - drilling down into individual test failures through the
web ui. Your test run needs to generate appropriate xml for that to
work though.
Buildbot can do this too. It can
On 3/5/2011 12:44 PM, Paul Moore wrote:
On 5 March 2011 15:09, Michael Foordfuzzy...@voidspace.org.uk wrote:
On 04/03/2011 21:35, Martin v. Löwis wrote:
It would also be good if the PEP took a position on providing
pythonXY.exe binaries on Windows (with the related question of
whether it's
On 05/03/2011 18:52, Terry Reedy wrote:
On 3/5/2011 12:44 PM, Paul Moore wrote:
On 5 March 2011 15:09, Michael Foordfuzzy...@voidspace.org.uk wrote:
On 04/03/2011 21:35, Martin v. Löwis wrote:
It would also be good if the PEP took a position on providing
pythonXY.exe binaries on Windows
On Mar 5, 2011, at 8:44 AM, Antoine Pitrou wrote:
On Sat, 5 Mar 2011 08:36:04 -0800
Daniel Stutzbach stutzb...@google.com wrote:
On Sat, Mar 5, 2011 at 5:54 AM, Tim Delaney
timothy.c.dela...@gmail.comwrote:
If those were to be removed from .hgignore then there would be a high
I'm sorry, but I can't just get used to it, nor do I think it's the least
bad of all available options.
I'll just summarise briefly what the incorrect ways of addressing this
problem are, and why:
* he or she and his or her are cumbersome constructions introduced by
politically correct zealots
On Sat, Mar 5, 2011 at 12:39 PM, Georg Brandl g.bra...@gmx.net wrote:
I'm very happy to announce that the core Python repository switch
to Mercurial is complete and the new repository at
http://hg.python.org/cpython/ is now officially open for cloning,
and for commits by those who had commit
On Sat, 05 Mar 2011 18:26:29 +
Michael Foord fuzzy...@voidspace.org.uk wrote:
On 28/02/2011 21:59, Martin v. Löwis wrote:
That's one of the big advantages that Jenkins (nee Hudson) has over
buildbot - drilling down into individual test failures through the
web ui. Your test run needs to
Georg Brandl:
I'm very happy to announce that the core Python repository switch
to Mercurial is complete and the new repository at
http://hg.python.org/cpython/ is now officially open for cloning,
OK, I just performed a clone OK. It seems wrong to me that the
*.vcproj and *.vsprops files
On Sun, 6 Mar 2011 08:51:01 +1100
Neil Hodgson nyamaton...@gmail.com wrote:
Georg Brandl:
I'm very happy to announce that the core Python repository switch
to Mercurial is complete and the new repository at
http://hg.python.org/cpython/ is now officially open for cloning,
OK, I just
Am 05.03.2011 19:26, schrieb Michael Foord:
On 28/02/2011 21:59, Martin v. Löwis wrote:
That's one of the big advantages that Jenkins (nee Hudson) has over
buildbot - drilling down into individual test failures through the
web ui. Your test run needs to generate appropriate xml for that to
Antoine Pitrou:
It mimicks their settings in the SVN repository, so it should be ok.
It doesn't match how they are checked out by svn since they have
the property svn:eol-style set to 'native'. Therefore these files are
checked out by svn with Windows \r\n line ends.
Neil
Le dimanche 06 mars 2011 à 09:27 +1100, Neil Hodgson a écrit :
Antoine Pitrou:
It mimicks their settings in the SVN repository, so it should be ok.
It doesn't match how they are checked out by svn since they have
the property svn:eol-style set to 'native'. Therefore these files are
With that settled, there is the issue of Start menu shortcuts. I
thought we had agreed to put version specific labels on them so we
would not have, for instance, identical 'IDLE (Python GUI)' items in
the frequently used list. I guess that got lost without a PEP to put
it on. Now there is?
Am 05.03.2011 23:33, schrieb Antoine Pitrou:
Le dimanche 06 mars 2011 à 09:27 +1100, Neil Hodgson a écrit :
Antoine Pitrou:
It mimicks their settings in the SVN repository, so it should be ok.
It doesn't match how they are checked out by svn since they have
the property svn:eol-style set
Am 05.03.2011 17:14, schrieb s...@pobox.com:
Yesterday I cloned the hg cpython repository and made several local copies
for various maintenance releases. This morning I tried to hg pull my
cpython repo to get any changes (not really expecting any), but got this
output:
% hg pull
Daniel A. Welty wrote:
* they and their are plural, and should never be used in the singular.
Thank you for sharing your option here, but you are not a linguist and
you are simply wrong.
At least two people in this thread have already linked to Wikipedia's
article on singular-they, which
To minimize differences from previous behaviour, it is probably
best to mimic svn more closely by changing .hgeol to either have all
the project files as native or allow fall through to the default ** =
native.
Another possibility is to set Visual Studio project files to CRLF
but this is
On Sun, 6 Mar 2011 10:27:14 +1100
Neil Hodgson nyamaton...@gmail.com wrote:
To minimize differences from previous behaviour, it is probably
best to mimic svn more closely by changing .hgeol to either have all
the project files as native or allow fall through to the default ** =
native.
If
Another possibility is to set Visual Studio project files to CRLF
but this is less compatible with how svn has been used. The advantage
to explicit CRLF is that if you clone onto a Unix system and then
share that disk with Windows or create an archive that is expanded on
Windows (in binary
On Sun, 2011-03-06 at 10:25 +1100, Steven D'Aprano wrote:
Daniel A. Welty wrote:
* they and their are plural, and should never be used in the singular.
Thank you for sharing your option here, but you are not a linguist and
you are simply wrong.
At least two people in this thread have
How should patches be applied to the cpython repository if they
land in more than one branch?
More specifically, assuming I want to patch all of 2.7, 3.1, 3.2, and
default - how do I apply the patches and how do I merge?
Regards,
Martin
___
Python-Dev
On Sun, 06 Mar 2011 00:37:32 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
What is the recommended merge flow if I want to make this change to
all branches?
- on one hand: 2.5 - 2.6 - 2.7 (if you still want to maintain 2.5)
- on the other hand: 3.1 - 3.2 - default
Regards
Antoine.
It seems that the dev guide recommends to use the --git option in hg
diff. I'm working on the Rietveld integration, and found that this
option makes things worse: the regular diff includes the base revision
of the patch; hg diff --git doesn't.
So I would rather like people not to use the --git
On Sun, 06 Mar 2011 00:44:03 +0100
Martin v. Löwis mar...@v.loewis.de wrote:
How should patches be applied to the cpython repository if they
land in more than one branch?
More specifically, assuming I want to patch all of 2.7, 3.1, 3.2, and
default - how do I apply the patches and how do I
Westley Martínez wrote:
I believe singular they should not be used in formal writing. So what if
you use it in an email?
If you, personally, dislike it, then don't use it. But if you (generic
you) say that it is grammatically incorrect to do so, then you are
simply *wrong*. Some things are
On Sun, Mar 6, 2011 at 4:11 AM, Ron Adam r...@ronadam.com wrote:
Adding a second references to the '__main__' module begins to blur the
purpose of sys.modules from being a place to keep imported modules to a
place that also has some ordering information. (Practicality over purity?,
Or an
I am trying to fix the hgeol settings for the vcproj files, with little
success so far. I created
http://hg.python.org/sandbox/hgeol/
which merely changes the .hgeol file. Now, if you enable the eol
extension, and check this branch out, you immediately get a report
(from hg status) that you have
Martin v. Löwis:
So how can I fix this properly: so that all files have CRLF, but
are still attributed to whoever last modified them, rather than
having them attributed to me?
I don't think this is possible from the current state. It may be
possible to change the conversion process to
On 3/5/2011 7:37 PM, Martin v. Löwis wrote:
I am trying to fix the hgeol settings for the vcproj files, with little
success so far. I created
http://hg.python.org/sandbox/hgeol/
which merely changes the .hgeol file. Now, if you enable the eol
extension, and check this branch out, you
For the record, the reason these emails look a bit strange (and appear
to be pushed by Dirkjan (sorry)) is that they were done directly on the
server with the settings of the local user hg.
Regards
Antoine.
On Sun, 06 Mar 2011 02:36:25 +0100
dirkjan.ochtman python-check...@python.org wrote:
Enough already. If anyone still disagrees, they can discuss it in the
comments page on wikipedia
(http://en.wikipedia.org/wiki/Talk:Singular_they).
Seriously, this is off-topic for python-dev.
--
--Guido van Rossum (python.org/~guido)
___
Python-Dev
On 6/03/2011 12:37 AM, Michael Foord wrote:
On 05/03/2011 07:02, Nick Coghlan wrote:
On Sat, Mar 5, 2011 at 10:47 AM, Mark
Hammondmhamm...@skippinet.com.au wrote:
I think this discussion should be divorced from this PEP and taken up
with
the discussion about the PATH and the last installed
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In
http://docs.python.org/devguide/faq.html#can-i-make-commits-from-machines-other-than-the-one-i-generated-the-keys-on
I would rather prefer to promote the -A parameter to SSH (to use the
local SSH agent be used from the remote development machine)
On Sun, 2011-03-06 at 11:18 +1100, Steven D'Aprano wrote:
Westley Martínez wrote:
I believe singular they should not be used in formal writing. So what if
you use it in an email?
If you, personally, dislike it, then don't use it. But if you (generic
you) say that it is grammatically
On 03/05/2011 06:33 PM, Nick Coghlan wrote:
On Sun, Mar 6, 2011 at 4:11 AM, Ron Adamr...@ronadam.com wrote:
Adding a second references to the '__main__' module begins to blur the
purpose of sys.modules from being a place to keep imported modules to a
place that also has some ordering
On Sun, Mar 6, 2011 at 2:54 PM, Ron Adam r...@ronadam.com wrote:
... if the key matches sys.modules.__missing__
Works for me. ;-)
We can find a better name than __missing__ later. (minor detail)
__missing__ is a dict method. I was merely noting it would make more
sense to override that
On Sat, Mar 5, 2011 at 7:54 PM, Jesus Cea j...@jcea.es wrote:
In
http://docs.python.org/devguide/faq.html#can-i-make-commits-from-machines-other-than-the-one-i-generated-the-keys-on
I would rather prefer to promote the -A parameter to SSH (to use the
local SSH agent be used from the
59 matches
Mail list logo
