Re: [Python-Dev] Python merge module

Am 02.02.2011 20:01, schrieb Hoyt, David: > Is there or will there be support for python merge modules so we can > include python in our installer? I haven't planned any. Contributions are welcome. > But has there been thought towards migrating away from msilib and using > platform standard tools

Re: [Python-Dev] Python merge module

>> The Installer COM object is the platform standard mechanism, and >> that's what msilib uses. > > Why maintain a lib when there's (better), free alternatives out there > that are maintained by Microsoft itself? Using msilib is easier than using Wix. It's also more flexible. All you have to know

Re: [Python-Dev] Python merge module

> I'm really not trying to start a flame war here (my original post > only asked if there was "thought towards migrating away from > msilib"). There's legitimate need/desire for a merge module to make > it easier to package a specific Python version. Please recognize that this question is entirely

Re: [Python-Dev] Python merge module

>> As far as the possibility of distributing Python as a merge >> module? I'd recommend against it. Shared location merge modules are >> a maintenance nightmare, and private location merge modules may >> not offer the benefit you need. Better to just install the main >> Python msi as part of a suit

Re: [Python-Dev] Python merge module

> Technically this is a problem with the component generation in Python, > and for that in particular, a move to WiX could be very helpful. They > have stable component code generation which keys off of location, > name, platform, etc., but only works for single-file components. That would be no r

Re: [Python-Dev] Python merge module

Am 03.02.2011 18:58, schrieb Floris Bruynooghe: > On 3 February 2011 15:38, Michael Urman wrote: >> Technically this is a problem with the component generation in Python, >> and for that in particular, a move to WiX could be very helpful. They >> have stable component code generation which keys of

Re: [Python-Dev] Python merge module

> The general recommendation regarding msi packages is that you always, > always do single-file components (one of the major reasons being for > patching purposes). Can you please cite a source for that recommendation? Preferably some MSDN documentation. Regards, Martin __

Re: [Python-Dev] Py_tp_getset in ABI?

Am 03.02.2011 16:43, schrieb Egon Smiwa: > Hi all, > I'm trying to convert my embedding code to your new ABI, > but I cannot find the ABI slot for tp_getset in typeslots.h > (while tp_methods are supported). Is the support of tp_getset > not yet determined? Not sure what I thought - it seems that

Re: [Python-Dev] Finally fix installer to add Python to %PATH% on Windows

> I'd like to see this in 3.2 release, of course. As Brian already asserted: that's not feasible. I still haven't managed to test your installer, and may not be able to for the next few weeks. It's also against the policy for release candidates to add such a change at this point. I believe the cha

Re: [Python-Dev] API bloat

> The functions may have been add to CPython 8 years ago, but they were > added to the API when they appeared in the docs, between 3.1 and 3.1.3. > > How is the API defined, if not by the documentation? Just to stress and support Georg's explanation: the API is *not* defined through the documenta

Re: [Python-Dev] API bloat

>> 1. CPython developers >> 2. authors of CPython extensions >> 3. developers embedding a CPython interpreter (or interpreters) into >> their application > > This makes me wonder who `owns' the API. > Is the CPython developers, the Python community as a whole, the PSF? > (Another one for Python-id

Re: [Python-Dev] Rights on the tracker

> Done. I hope. This is the first one we (currently) have where more > than one person is being auto-nosied, so I hope I got the syntax right. It should be fine: roundup_tracker=> select * from component_add_as_nosy where nodeid = 25; linkid | nodeid + 7641 | 25 12434

[Python-Dev] svn outage on Friday

I'm going to perform a Debian upgrade of svn.python.org on Friday, between 9:00 UTC and 11:00 UTC. I'll be disabling write access during that time. The outage shouldn't be longer than an hour. Regards, Martin ___ Python-Dev mailing list Python-Dev@python

Re: [Python-Dev] svn outage on Friday

Am 17.02.2011 23:19, schrieb Santoso Wijaya: > Speaking of, what is the current status and timeline on the move to > Mercurial? I think it's fair to say that the project currently rests, lacking a project lead. The most recent timeline is that conversion should be completed by PyCon, and, failing

Re: [Python-Dev] svn outage on Friday

Am 18.02.2011 14:41, schrieb Dirkjan Ochtman: > On Tue, Feb 15, 2011 at 09:30, "Martin v. Löwis" wrote: >> I'm going to perform a Debian upgrade of svn.python.org on Friday, >> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during >> that

Re: [Python-Dev] "Some" .pyc files not ending up in __pycache__ during installation

> sorry for asking here instead of filing a bug, but given that 3.2 final > is pretty close, I wanted to make sure this gets considered. If you want it decided before the 3.2 release, it must be a release-critical bug report in the tracker. Posting it here does not make sure it gets considered. R

Re: [Python-Dev] "Some" .pyc files not ending up in __pycache__ during installation

Am 19.02.2011 14:14, schrieb Antoine Pitrou: > On Sat, 19 Feb 2011 23:07:17 +1000 > Nick Coghlan wrote: >> >> While this is definitely untidy, it doesn't strike me as a release >> blocker. More of a "fix it in 3.2.1", since the status quo will >> *work*, it just means the precompiled file will be

Re: [Python-Dev] w9xpopen.exe is still in 3.2

Am 20.02.2011 07:43, schrieb anatoly techtonik: > Python definitely needs a development Roadmap to avoid things like > w9xpopen.exe slipping off radar from release to release. We don't > support Windows 9x since Python 2.6. What this file does in 3.x > distributions? > > http://bugs.python.org/iss

Re: [Python-Dev] w9xpopen.exe is still in 3.2

> Does a modern windows installation actually even *work* if you change > COMSPEC to command.com instead of cmd.exe? And why would anyone ever > do that? Hey, I have a good idea: python can just ignore COMSPEC and > always run cmd.exe. Then you can delete w9xpopen, hooray. We have a process for th

Re: [Python-Dev] Const-correctness in C-API Object Protocol

> Also changing it now would be a giant hassle, leading to so-called > "const poisoning" where many, many APIs need to be changed before > everything would again work. We have been adding const to many places over the years. I think the specific case was just missed (i.e. nobody cared about adding

Re: [Python-Dev] Const-correctness in C-API Object Protocol

>> Though I do not get that warning -- which compiler and version issues >> it? Is it a C or a C++ compiler? > > Well, which warning are you talking about? I think Guido assumed that the OP was getting actual complaints from some actual compiler - else he wouldn't have asked the question. However

Re: [Python-Dev] %-formatting depracation

> The very long term view is for %-formatting to go away Add to that that this view isn't universally shared among contributors. Many of us would rather see % formatting stay indefinitely. I regularly use it for new code. Regards, Martin ___ Python-Dev

Re: [Python-Dev] Const-correctness in C-API Object Protocol

> Even if it is eventually decided not to backport those patches to 2.7, > it would be nice if the documentation could be updated to indicate > that strings passed to those functions won't be modified, so that API > users like myself can feel a little safer when passing literals in, > without havin

Re: [Python-Dev] Const-correctness in C-API Object Protocol

> I don't think it's a good idea to backport visible API changes. > (someone successfully compiling on 2.7.N could then have users > complaining that compilation fails on 2.7.N-1). +1. If it was a bug fix (which it isn't), having this kind of breakage would be fine, of course (i.e. code relying on

Re: [Python-Dev] svn outage on Friday

Am 23.02.2011 02:43, schrieb Nick Coghlan: > On Tue, Feb 15, 2011 at 6:30 PM, "Martin v. Löwis" wrote: >> I'm going to perform a Debian upgrade of svn.python.org on Friday, >> between 9:00 UTC and 11:00 UTC. I'll be disabling write access during >> that

Re: [Python-Dev] 3.2.0 == 20th anniversary release

> Or you realized later how nice it would be, grabbed the time machine, > and fixed 10 release blockers on the 19th. :) No no no. He actually grabbed the time machine, drove 20 years back, and gave it to Guido so he could release Python 0.9 in time. Guido then kept the machine ever since. Regards

Re: [Python-Dev] Link to issue tracker

Am 23.02.2011 19:30, schrieb Brett Cannon: > I won't add the link back Why not? It's a useful link apparently. The "Developer's Guide" link does not hint that it will be the only way to find the bug tracker. It's like adding the download page at the end of the tutorial - "you can get Python only

Re: [Python-Dev] Link to issue tracker

> But python.org/dev/ is a dead page. I was > trying to avoid adding a redirect for python.org/dev/ > as I was afraid that it would lead to the > website doing something silly like redirecting everything below that > URL, but obviously this can cont

Re: [Python-Dev] Link to issue tracker

> As for redirects: it's certainly possible to redirect ^/dev$ to > /devguide, leaving /dev..* alone. I can set this up if you want me to. > > > Please. Or double-check what I put into pydotorg's redirect.txt will > work properly. What redirect.txt did you edit specifically? I have now

Re: [Python-Dev] Link to issue tracker

> What redirect.txt did you edit specifically? > > > It was beta.python.org/build/redirects.txt > , but I went ahead and > reverted the change since your solution works. Ah. That file isn't used, AFAICT, so I now deleted it. If there are any other

Re: [Python-Dev] Mercurial conversion repositories

> Georg and I have been working on converting the SVN repository to > Mercurial. We can now present you a test repository (actually, two). Thanks for working on this! How do you want bugs reported? Can you please update the PEP? I see at least the following deviations: - the extrahist repository

Re: [Python-Dev] strange buildbot fail

Am 25.02.2011 08:29, schrieb Eli Bendersky: > Hi, > Earlier today I've committed revision 88554, and a bit later a > buildbot failure message was received: > Builder AMD64 Windows Server 2008 hg-3.x build #47 failed with failed > test_import, blamelist having my name because I made the last commit

Re: [Python-Dev] Mercurial conversion repositories

Am 25.02.2011 09:17, schrieb Dirkjan Ochtman: > On Fri, Feb 25, 2011 at 09:09, "Martin v. Löwis" wrote: >> I think I would have liked the strategy of the PEP better (i.e. >> create clones for feature branches, rather than putting all >> in a single repository). &g

Re: [Python-Dev] Mercurial conversion repositories

Am 25.02.2011 09:29, schrieb Dirkjan Ochtman: > On Fri, Feb 25, 2011 at 09:25, "Martin v. Löwis" wrote: >> If there are hundreds of them, it's far from trivial. I don't even know >> how to find out which one to convert. > > Right, I mostly mean it'

Re: [Python-Dev] [Python-checkins] pymigr: Update todo

> After migration > === > > +* set up automatic installation of changes to ssh keys, decide upon > + account managers I would like account managers to be decided before the conversion. I personally won't be available as an account manager anymore. The new account managers are then

Re: [Python-Dev] Mercurial conversion repositories

> I think people should simply get used to the idea that "default" is > /the/ main branch in Mercurial (*). It's even easier to remember IMHO > ("trunk" sounds a bit obscure at first, for a non-native English > speaker). +1. People will recognize "trunk" as a svn think. If that doesn't clue them i

Re: [Python-Dev] [Python-checkins] cpython (trunk): Close the "trunk" branch.

> http://hg.python.org/cpython/rev/41071f447b15 > changeset: 68041:41071f447b15 > branch: trunk > tag: tip > parent: 62750:800f6c92c3ed > user:Georg Brandl > date:Sat Feb 26 07:48:21 2011 +0100 > summary: > Close the "trunk" branch. What's the effect of "clos

Re: [Python-Dev] [Python-checkins] cpython (trunk): Close the "trunk" branch.

> Committing reopened it So what's the point of closing it, then? What effect does that achieve? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/ma

Re: [Python-Dev] Mercurial conversion repositories

Am 26.02.2011 15:42, schrieb Nick Coghlan: > On Sat, Feb 26, 2011 at 7:29 PM, "Martin v. Löwis" wrote: >>> I think people should simply get used to the idea that "default" is >>> /the/ main branch in Mercurial (*). It's even easier to remember IMHO &

Re: [Python-Dev] Mercurial conversion repositories

> Although I now admit "legacy-trunk" sounds quite accurate, and conveys > a clear warning to anyone wondering if they should use it. To stay in tree terminology, I propose "stump" (*). Or "rotten-trunk". Bikeshedding is such a fun activity :-) Regards, Martin (*) m-w.com: "the part of a plant

Re: [Python-Dev] Mercurial conversion repositories

Am 26.02.2011 17:44, schrieb Antoine Pitrou: > Le samedi 26 février 2011 à 08:38 -0800, Daniel Stutzbach a écrit : >> On Fri, Feb 25, 2011 at 6:32 PM, Nick Coghlan >> wrote: >> Would it be possible to name "trunk" as "2.x" instead? >> Otherwise I >> could see people getting

Re: [Python-Dev] pymigr: Ask for hgeol-checking hook.

Am 26.02.2011 18:54, schrieb Antoine Pitrou: > On Sat, 26 Feb 2011 18:48:17 +0100 > martin.v.loewis wrote: >> * some hook should prevent pushing python files indented by tabs. >> * some hook should prevent pushing to the 2.x trunk. >> +* some hook should prevent breaking EOL conventions. > > We

Re: [Python-Dev] Mercurial conversion repositories

>> But is there a need to have any changesets in the "trunk" named branch? >> Couldn't the historical changesets just be in an unnamed branch, being >> ancestor of so many named branches? > > There is no such thing as an "unnamed branch". What would "hg branches" > show? An empty space? hg branch

Re: [Python-Dev] [Python-checkins] cpython: improve license

Am 26.02.2011 19:12, schrieb Barry Warsaw: > Notice the subject line. Can we make commit messages contain the named branch > that the change applies to? If you don't want this request to be forgotten, add it to todo.txt in the pymigr repo. Regards, Martin ___

Re: [Python-Dev] pymigr: Ask for hgeol-checking hook.

Am 26.02.2011 19:13, schrieb Antoine Pitrou: > >> In Mercurial, it's just a hook, and optional. So we can't be sure all >> users use it correctly - and in my (limited) experience with Mercurial, >> chances are high that users will make mistakes in that respect (i.e. >> in one out of one cross-plat

Re: [Python-Dev] hg extensions was Mercurial conversion repositories

> Actually, it isn't *required* on each developer's setup, since we > now have a hook that refuses bogus changegroups (if needed, we can even > refuse individual changesets). In most situations, even without the > eol extension line endings won't get modified anyway. I think this is overly optimi

Re: [Python-Dev] Mercurial conversion repositories

>> changeset: 72694:e65daae6cf44 >> user:Antoine Pitrou >> date:Mon Feb 21 21:30:55 2011 + >> summary: Try s/UINT_MAX/INT_MAX/ > > It's not on an unnamed branch, it's on the "default" branch (which is > omitted for concision by "hg log" and other commands with a similar

Re: [Python-Dev] of branches and heads

> So, actually, hg promotes a slightly different terminology: > - a "head" is a changeset without a child in the topology So what do you call the LoD leading up to a head? (i.e. the set of changesets that are ancestors of a head and not ancestors of any other head) Regards, Martin _

Re: [Python-Dev] pymigr: Ask for hgeol-checking hook.

Am 26.02.2011 20:30, schrieb Antoine Pitrou: > > Martin, I have now enabled the eol hook on the test repo (a quick test > seemed to show it works). Could you test again? It seems to work fine, thanks. I modified a file with Visual Studio, and that changed all line endings. I then decided to "fix"

Re: [Python-Dev] [Python-checkins] hooks: Fix checkbranch hook

Am 27.02.2011 00:21, schrieb Éric Araujo: >> Then we will have to fix the hook each time we want to add a new >> legitimate branch. > The alternative is to edit the hook each time we want to remove a former > legitimate branch, plus have another hook to refuse new named branches. The question is w

Re: [Python-Dev] hg extensions was Mercurial conversion repositories

>> I think this is overly optimistic. Visual Studio will break all your >> files if you don't use that extension (and you actually use it to >> modify source code). > > My assumption was that most developers don't use MSVC, so most of them > don't risk breaking eols ;) > True, for Windows devs it

Re: [Python-Dev] hg extensions was Mercurial conversion repositories

>> My assumption was that most developers don't use MSVC, so most of them >> don't risk breaking eols ;) >> True, for Windows devs it might be necessary to promote it. > > Windows devs were the original target audience, yes :) I meant to say that earlier: thanks to everybody involved in the origi

Re: [Python-Dev] Finding buildbot failures

>>> 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 even do it without xml, alt

Re: [Python-Dev] Please sync your feature branches

> In preparation for the hg switch, I would recommend that, if you have > any feature branches managed with svnmerge, you sync them with the py3k > branch before we switch. That way, it will make it easier to "bridge > the gap" when you create a new repository for your work after the > switch (the

Re: [Python-Dev] Please sync your feature branches

Am 28.02.2011 23:45, schrieb Antoine Pitrou: > Le lundi 28 février 2011 à 23:26 +0100, "Martin v. Löwis" a écrit : >>> In preparation for the hg switch, I would recommend that, if you have >>> any feature branches managed with svnmerge, you sync them with the py3k &g

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

Am 02.03.2011 00:16, schrieb Kerrick Staley: > I think that it's a good idea to not only state that python should be > Python 2, but also that python2 should be implemented and that scripts > should specify it, to provide redundancy and handle distros that won't > or have not yet switched back to t

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

>> I believe we agreed at the language summit last year (or maybe even the >> year before) that "python" would always be python2.x, and "python3" >> would be python3.x. >> >> And by "always" we indeed meant forever. To do otherwise would break >> scripts even many, many years from now. > > It s

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

> I think a PEP would help, but in this case I would request that before > the PEP gets written (it can be a really short one!) somebody actually > go out and get consensus from a number of important distros. Besides > Barry, do we have any representatives of distros here? Matthias Klose represent

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

Am 02.03.2011 20:49, schrieb James Y Knight: > On Mar 2, 2011, at 12:14 PM, Barry Warsaw wrote: >> I don't have a problem with adding such a symlink, and I think it >> should be done by Informational PEP, not Standards Track PEP. >> Since there will be no Python 2.8, our own build system shouldn't

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

Am 02.03.2011 23:36, schrieb Jérôme Radix: > No, I don't do it now. But taking like granted the fact that 2.x python > will be dead in 5 years and that /usr/bin/python will point to python3 > is, imho, a little too optimistic. I don't think Steven said, or assumed, a scope of 5 years - more like a

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

> Here is a draft PEP (forgive me if it's incorrectly formatted; I've > never done this before). LGTM. Please specify what /usr/bin/python is supposed to be also (rather: the "python" utility). I'd like it ruled out that installations *only* provide python2 and python3 - "python" could be either o

[Python-Dev] Summer of Code: call for ideas and mentors

Google Summer of Code is coming up again, and we will again be participating. Arc Riley will setup infrastructure later today, and we need to start thinking about possible projects. Traditionally, people (students and other projects) have been willing to give the Python Core the highest attention

Re: [Python-Dev] Summer of Code: call for ideas and mentors

> Would you consider working on benchmarking (http://speed.pypy.org but > also infrastructure for running it) a part of core GSoC work? I can > imagine this to be useful not only for pypy and preferably also > running CPython trunk on benchmarks. IMO, the question really is if this is "primarily"

Re: [Python-Dev] Summer of Code: call for ideas and mentors

> Are proof-of-concept projects acceptable as GSoC projects? I'd say so. It's more rewarding (both for the student and the project) if the code has a chance to be integrated, at least in principle. However, doing a project and then finding out that the real solution should be similar but different

Re: [Python-Dev] Summer of Code: call for ideas and mentors

Am 04.03.2011 13:35, schrieb Antoine Pitrou: > On Fri, 04 Mar 2011 09:35:38 +0100 > "Martin v. Löwis" wrote: >> Google Summer of Code is coming up again, and we will again >> be participating. Arc Riley will setup infrastructure later >> today, and we nee

Re: [Python-Dev] rXXX links in the bug tracker after the migration to Mercurial

Am 04.03.2011 18:17, schrieb Georg Brandl: > On 04.03.2011 13:59, Victor Stinner wrote: >> Hi, >> >> Does the bug tracker will continue to support rX links after the >> migration to Mercurial? > > Yes. They will link to http://hg.python.org/lookup/rX, which uses > the conversion metadata

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

>>> Should any of this also apply to Mac OS X and Windows? >> Any platform that considers itself "unix-like" in this context can >> decide to follow it, we aren't fussy (e.g. Cygwin and the *nix-y >> aspects of OS X). The main point of the PEP is to get a consensus >> recommendation out of python-d

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

> P.S. I'm a bit confused about this discussion though, wouldn't adding > python2 to the installation be a feature change and as such not > something that can be done in a maintenance branch? Correct. However, IMO, a PEP could propose to break that rule. Having such a proposal may cause rejection

Re: [Python-Dev] Mercurial conversion repositories

> 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 > Windows (3.2) that probably should be entered as .hgignore entries: All patches shoul

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

Am 04.03.2011 20:14, schrieb Guido van Rossum: > Is there any discussion still going on about the details of the PEP > (now PEP 394)? I'm in favor of the general idea. What about Windows? I > think it should be the same there if possible. I think a key issue is whether to change future 2.7 bug fix

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

> 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 consider it. Up to Martin on this one > tho

Re: [Python-Dev] rXXX links in the bug tracker after the migration to Mercurial

> 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 would give false positives: Python 1.6a2 (#7, Apr 24 2000, 23:02:54) [GCC pgcc-2.91.66 19990314 minidom (as the proposed docum

Re: [Python-Dev] Summer of Code: call for ideas and mentors

> I'm a little confused by the > http://wiki.python.org/moin/SummerOfCode/2011 page though. If I'm a > *member* of an approved project (CPython in this case), can I just add > an entry to the table? Or do I need to do something first to be > approved as a prospective mentor? It's a wiki, so feel f

Re: [Python-Dev] [Python-checkins] pymigr: The peps repo is the only other one that seems relevant

> 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 http://mail.python.org/mailman/listinfo/pyt

Re: [Python-Dev] Finding buildbot failures

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

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

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

Re: [Python-Dev] CPython hg transition complete

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:

Re: [Python-Dev] hg pull failed

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 >

Re: [Python-Dev] CPython hg transition complete

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

[Python-Dev] hg merge flow

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 m

[Python-Dev] hg diff

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 opt

[Python-Dev] hgeol

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

Re: [Python-Dev] r88758 - tracker/instances/python-dev/scripts/addpatchsets

-def find_bases(data, rev): +def hg_splitpatch(data): +patches = [] +filename = None +for line in data.splitlines(True): +if line.startswith('diff -r'): Now I understand why you would like to discourage git diffs. But, as I said back then, I don't think it's worthwhile to try

Re: [Python-Dev] hg pull failed

So, when I cloned, I should have done something like this: hg clone http://hg.python.org/cpython hg clone cpython 3.2 hg clone 3.2 3.1 hg clone cpython 2.7 hg clone 2.7 2.6 hg clone 2.6 2.5 hg clone 2.5 2.4 instead of cloning everything from cpython, right? Y

Re: [Python-Dev] Support the /usr/bin/python2 symlink upstream

I do not like the vagueness about the python link. Sounds like "It may point to this or that, but it might change, and it might break, maybe we'll change our position later, in some years". I can understand the uneasiness about that, however, the slightly sarcastic phrasing describes the inten

Re: [Python-Dev] r88758 - tracker/instances/python-dev/scripts/addpatchsets

Would you like to contribute a patch to make that work? It's too tedious to work without a base revision, so for the time being, this cannot be supported. Well, no. I was assuming that basing all patches on tip would make things simpler. It's very easy to get the base code if you know the base

Re: [Python-Dev] hg pull failed

Not sure if it fits in your specific case you mention here, but Mercurial has a reserved path alias name "default-push" with special meaning: Ah. I didn't know that, thanks. Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.o

[Python-Dev] (Final?) release of Python 2.5 in April

According to our security fix policy, Python 2.5 releases can happen until September 2011. Since there are unreleased changes, I plan to make a release "soon", which likely means April. I'll call this tentatively the "final" release of Python 2.5, even though security issues discovered after war

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

Am 06.03.2011 21:12, schrieb Kerrick Staley: Some nitpicks: Heh, you are the author of the PEP :-) You'll find the source of your PEP in http://svn.python.org/projects/peps/trunk/ Please provide Nick with a patch/updated version; if you want to, you can also get write access to the PEP repos

Re: [Python-Dev] CPython hg transition complete

Am 06.03.2011 21:46, schrieb s...@pobox.com: Antoine> Yes, there is. You can simply push to your 3.2 repo instead: Antoine> $ cd 3.1 Antoine> $ hg up 3.1# just in case Antoine> # hack, compile, test Antoine> $ hg ci -m "Issue #xxx: nasty bug now fixed" An

Re: [Python-Dev] [PEPs] Support the /usr/bin/python2 symlink upstream

I should've mentioned that I'd like a consensus (or a lack of protest) on the changes related to these snippets: [...] -"Exclusions of MS Windows" I think you won't get consensus on that: there are strong proponents and strong opponents (I think Mark being a strong proponent of such exclusio

Re: [Python-Dev] hg diff

Am 07.03.2011 02:24, schrieb Stephen J. Turnbull: "Martin v. Löwis" writes: > 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 regula

Re: [Python-Dev] hg diff

Am 07.03.2011 03:43, schrieb Stephen J. Turnbull: "Martin v. Löwis" writes: > Am 07.03.2011 02:24, schrieb Stephen J. Turnbull: > > "Martin v. Löwis" writes: > >> It seems that the dev guide recommends to use the --git option in hg > &

[Python-Dev] Codereview on bugs.python.org ready for testing again

I ported the code review support on bugs.python.org to hg, and reactivated it. Review "issues" are created automatically if the attached file is recognized as a patch that applies cleanly. The roundup issue's nosy list is synchronized with the rietveld issue's cc list, so comments get mailed to th

Re: [Python-Dev] PyCObject_AsVoidPtr removed from python 3.2 - is this documented?

Am 07.03.2011 10:14, schrieb Nick Coghlan: On Mon, Mar 7, 2011 at 6:36 PM, John Arbash Meinel wrote: Especially since, AIUI, deprecations are suppressed by default now. True, but developers are expected to run their tests with them enabled. I think everything here is as it should be. Peop

[Python-Dev] combined hg incoming patch

I'd like to experiment with adding Rietveld support for reviewing remote repositories. For that, I'd need to create a single patch (programmatically) that covers all incoming changes. 'hg incoming -p' mostly works, but it may provide multiple patches for a single file, which I think would harm the

Re: [Python-Dev] combined hg incoming patch

Am 07.03.2011 23:09, schrieb Brendan Cully: On 2011-03-07, at 1:03 PM, Martin v. Löwis wrote: I'd like to experiment with adding Rietveld support for reviewing remote repositories. For that, I'd need to create a single patch (programmatically) that covers all incoming changes. '

Re: [Python-Dev] hg diff

With a branch you can easily view the full patch, making a branch strictly more general. I just asked this before: how *exactly* do you do that? Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/

Re: [Python-Dev] hg diff

However, as Michael points out, you can have your tools generate the patch. For example, it shouldn't be too hard to add a dynamic patch generator to Roundup (although I haven't thought about the UI or the CPU burden). For Mercurial, that's more difficult than you might expect. There is "hg in

Re: [Python-Dev] combined hg incoming patch

Sorry, I didn't think that through. Revsets still have the power though: hg -R tmp.bundle diff -r'ancestor(.,default)' -r default (assuming your local repo is at the tip of default) I can't make this work. I'm using hg 1.6.4, which does have revsets and (including ancestor). Still, with this c

<    19   20   21   22   23   24   25   26   27   28   >