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 is not mentioned - the branchmap is (apparently?) not evaluated; in particular, it's not clear whether the keep-clone branches went. - it's not clear what your view on the subversion repository is - do you keep the notion of discarded branches (i.e. branches that can only be discovered from looking at a copy of the subversion repository), or do you mean to convert everything? As for the cpythonextrahist repository: why are the heads all unnamed? How are you supposed to find anything in it? 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). 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] Mercurial conversion repositories
With hg 1.7.5 on Windows 7 I performed a non-core checkout: hg clone http://hg.python.org/cpython The eol extension is enabled in global settings. I looked at things a bit, opening some files and using the Tortoise Hg Repository Explorer. But made no actual changes. Running hg diff produces a large amount of output with almost all the *.decTest and most of the Windows build files (*.mk, *.sln, *.vcproj, *.bat) showing as changed but with identical text. I've had problems like this with Hg before (http://mercurial.selenic.com/bts/issue2287). The situation can be fixed by hg update to another version and then back to default. Neil ___ 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] Mercurial conversion repositories
On Fri, Feb 25, 2011 at 09:09, Martin v. Löwis mar...@v.loewis.de 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). Unnamed heads are trivial to convert to clones. 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] 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 (apparently). Two other buildbots succeeded building and testing after my commit, as did my local tests. Some examination of the failed test shows no apparent connection to my commit. You find the builder here: http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%20hg-3.x The specific build you can find here http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%20hg-3.x/builds/47 The failing build step is here http://www.python.org/dev/buildbot/all/builders/AMD64%20Windows%20Server%202008%20hg-3.x/builds/47/steps/test/logs/stdio The failure message is this: test test_import failed -- Traceback (most recent call last): File c:\buildslave-py3k\hg-3.x.curtin-win2008-amd64\build\lib\test\test_import.py, line 182, in test_failing_import_sticks self.assertRaises(ZeroDivisionError, __import__, TESTFN) AssertionError: ZeroDivisionError not raised by __import__ In re-running the test, the test succeeded: test_failing_import_sticks (test.test_import.ImportTests) ... ok So apparently, this test case has a transient failure. It's not obvious (to me) why there might be a transient failure in this test case. What can be done in cases like this? How to investigate further? One way of dealing with it is to ignore it. If you do want to investigate further, try to reproduce the failure. It may be that the specific sequence in which the tests are executed can cause the failure. Or it's specific to the Windows installation, and some interaction with the virus scanner, in which case you should ask Brian for remote-desktop access to the build slave in order to reproduce it. HTH, 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] Mercurial conversion repositories
Am 25.02.2011 09:17, schrieb Dirkjan Ochtman: On Fri, Feb 25, 2011 at 09:09, Martin v. Löwis mar...@v.loewis.de 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). Unnamed heads are trivial to convert to clones. If there are hundreds of them, it's far from trivial. I don't even know how to find out which one to convert. 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] Mercurial conversion repositories
On Fri, Feb 25, 2011 at 09:25, Martin v. Löwis mar...@v.loewis.de 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's trivial for Antoine or Georg to extract into a clone (at least that's how I was planning to do it, not sure what their idea is). 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] Mercurial conversion repositories
Am 25.02.2011 09:29, schrieb Dirkjan Ochtman: On Fri, Feb 25, 2011 at 09:25, Martin v. Löwis mar...@v.loewis.de 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's trivial for Antoine or Georg to extract into a clone (at least that's how I was planning to do it, not sure what their idea is). Ah ok. So I guess that goes back to my original request - that the PEP be updated. 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
[Python-Dev] PyEval_InitThreads() no longer safe before Py_Initialize() in 3.2
It seems that PyEval_InitThreads() can no longer be called before
Py_Initialize(). I get a fatal error in PyThreadState_GET().
This contradicts the documentation
http://docs.python.org/release/3.2/c-api/init.html#PyEval_InitThreads
Minimal repro:
#include Python.h
int main()
{
PyEval_InitThreads();
return 0;
}
___
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] Mercurial conversion repositories
On Feb 25, 2011, at 12:09 AM, 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). In my brief tests, the single repository has been easy to work with. If they were separate, it would complicate backporting patches and merges. So, I'm happy with how George and Benjamin put this together. Raymond ___ 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] Mercurial conversion repositories
On Fri, 25 Feb 2011 19:13:49 +1100 Neil Hodgson nyamaton...@gmail.com wrote: With hg 1.7.5 on Windows 7 I performed a non-core checkout: hg clone http://hg.python.org/cpython The eol extension is enabled in global settings. Yes, please try to disable it. The issue is we have a .hgeol in the repository right now (it's in the SVN repository too), but it doesn't match the reality of on-disk files, so when you update, the eol extension tries to fix those files. 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] Mercurial conversion repositories
On Thu, 24 Feb 2011 17:39:40 -0800 Brett Cannon br...@python.org wrote: Your clone will contain the following branches: $ hg branches default68026:f12ef116dd10 3.268025:cef92ee1a323 2.768010:8174d00d0797 3.167955:5be8b695ea86 2.667287:5e26a860eded 2.565464:e4ecac76e499 trunk 62750:800f6c92c3ed 3.060075:1d05144224fe 2.458552:df72cac1899e 2.345731:a3d9a9730743 2.240444:d55ddc8c8501 2.130171:06fcccf6eca8 2.018214:dc0dfc9565cd The branch default is the current py3k branch from SVN. The branch trunk represents SVN trunk history until 2.7 was branched for maintenance. Just to help justify it in my head, the trunk branch exists for the history and nothing more, right? True. Could we actually close the branch so it isn't even visible by default to prevent confusing people? Yes, we can. This can be done post-conversion, actually. Something like: $ hg up trunk $ hg ci --close-branch -m Close trunk 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] Mercurial conversion repositories
On 25.02.2011 09:25, Martin v. Löwis wrote: Am 25.02.2011 09:17, schrieb Dirkjan Ochtman: On Fri, Feb 25, 2011 at 09:09, Martin v. Löwis mar...@v.loewis.de 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). Unnamed heads are trivial to convert to clones. If there are hundreds of them, it's far from trivial. I don't even know how to find out which one to convert. The full-history repo has several ways to get at that information, so it's quite for us to extract feature branches as separate clones. Since most side-track branches won't actually be needed anymore, we'd like to reconstruct them on request. I assume you'd like to have pep-0383? 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] Mercurial conversion repositories
On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote: On Feb 25, 2011, at 12:09 AM, 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). In my brief tests, the single repository has been easy to work with. If they were separate, it would complicate backporting patches and merges. So, I'm happy with how George and Benjamin put this together. The way I work with the Subversion branches is to have all the active branches checked out into separate directories under a common parent, e.g. ~/projects/python/py26 ~/projects/python/py27 ~/projects/python/trunk ~/projects/python/py31 ~/projects/python/py32 ~/projects/python/py3k This makes it very easy to just cd, svn up, make distclean, configure, make to test things. How can I do this with the hg clone when all the branches are in the single repository, but more or less hidden? After doing the 'hg clone' operation specified by Antoine, I'm left with a single cpython directory containing (iiuc) the contents of the 'default' branch. I'm sure I'm not the only one who works this way with Subversion. IWBN to cover this in the devguide (or is it there and I missed it?). Cheers, -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] 3.2.0 == 20th anniversary release
On Wed, Feb 23, 2011 at 10:30 PM, Georg Brandl g.bra...@gmx.net wrote: On 23.02.2011 20:43, Martin v. Löwis wrote: 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. Uh oh. Temporal mechanics gives me headaches. While SciPy conference folks are inventing pythonic API for that stuff, the most we can do now is analyze reasons for missing goals and aims from this period, and try to neutralize their effect as the Python grows. -- 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] Mercurial conversion repositories
Hi Barry, The way I work with the Subversion branches is to have all the active branches checked out into separate directories under a common parent, e.g. ~/projects/python/py26 ~/projects/python/py27 ~/projects/python/trunk ~/projects/python/py31 ~/projects/python/py32 ~/projects/python/py3k This makes it very easy to just cd, svn up, make distclean, configure, make to test things. How can I do this with the hg clone when all the branches are in the single repository, but more or less hidden? After doing the 'hg clone' operation specified by Antoine, I'm left with a single cpython directory containing (iiuc) the contents of the 'default' branch. Indeed, the default branch is checked out by default. But you can switch to another branch: $ hg sum parent: 68026:f12ef116dd10 tip In FTP.close() method, make sure to also close the socket object, not only the file. branch: default commit: (clean) update: (current) $ hg up 2.7 3310 files updated, 0 files merged, 378 files removed, 0 files unresolved $ hg sum parent: 68010:8174d00d0797 Merged revisions 88486 via svnmerge from branch: 2.7 commit: (clean) update: (current) (hg sum is a shorthand for hg summary) Furthermore, once you have a local clone, you can clone it further to get several independent clones, and keep each of them updated on whatever branch you want. This makes it easy to replicate your workflow (by having a master clone - a mirror if you want - and then child clones that get updated from the master clone by running hg pull). I'm sure I'm not the only one who works this way with Subversion. IWBN to cover this in the devguide (or is it there and I missed it?). Use of hg update to switch between branches is mentioned in http://potrou.net/hgdevguide/setup.html#getting-the-source-code and also http://potrou.net/hgdevguide/coredev.html#read-write-checkout and also in http://potrou.net/hgdevguide/committing.html#porting-within-a-major-version. But a dedicated FAQ entry could be added. 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] Mercurial conversion repositories
On 25.02.2011 17:12, Barry Warsaw wrote: On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote: On Feb 25, 2011, at 12:09 AM, 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). In my brief tests, the single repository has been easy to work with. If they were separate, it would complicate backporting patches and merges. So, I'm happy with how George and Benjamin put this together. The way I work with the Subversion branches is to have all the active branches checked out into separate directories under a common parent, e.g. ~/projects/python/py26 ~/projects/python/py27 ~/projects/python/trunk ~/projects/python/py31 ~/projects/python/py32 ~/projects/python/py3k This makes it very easy to just cd, svn up, make distclean, configure, make to test things. How can I do this with the hg clone when all the branches are in the single repository, but more or less hidden? After doing the 'hg clone' operation specified by Antoine, I'm left with a single cpython directory containing (iiuc) the contents of the 'default' branch. Two scenarios are possible: * You make a clone per branch with the full history, with the current branch being different in each of those. Since hg update updates to the head of the current branch, this should be easy to do. When you pull from the single repo you will get changes for the other branches as well, but they will not bother you. * You make a clone per branch, containing *only* the respective branch (with its ancestors). This is done by using URI#branchname as the source when cloning/pulling. Both should work equally well, with the former giving larger repository sizes, and the latter taking somewhat longer on the initial clone. 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] Mercurial conversion repositories
On 25.02.2011 17:31, Georg Brandl wrote: On 25.02.2011 17:12, Barry Warsaw wrote: On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote: On Feb 25, 2011, at 12:09 AM, 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). In my brief tests, the single repository has been easy to work with. If they were separate, it would complicate backporting patches and merges. So, I'm happy with how George and Benjamin put this together. The way I work with the Subversion branches is to have all the active branches checked out into separate directories under a common parent, e.g. ~/projects/python/py26 ~/projects/python/py27 ~/projects/python/trunk ~/projects/python/py31 ~/projects/python/py32 ~/projects/python/py3k This makes it very easy to just cd, svn up, make distclean, configure, make to test things. How can I do this with the hg clone when all the branches are in the single repository, but more or less hidden? After doing the 'hg clone' operation specified by Antoine, I'm left with a single cpython directory containing (iiuc) the contents of the 'default' branch. Two scenarios are possible: * You make a clone per branch with the full history, with the current branch being different in each of those. Since hg update updates to the head of the current branch, this should be easy to do. When you pull from the single repo you will get changes for the other branches as well, but they will not bother you. * You make a clone per branch, containing *only* the respective branch (with its ancestors). This is done by using URI#branchname as the source when cloning/pulling. Both should work equally well, with the former giving larger repository sizes, and the latter taking somewhat longer on the initial clone. Ah, and the latter obviously also won't work with the hg-native workflow (merging between the branches using hg merge). 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
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2011-02-18 - 2011-02-25)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open2682 (+27)
closed 20422 (+52)
total 23104 (+79)
Open issues with patches: 1137
Issues opened (56)
==
#11244: Negative tuple elements produce inefficient code.
http://bugs.python.org/issue11244 opened by jdharper
#11245: Implementation of IMAP IDLE in imaplib?
http://bugs.python.org/issue11245 opened by Shay.Rojansky
#11246: PyUnicode_FromFormat(%V) decodes the byte string from ISO-88
http://bugs.python.org/issue11246 opened by haypo
#11247: Error sending packets to multicast IPV4 address
http://bugs.python.org/issue11247 opened by dmahn
#11250: 2to3 truncates files at formfeed character
http://bugs.python.org/issue11250 opened by cgohlke
#11253: autodocument first appearance of ctypes.wintypes constants
http://bugs.python.org/issue11253 opened by techtonik
#11254: distutils doesn't byte-compile .py files to __pycache__ during
http://bugs.python.org/issue11254 opened by scoder
#11255: 2to3 throws AttributeError during distutils installation with
http://bugs.python.org/issue11255 opened by scoder
#11256: inspect.getcallargs raises TypeError on valid arguments
http://bugs.python.org/issue11256 opened by durban
#11257: asyncore stores unnecessary object references
http://bugs.python.org/issue11257 opened by mmarkk
#11258: ctypes: Speed up find_library() on Linux by 500%
http://bugs.python.org/issue11258 opened by jonash
#11259: asynchat does not check if terminator is negative integer
http://bugs.python.org/issue11259 opened by mmarkk
#11260: smtpd-as-a-script feature should be documented and should use
http://bugs.python.org/issue11260 opened by xmorel
#11261: urlopen breaks when data parameter is used.
http://bugs.python.org/issue11261 opened by david193
#11265: asyncore does not check for EAGAIN errno
http://bugs.python.org/issue11265 opened by mmarkk
#11266: asyncore does not handle EINTR in recv, send, connect, accept,
http://bugs.python.org/issue11266 opened by mmarkk
#11267: asyncore does not check for POLLERR and POLLHUP if neither rea
http://bugs.python.org/issue11267 opened by mmarkk
#11270: logging: RotatingFileHandler crash when opening the Logfile in
http://bugs.python.org/issue11270 opened by RockstarVC
#11271: concurrent.futures.ProcessPoolExecutor.map() slower than multi
http://bugs.python.org/issue11271 opened by tbrink
#11273: asyncore creates selec (or poll) on every iteration
http://bugs.python.org/issue11273 opened by mmarkk
#11275: Linking to gcc's gomp causes crash later.
http://bugs.python.org/issue11275 opened by hoytak
#11276: 2to3: imports fixer doesn't update references to modules speci
http://bugs.python.org/issue11276 opened by Arfrever
#11279: test_posix and lack of id -G support - less noise required?
http://bugs.python.org/issue11279 opened by illumino
#11281: smtplib: add ability to bind to specific source IP address/por
http://bugs.python.org/issue11281 opened by paulos
#11282: unittest document not keep consist with code
http://bugs.python.org/issue11282 opened by ysj.ray
#11283: incorrect pattern in the re module docs for conditional regex
http://bugs.python.org/issue11283 opened by wesley.chun
#11284: slow close file descriptors in subprocess, popen2, os.pepen*
http://bugs.python.org/issue11284 opened by s7v7nislands
#11287: Add context manager support to dbm modules
http://bugs.python.org/issue11287 opened by ysj.ray
#11289: smtplib context manager
http://bugs.python.org/issue11289 opened by giampaolo.rodola
#11290: ttk.Combobox['values'] String Conversion to Tcl
http://bugs.python.org/issue11290 opened by claytondarwin
#11291: poplib suppresses exception on QUIT
http://bugs.python.org/issue11291 opened by giampaolo.rodola
#11292: Curses - add A_REVERSE to attributes table
http://bugs.python.org/issue11292 opened by sandro.tosi
#11293: Distutils - read the file when using it in long_description
http://bugs.python.org/issue11293 opened by sandro.tosi
#11294: Locale - update uniform ERA_*_FMT doc
http://bugs.python.org/issue11294 opened by sandro.tosi
#11297: Make ChainMap() public in the collections module.
http://bugs.python.org/issue11297 opened by rhettinger
#11298: unittest discovery needs better explanation
http://bugs.python.org/issue11298 opened by blokeley
#11299: Allow deepcopying and pickling paused generators
http://bugs.python.org/issue11299 opened by cool-RR
#11300: mmap() large file failures on Mac OS X docfix
http://bugs.python.org/issue11300 opened by sdaoden
#11302: Add more tests to test_ast.py
http://bugs.python.org/issue11302 opened by vincele
#11303: b'x'.decode('latin1') is much slower than b'x'.decode('latin-1
http://bugs.python.org/issue11303 opened by belopolsky
#11305: TextIOWrapper.readline and
Re: [Python-Dev] Mercurial conversion repositories
On Fri, 25 Feb 2011 13:52:58 +0100 Antoine Pitrou solip...@pitrou.net wrote: On Fri, 25 Feb 2011 19:13:49 +1100 Neil Hodgson nyamaton...@gmail.com wrote: With hg 1.7.5 on Windows 7 I performed a non-core checkout: hg clone http://hg.python.org/cpython The eol extension is enabled in global settings. Yes, please try to disable it. The issue is we have a .hgeol in the repository right now (it's in the SVN repository too), but it doesn't match the reality of on-disk files, so when you update, the eol extension tries to fix those files. It should now be fixed in current SVN, meaning the final conversion should be perfectly usable with the eol extension enabled. Do you find other issues under Windows? Have you tried pushing changes? 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] r88580 - in python/branches/py3k: Doc/library/os.rst Doc/whatsnew/3.3.rst Lib/test/test_os.py Misc/NEWS Modules/posixmodule.c configure.in pyconfig.h.in
On Fri, 25 Feb 2011 15:39:16 +0100 (CET) giampaolo.rodola python-check...@python.org wrote: +#else +*((off_t*)addr) = PyLong_Check(arg) ? PyLong_AsLongLong(arg) +: PyLong_AsLong(arg); +#endif There's something fishy here. Why would you call PyLong_AsLong() if PyLong_Check() is false? 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] Mercurial conversion repositories
On 2011-02-25 17:12, Barry Warsaw wrote: On Feb 25, 2011, at 01:50 AM, Raymond Hettinger wrote: On Feb 25, 2011, at 12:09 AM, 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). In my brief tests, the single repository has been easy to work with. If they were separate, it would complicate backporting patches and merges. So, I'm happy with how George and Benjamin put this together. The way I work with the Subversion branches is to have all the active branches checked out into separate directories under a common parent, e.g. ~/projects/python/py26 ~/projects/python/py27 ~/projects/python/trunk ~/projects/python/py31 ~/projects/python/py32 ~/projects/python/py3k This makes it very easy to just cd, svn up, make distclean, configure, make to test things. How can I do this with the hg clone when all the branches are in the single repository, but more or less hidden? After doing the 'hg clone' operation specified by Antoine, I'm left with a single cpython directory containing (iiuc) the contents of the 'default' branch. I'm sure I'm not the only one who works this way with Subversion. IWBN to cover this in the devguide (or is it there and I missed it?). I know (almost) nothing about developing Python (this is my first post to this list after lurking for quite a while now), but as a regular Mercurial contributor, I think the following could be useful for you: First, get an initial clone (let's name it 'master') over the wire using: [1] $ hg clone -U ssh://h...@hg.python.org/cpython master Then create a hardlinked clone [2] for working in each branch, specifying the branch to check out using option -u: $ hg clone master py26 -u 2.6 updating to branch 2.6 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone master py27 -u 2.7 updating to branch 2.7 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone master trunk -u trunk updating to branch trunk NNN files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone master py31 -u 3.1 updating to branch 3.1 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone master py32 -u 3.2 updating to branch 3.2 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved This will be fast and save space as these local 'branch clones' will share diskspace inside .hg/store by using hardlinks, and you need to do the initial slow clone over the wire only once. Note that each of these branch clones will initially have your local master repo as the default path [3,4]. If you'd like to have the default push/pull path to point to ssh://h...@hg.python.org/cpython instead, you'd want to edit the [paths] section in the .hg/hgrc file in each of the branch repos. But of course you can also leave the default paths as they are and synchronize via the master repo (e.g. pull new changesets into master first, and then pull into the specific branch repo). [1] http://selenic.com/repo/hg/help/clone [2] http://mercurial.selenic.com/wiki/HardlinkedClones [3] http://www.selenic.com/mercurial/hgrc.5.html#paths [4] http://selenic.com/repo/hg/help/urls ___ 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] Finding buildbot failures
What's the easiest way of finding which tests failed on buildbot builds? I mean, is there anything easier than using the Web interface to browse to failing builds and then looking at the stdio output in a browser? Thanks, Vinay Sajip ___ 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] r88580 - in python/branches/py3k: Doc/library/os.rst Doc/whatsnew/3.3.rst Lib/test/test_os.py Misc/NEWS Modules/posixmodule.c configure.in pyconfig.h.in
On Fri, 2011-02-25 at 18:32 +0100, Antoine Pitrou wrote: On Fri, 25 Feb 2011 15:39:16 +0100 (CET) giampaolo.rodola python-check...@python.org wrote: +#else +*((off_t*)addr) = PyLong_Check(arg) ? PyLong_AsLongLong(arg) +: PyLong_AsLong(arg); +#endif There's something fishy here. Why would you call PyLong_AsLong() if PyLong_Check() is false? I'm not entirely sure how that works (other than it seems to!). The code came from other places where large file support is, such as in ftruncate() and lseek() in the posix module. Ross ___ 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/rosslagerwall%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] r88580 - in python/branches/py3k: Doc/library/os.rst Doc/whatsnew/3.3.rst Lib/test/test_os.py Misc/NEWS Modules/posixmodule.c configure.in pyconfig.h.in
Le vendredi 25 février 2011 à 20:11 +0200, Ross Lagerwall a écrit : On Fri, 2011-02-25 at 18:32 +0100, Antoine Pitrou wrote: On Fri, 25 Feb 2011 15:39:16 +0100 (CET) giampaolo.rodola python-check...@python.org wrote: +#else +*((off_t*)addr) = PyLong_Check(arg) ? PyLong_AsLongLong(arg) +: PyLong_AsLong(arg); +#endif There's something fishy here. Why would you call PyLong_AsLong() if PyLong_Check() is false? I'm not entirely sure how that works (other than it seems to!). The code came from other places where large file support is, such as in ftruncate() and lseek() in the posix module. Ok, then I guess that code was ported straightly from 2.x without really a thought. Thanks for your contribution, by the way! 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] Finding buildbot failures
On Fri, 25 Feb 2011 18:10:28 + (UTC) Vinay Sajip vinay_sa...@yahoo.co.uk wrote: What's the easiest way of finding which tests failed on buildbot builds? I mean, is there anything easier than using the Web interface to browse to failing builds and then looking at the stdio output in a browser? Not really, but that becomes quite easy once you're used to it. Good luck :) 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] Finding buildbot failures
On 25/02/2011 18:10, Vinay Sajip wrote: What's the easiest way of finding which tests failed on buildbot builds? I mean, is there anything easier than using the Web interface to browse to failing builds and then looking at the stdio output in a browser? 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. Michael Thanks, Vinay Sajip ___ 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] Finding buildbot failures
On 25.02.2011 19:10, Vinay Sajip wrote: What's the easiest way of finding which tests failed on buildbot builds? I mean, is there anything easier than using the Web interface to browse to failing builds and then looking at the stdio output in a browser? Once every failure sent a mail to python-checkins; I had modified the email reporting to include as much info about the failed test as possible. However, there were so many of these emails that we discontinued sending them. 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] Finding buildbot failures
On 06:47 pm, fuzzy...@voidspace.org.uk wrote: On 25/02/2011 18:10, Vinay Sajip wrote: What's the easiest way of finding which tests failed on buildbot builds? I mean, is there anything easier than using the Web interface to browse to failing builds and then looking at the stdio output in a browser? 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, although it does need *some* parseable format, which I think the Python test suite is a long way from. Jean-Paul ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython (2.7): Update copyright years.
2011/2/25 barry.warsaw python-check...@python.org: barry.warsaw pushed 9619d21d8198 to cpython: http://hg.python.org/cpython/rev/9619d21d8198 changeset: 68030:9619d21d8198 branch: 2.7 tag: tip parent: 68010:8174d00d0797 user: Barry Warsaw ba...@python.org date: Fri Feb 25 14:35:22 2011 -0500 summary: Update copyright years. files: Python/Python-ast.c README diff --git a/Python/Python-ast.c b/Python/Python-ast.c --- a/Python/Python-ast.c +++ b/Python/Python-ast.c @@ -2,7 +2,7 @@ /* - __version__ 82160. + __version__ . Ah, this reminds me. Figuring out what to do with the AST version should probably be a hg roadmap topic. -- Regards, Benjamin ___ 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] Mercurial conversion repositories
On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote: First, get an initial clone (let's name it 'master') over the wire using: [1] $ hg clone -U ssh://h...@hg.python.org/cpython master Then create a hardlinked clone [2] for working in each branch, specifying the branch to check out using option -u: $ hg clone master py26 -u 2.6 updating to branch 2.6 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone master py27 -u 2.7 updating to branch 2.7 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone master trunk -u trunk updating to branch trunk NNN files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone master py31 -u 3.1 updating to branch 3.1 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved $ hg clone master py32 -u 3.2 updating to branch 3.2 NNN files updated, 0 files merged, 0 files removed, 0 files unresolved Note that each of these branch clones will initially have your local master repo as the default path [3,4]. If you'd like to have the default push/pull path to point to ssh://h...@hg.python.org/cpython instead, you'd want to edit the [paths] section in the .hg/hgrc file in each of the branch repos. Thanks very much Adrian, this is exactly what I was looking for. It maps almost directly to my current mental model for working on Python in Subversion (and truth be told, also how I do/did it with Bazaar). It does leave me with an empty 'master' directory that I basically won't touch, though I suppose I could hide it in a dot-filename. And I have to remember to fiddle with .hg/hgrc when I clone a new branch working directory, but I guess that's mostly a one-time cost. I'll have to remember that 'hg pull' does not update the working copy by default, and eventually I'll figure out the whole merge thing. One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes my editor and always shows me a 'diff -u' in the commit message buffer. This is incredibly handy because I don't have to remember to do the diff in a different window, and I always have all the information I want right there to craft the commit message. It doesn't look like this is possible with 'hg commit' though, right? Cheers, -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] [Python-checkins] cpython (2.7): Update copyright years.
On Feb 25, 2011, at 01:39 PM, Benjamin Peterson wrote: Ah, this reminds me. Figuring out what to do with the AST version should probably be a hg roadmap topic. Is there a bug tracker for the conversion? -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] [Python-checkins] cpython (2.7): Update copyright years.
On 25.02.2011 20:45, Barry Warsaw wrote: On Feb 25, 2011, at 01:39 PM, Benjamin Peterson wrote: Ah, this reminds me. Figuring out what to do with the AST version should probably be a hg roadmap topic. Is there a bug tracker for the conversion? There's todo.txt in the pymigr repo. 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] Mercurial conversion repositories
On Fri, 25 Feb 2011 14:43:15 -0500 Barry Warsaw ba...@python.org wrote: I'll have to remember that 'hg pull' does not update the working copy by default, and eventually I'll figure out the whole merge thing. You can use hg pull -u to update (and hg pull -uv if you want to see the list of updated files). One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes my editor and always shows me a 'diff -u' in the commit message buffer. This is incredibly handy because I don't have to remember to do the diff in a different window, and I always have all the information I want right there to craft the commit message. It doesn't look like this is possible with 'hg commit' though, right? Should be customizable: http://mercurial.selenic.com/wiki/CommitMessageTemplate http://mercurial.selenic.com/wiki/DiffsInCommitMessageInVIM (never tried myself) 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] Mercurial conversion repositories
On 25/02/2011 20:43, Barry Warsaw wrote: One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes my editor and always shows me a 'diff -u' in the commit message buffer. This is incredibly handy because I don't have to remember to do the diff in a different window, and I always have all the information I want right there to craft the commit message. It doesn't look like this is possible with 'hg commit' though, right? What you are asking for is available in TortoiseHg which absolutely rocks (if you are not allergic to the idea of a graphical tool). You can even select indvidually inside a file which lines to commit or not. A bit risky but very handy when you have a few oneliners to commit or not to commit. cheers, Philippe ___ 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] Mercurial conversion repositories
Antoine Pitrou: It should now be fixed in current SVN, meaning the final conversion should be perfectly usable with the eol extension enabled. Good. Do you find other issues under Windows? Have you tried pushing changes? Since I'm not a member of core developers I used a http pull and can't push: C:\u\cpythonhg push pushing to http://hg.python.org/cpython searching for changes remote: ssl required Neil ___ 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] Mercurial conversion repositories
Le samedi 26 février 2011 à 08:40 +1100, Neil Hodgson a écrit : Antoine Pitrou: It should now be fixed in current SVN, meaning the final conversion should be perfectly usable with the eol extension enabled. Good. Do you find other issues under Windows? Have you tried pushing changes? Since I'm not a member of core developers I used a http pull and can't push: Ok, well that's expected then ;) Sorry for the confusion. 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] Mercurial conversion repositories
On Feb 25, 2011, at 09:04 PM, Philippe Fremy wrote: What you are asking for is available in TortoiseHg which absolutely rocks (if you are not allergic to the idea of a graphical tool). Like shellfish, bee-strings, and Perl I'm afraid. :) You can even select indvidually inside a file which lines to commit or not. A bit risky but very handy when you have a few oneliners to commit or not to commit. You mean, TortoiseHg supports incremental commits on a single file? That's kind of neat, but scary. ;) -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] r88589 - python/branches/py3k/Lib/test/test_logging.py
On Fri, 25 Feb 2011 18:02:43 +0100 (CET)
vinay.sajip python-check...@python.org wrote:
Author: vinay.sajip
Date: Fri Feb 25 18:02:43 2011
New Revision: 88589
Log:
logging: enabled test which was intermittently failing on buildbots.
Looks like it fails again:
(
http://www.python.org/dev/buildbot/all/builders/x86%20Windows7%203.x/builds/2671/steps/test/logs/stdio
)
==
ERROR: test_compute_rollover_MIDNIGHT
(test.test_logging.TimedRotatingFileHandlerTest)
--
Traceback (most recent call last):
File
D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py,
line 1990, in tearDown
os.unlink(self.fn)
WindowsError: [Error 32] The process cannot access the file because it is being
used by another process:
'c:\\users\\db3l\\appdata\\local\\temp\\test_logging-2-vhc3k5.log'
==
FAIL: test_compute_rollover_MIDNIGHT
(test.test_logging.TimedRotatingFileHandlerTest)
--
Traceback (most recent call last):
File
D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py,
line 2053, in test_compute_rollover
self.assertEqual(exp, rh.computeRollover(0.0))
AssertionError: 82800 != 18000.0
==
FAIL: test_compute_rollover_S (test.test_logging.TimedRotatingFileHandlerTest)
--
Traceback (most recent call last):
File
D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py,
line 1981, in setUp
BaseTest.setUp(self)
File
D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py,
line 95, in setUp
raise AssertionError('Unexpected handlers: %s' % hlist)
AssertionError: Unexpected handlers: [logging.StreamHandler object at
0x0DAFC5B0]
==
FAIL: test_compute_rollover_W0 (test.test_logging.TimedRotatingFileHandlerTest)
--
Traceback (most recent call last):
File
D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py,
line 1981, in setUp
BaseTest.setUp(self)
File
D:\cygwin\home\db3l\buildarea\3.x.bolen-windows7\build\lib\test\test_logging.py,
line 95, in setUp
raise AssertionError('Unexpected handlers: %s' % hlist)
AssertionError: Unexpected handlers: [logging.StreamHandler object at
0x0DAFC5B0]
___
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] Let's get PEP 380 into Python 3.3
Now that the language moratorium is lifted, let's make sure to get PEP 380 implemented for Python 3.3. I think there are some minor issues to be resolved, but I don't think that should stop someone from doing a first pass of the implementation (especially since a version for 2.6 already exists). (OTOH I am not much enamored with cofunctions, PEP 3152.) -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get PEP 380 into Python 3.3
From: Guido van Rossum (OTOH I am not much enamored with cofunctions, PEP 3152.) That's okay, I don't like it much myself in its current form. I plan to revisit it at some point, but there's no hurry. -- Greg This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information. ___ 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] Mercurial conversion repositories
On 25Feb2011 14:43, Barry Warsaw ba...@python.org wrote: | [...] And I have to | remember to fiddle with .hg/hgrc when I clone a new branch working directory, | but I guess that's mostly a one-time cost. Hmm. Why do you need to fiddle with the hgrc? Just curious. | I'll have to remember that 'hg pull' does not update the working copy by | default, and eventually I'll figure out the whole merge thing. hg fetch does though. That's my usual incanation. | One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes | my editor and always shows me a 'diff -u' in the commit message buffer. This | is incredibly handy because I don't have to remember to do the diff in a | different window, and I always have all the information I want right there to | craft the commit message. It doesn't look like this is possible with 'hg | commit' though, right? CVS had that problem. I had a wrapper somewhere that masquerades as $EDITOR and writes a diff into the commit buffer as you describe. [ Digs through my hg repository... ] Ok; then it took the form of a script called cvscommit that set $EDITOR to the command cvscommit-editor, wrote the diff stuff, invoked cvs commit. That ran cvscommit-editor, which invoked the old $EDITOR and off you went. I would think editing the hgrc to set the hg editor and using the commit hooks would streamline this for Mercurial so you could do the usual hg commit command without going through the outer wrapper. I'll devote a little time today, since I've missed this little hack:-( Interested? Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ We don't just *borrow* words; on occasion, English has pursued other languages down alleyways to beat them unconscious and rifle their pockets for new vocabulary. - James D. Nicoli ___ 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] Let's get PEP 380 into Python 3.3
Ok. Will you hvae time to port your patches to 3.3? On Fri, Feb 25, 2011 at 3:01 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: From: Guido van Rossum (OTOH I am not much enamored with cofunctions, PEP 3152.) That's okay, I don't like it much myself in its current form. I plan to revisit it at some point, but there's no hurry. -- Greg This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Let's get PEP 380 into Python 3.3
On Fri, Feb 25, 2011 at 5:43 PM, Guido van Rossum gu...@python.org wrote: Now that the language moratorium is lifted, let's make sure to get PEP 380 implemented for Python 3.3. I think there are some minor issues to be resolved, but I don't think that should stop someone from doing a first pass of the implementation (especially since a version for 2.6 already exists). (OTOH I am not much enamored with cofunctions, PEP 3152.) Yay! ___ 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] Let's get PEP 380 into Python 3.3
On Fri, Feb 25, 2011 at 8:01 PM, Greg Ewing greg.ew...@canterbury.ac.nz wrote: From: Guido van Rossum (OTOH I am not much enamored with cofunctions, PEP 3152.) That's okay, I don't like it much myself in its current form. I plan to revisit it at some point, but there's no hurry. I've just gone through PEP 3152 - and the first though that occurred me is that a decorator is perfectly usable instead of the new proposed keyword codef. (It would need to be able to set special attributes in the function to indicate its nature) Besides not adding a new keyword, it would allow for different (concurrently running? ) types of co-functions to be created and benefit from the other mechanisms. But maybe considerations about this should be take place on python-ideas only? -- Greg ___ 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] Mercurial conversion repositories
Hi, Le 25/02/2011 20:43, Barry Warsaw a écrit : On Feb 25, 2011, at 06:40 PM, Adrian Buehlmann wrote: [snip] Note that each of these branch clones will initially have your local master repo as the default path [3,4]. If you'd like to have the default push/pull path to point to ssh://h...@hg.python.org/cpython instead, you'd want to edit the [paths] section in the .hg/hgrc file in each of the branch repos. I plan on having one clone per branch but pushing and pulling from only one repository, so I don’t need to edit hgrcs. It does leave me with an empty 'master' directory that I basically won't touch, though I suppose I could hide it in a dot-filename. Or have the master clone do double duty as the py3k clone. (IOW, I have 2.7 3.1 3.2 py3k, I pull/push in py3k and also do merges and new features in py3k). And I have to remember to fiddle with .hg/hgrc when I clone a new branch working directory, but I guess that's mostly a one-time cost. You don’t, see above. I’ve wanted to tell you something for a long time: Mercurial branches are not at all like Bazaar branches. See http://mercurial.selenic.com/wiki/Branch and http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-mercurial/ Anecdote: I migrated from Subversion to Mercurial a few years ago, and found Mercurial branches very intuitive. When I saw mentions of Bazaar branches I was driven nuts by (what I saw as) the conflation between a branch and a clone. Later I understood how it made sense from the perspective of Bazaar, so I shifted my judgment from “insanely confusing” to “a particular choice that I don’t approve” wink. What I’m saying is that a lot of Bazaar terminology using “branch” does not map as-is to Mercurial. We clone a repo, we pull from a repo/clone, we have named branches (e.g. 3.2) in a repo, we have unnamed branches on one named branch. I think you know that already, since you went from using Bazaar terms applied to Mercurial to mixing terms from both (“clone a new branch working directory” → “clone a repo”, probably). I salute your willingness to learn Mercurial, considering how fluent (and fluffly) you appear to be with Bazaar. I'll have to remember that 'hg pull' does not update the working copy by default, That pull does not update is a feature: The operation between a remote repo and the local repo (the .hg directory) is separate from the operation from the local repo to the working directory. When you know that you want pull + update (like when you have a clean working directory), you use “hg pull -u”. (I don’t like the fetch command.) and eventually I'll figure out the whole merge thing. Without anything specific, I’ll point to some resources: Short tuto: http://hginit.com/04.html Concepts and examples: http://mercurial.selenic.com/wiki/Merge Longer narratives: http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html One immediate thing that I'm missing from Bazaar is that 'bzr commit' invokes my editor and always shows me a 'diff -u' in the commit message buffer. This is incredibly handy because I don't have to remember to do the diff in a different window, and I always have all the information I want right there to craft the commit message. You speak to my heart, sir. In your ~/.hgrc, under the section [ui], set “editor = path/to/mercurial/source/hgeditor” and enjoy your diffs. I use it and love it. If you want to commit a subset of your local changes, I use http://mercurial.selenic.com/wiki/CrecordExtension , a curses-based diff selection UI that works like a charm. Kind regards, your friendly Mercurial whippersnapper ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] 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, of course, free to establish any workflow they deem appropriate. +* adapt build identification for Windows build process I think this should also be done before the migration. 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] Finding buildbot failures
On 25/02/2011 20.10, Vinay Sajip wrote: What's the easiest way of finding which tests failed on buildbot builds? I mean, is there anything easier than using the Web interface to browse to failing builds and then looking at the stdio output in a browser? You can try bbreport (http://code.google.com/p/bbreport/wiki/Screenshots): hg clone https://bbreport.googlecode.com/hg/ bbreport cd bbreport python bbreport --help python bbreport 3.x (There is some issue with hg revision numbers that I haven't fixed yet, but the above command should work fine) Best Regards, Ezio Melotti Thanks, Vinay Sajip ___ 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/ezio.melotti%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] Mercurial conversion repositories
On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou solip...@pitrou.net wrote: $ hg branches default 68026:f12ef116dd10 3.2 68025:cef92ee1a323 2.7 68010:8174d00d0797 3.1 67955:5be8b695ea86 2.6 67287:5e26a860eded 2.5 65464:e4ecac76e499 trunk 62750:800f6c92c3ed 3.0 60075:1d05144224fe 2.4 58552:df72cac1899e 2.3 45731:a3d9a9730743 2.2 40444:d55ddc8c8501 2.1 30171:06fcccf6eca8 2.0 18214:dc0dfc9565cd The branch default is the current py3k branch from SVN. The branch trunk represents SVN trunk history until 2.7 was branched for maintenance. Would it be possible to name trunk as 2.x instead? Otherwise I could see people getting confused and asking why trunk was closed, and/or not the same as default. Looking very nice, though! :) 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] Mercurial conversion repositories
On Sat, 26 Feb 2011 12:32:04 +1000 Nick Coghlan ncogh...@gmail.com wrote: On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou solip...@pitrou.net wrote: $ hg branches default 68026:f12ef116dd10 3.2 68025:cef92ee1a323 2.7 68010:8174d00d0797 3.1 67955:5be8b695ea86 2.6 67287:5e26a860eded 2.5 65464:e4ecac76e499 trunk 62750:800f6c92c3ed 3.0 60075:1d05144224fe 2.4 58552:df72cac1899e 2.3 45731:a3d9a9730743 2.2 40444:d55ddc8c8501 2.1 30171:06fcccf6eca8 2.0 18214:dc0dfc9565cd The branch default is the current py3k branch from SVN. The branch trunk represents SVN trunk history until 2.7 was branched for maintenance. Would it be possible to name trunk as 2.x instead? Otherwise I could see people getting confused and asking why trunk was closed, and/or not the same as default. That was my first idea, but then I realized that the branch includes 1.x and even pre-1.0 commits, so 2.x might actually be more confusing/misleading and hide the fact that the full trunk history is there. 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). (*) but it's not any special really, it's just the branch you get by... default ;) 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] Mercurial conversion repositories
On 26.02.2011 03:32, Nick Coghlan wrote: On Fri, Feb 25, 2011 at 10:19 AM, Antoine Pitrou solip...@pitrou.net wrote: $ hg branches default68026:f12ef116dd10 3.268025:cef92ee1a323 2.768010:8174d00d0797 3.167955:5be8b695ea86 2.667287:5e26a860eded 2.565464:e4ecac76e499 trunk 62750:800f6c92c3ed 3.060075:1d05144224fe 2.458552:df72cac1899e 2.345731:a3d9a9730743 2.240444:d55ddc8c8501 2.130171:06fcccf6eca8 2.018214:dc0dfc9565cd The branch default is the current py3k branch from SVN. The branch trunk represents SVN trunk history until 2.7 was branched for maintenance. Would it be possible to name trunk as 2.x instead? Otherwise I could see people getting confused and asking why trunk was closed, and/or not the same as default. Problem is, you then have 1.5.2 released from the 2.x branch :) 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
