Re: [Python-Dev] [python-committers] How shall we conduct the Python 3.5 beta and rc periods? (Please vote!)
On Tue, May 12, 2015 at 4:36 PM, Larry Hastings wrote: > BTW, this workload was exacerbated by my foolish desire to keep the revision > DAG nice and clean. So I was actually starting over from scratch and > redoing all the cherry-picking every couple of days, just so I could get all > the cherry-picked revisions in strict chronological order. By the end I had > evolved a pretty elaborate guided-process automation script to do all the > cherry-picking, which you can see here if you're curious: Couldn't you just keep this as a branch that you then keep rebasing (without unlinking the original branch)? It doesn't seem like something that needs a one-off script, to me. Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add Gentoo packagers of external modules to Misc/ACKS
Tae Wong, Please don't speak on behalf the Gentoo Python team. Everyone else, sorry for this, they are definitely not actually connected to our Gentoo team. Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cffi in stdlib
On Tue, Feb 26, 2013 at 4:13 PM, Maciej Fijalkowski wrote: > I would like to discuss on the language summit a potential inclusion > of cffi[1] into stdlib. This is a project Armin Rigo has been working > for a while, with some input from other developers. It seems that the > main reason why people would prefer ctypes over cffi these days is > "because it's included in stdlib", which is not generally the reason I > would like to hear. Our calls to not use C extensions and to use an > FFI instead has seen very limited success with ctypes and quite a lot > more since cffi got released. The API is fairly stable right now with > minor changes going in and it'll definitely stablize until Python 3.4 > release. I think this would be great to have in the stdlib. I think it's useful to note that PyPy is planning to include this in their stdlib for the next release, too, right? 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] casefolding in pathlib (PEP 428)
On Thu, Apr 11, 2013 at 11:27 PM, Antoine Pitrou wrote: > Hmm, I think I'm tending towards the latter right now. You might also want to look at what Mercurial does. As a cross-platform filesystem-oriented tool, it has some interesting issues in the department of casefolding. 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] PEP 435 -- Adding an Enum type to the Python standard library
On Fri, Apr 12, 2013 at 2:55 PM, Eli Bendersky wrote: > Ordered comparisons between enumeration values are *not* supported. Enums > are > not integers (but see `IntEnum`_ below):: > > >>> Colors.red < Colors.blue > Traceback (most recent call last): > ... > NotImplementedError > >>> Colors.red <= Colors.blue > Traceback (most recent call last): > ... > NotImplementedError > >>> Colors.blue > Colors.green > Traceback (most recent call last): > ... > NotImplementedError > >>> Colors.blue >= Colors.green > Traceback (most recent call last): > ... > NotImplementedError I like much of this PEP, but the exception type for this case seems odd to me. Wouldn't a TypeError be more appropriate here? Somewhat like this: >>> 'a' - 'b' Traceback (most recent call last): File "", line 1, in TypeError: unsupported operand type(s) for -: 'str' and 'str' 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] libffi inclusion in python
On Thu, Apr 18, 2013 at 11:17 PM, Ronald Oussoren wrote: > Stripping libffi from python's source tree would be fine by me, but would > require testing with upstream libffi. AFAIK system libffi on osx wouldn't be > goog enough, it doesn't work properly with clang. If you mean http://bugs.python.org/issue17136, I think that has been fixed in libffi upstream? 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] Issue 11406: adding os.scandir(), a directory iterator returning stat-like info
On Tue, May 14, 2013 at 12:14 PM, Ben Hoyt wrote: > I don't think that's a big issue, however. If it's 3-8x faster in the > majority of cases (local disk on all systems, Windows networking), and > no slower in a minority (sshfs), I'm not too sad about that. Might be interesting to test something status calls with a hacked Mercurial. 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] Bilingual scripts
On Fri, May 24, 2013 at 10:23 PM, R. David Murray wrote:
> Gentoo has a (fairly complex) driver script that is symlinked to all
> of these bin scripts. The system then has the concept of the
> "current python", which can be set to python2 or python3. The default
> bin then calls the current default interpreter. There are also
> xxx2 and xxx3 versions of each bin script, which call the 'current'
> version of python2 or python3, respectively.
I'm one of the Gentoo devs, on the python team. I haven't actually
written any code for this, but I can show a little of what's going on.
I think most of the code is actually in
https://bitbucket.org/mgorny/python-exec. We then install three
scripts:
lrwxrwxrwx 1 root root 11 May 20 14:06 /usr/bin/sphinx-build -> python-exec
-rwxr-xr-x 1 root root 311 May 20 14:06 /usr/bin/sphinx-build-python2.7
-rwxr-xr-x 1 root root 311 May 20 14:06 /usr/bin/sphinx-build-python3.2
sphinx-build-python2.7 looks like this:
#!/usr/bin/python2.7
# EASY-INSTALL-ENTRY-SCRIPT: 'Sphinx==1.1.3','console_scripts','sphinx-build'
__requires__ = 'Sphinx==1.1.3'
import sys
from pkg_resources import load_entry_point
if __name__ == '__main__':
sys.exit(
load_entry_point('Sphinx==1.1.3', 'console_scripts', 'sphinx-build')()
)
We now use a python2.7 suffix rather than just a 2.7 suffix because we
will install separate wrappers for e.g. pypy1.9 (and we are also
prepared to support jython or other implementations at some point).
If you have any more questions, I'll try to answer them; or, join
#gentoo-python on Freenode, there are generally people hanging out
there who know much more about our setup than I do.
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] Python 3 as a Default in Linux Distros
On Wed, Jul 24, 2013 at 11:12 AM, Bohuslav Kabrda wrote:
> - What should user get after using "yum install python"?
> There are basically few ways of coping with this:
> 1) Just keep doing what we do, eventually far in the future drop "python"
> package and never provide it again (= go on only with python3/python4/...
> while having "yum install python" do nothing).
> 2) Do what is in 1), but when "python" is dropped, use virtual provide (*)
> "python" for python3 package, so that "yum install python" installs python3.
> 3), 4) Rename python to python2 and {don't add, add} virtual provide "python"
> in the same way that is in 1), 2)
> 5) Rename python to python2 and python3 to python at one point. This makes
> sense to me from the traditional "one version in distro + possibly compat
> package shipping the old" approach in Linux, but some say that Python 2 and
> Python 3 are just different languages [3] and this should never be done.
> All of the approaches have their pros and cons, but generally it is all about
> what user should get when he tries to install python - either nothing or
> python2 for now and python3 in future - and how we as a distro cope with that
> on the technical side (and when we should actually do the switch).
> Just as a sidenote, IMO the package that gets installed as "python" (if any)
> should point to /usr/bin/python, which makes consider these two points very
> closely coupled.
On Gentoo we get python2 and python3 executables and have user-level
tools to change what the 'python' symlink points to. I think we
default to only having Python 3 installed (and Python 3 is even made
the default Python), though it's currently always the case that Python
2 gets pulled in by some core dependencies.
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] Official github mirror for CPython?
On Fri, Jul 26, 2013 at 9:50 AM, Antoine Pitrou wrote: >> (For those that haven't seen it, RhodeCode seems broadly comparable to >> BitBucket feature wise, but because of the way it is licensed, the >> source code is freely available to all, and running your own instance >> is free-as-in-beer for non-profits and open source projects). > > By "freely available", do you mean actual open source / free software? It seems to be licensed under the GPLv3. https://secure.rhodecode.org/rhodecode/files/433d6385b216da52f68fa871ed1ff99f8d618613/COPYING https://rhodecode.com/blog/25/new-rhodecode-licensing 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] Offtopic: OpenID Providers
On Thu, Sep 5, 2013 at 10:30 PM, Tres Seaver wrote: > +1 for supporting Persona as an alternative to OpenID on all *.python.org > servers. BTW, I'd be happy to assist with any Persona RP implementations for python.org services. The MDN docs are pretty good, I got my first RP going in just a few hours of looking at code (and you can probably do better if you're more into frontend webdev stuff). There's also ongoing work that will replace ReadTheDocs accounts with Persona support. Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, Sep 5, 2013 at 10:33 PM, Glenn Linderman wrote: > Is there a Python implementation of Persona I can install on my web server? If you mean to use your web server as an Identity Provider, try this: https://bitbucket.org/djc/persona-totp It currently only implements TOTP-based authentication (i.e. no passwords), but it should be easy to add a password or 2FA-mode if you'd prefer that. Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Offtopic: OpenID Providers
On Thu, Sep 5, 2013 at 10:57 PM, Donald Stufft wrote: > Not that it changes this statement at all but you wouldn't expect to see a > Persona login > for gmail as persona solves the problem that people don't think of urls as > personal > identifiers by replacing it with emails. So Gmail would be the Persona IdP And actually you can already trivially login with your GMail account on any Persona-based Relying Party (that is, a site that uses Persona to authenticate you). This is because one of the nice parts of the current implementation of Persona is that Mozilla has implemented bridges that allow GMail and Yahoo addresses to be authenticated via their respective OAuth implementations, such that you don't need to setup an account at Mozilla's fallback IdP (which acts as an Identity Provider for email addresses that don't currently have an IdP available to them). Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a "transformdict" to collections
On Tue, Sep 10, 2013 at 11:28 AM, Antoine Pitrou wrote: > On the tracker issue, it seems everyone agreed on the principle. There > is some bikeshedding left to do, though. So here are the reasonable > naming proposals so far: > > - transformkeydict > - coercekeydict > - transformdict > - coercedict > > I have a sweet spot for "transformdict" myself. Given OrderedDict, it seems like this should definitely be TransformDict rather than transformdict. Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP-431 non-status
On Wed, Oct 2, 2013 at 2:17 PM, Lennart Regebro wrote: > If you wonder about the lack of progress reports on pep-431, this is > because of a lack of progress. I simply haven't had any time to work > on this. I considered make a kickstarter so I could take time off from > working, but to be honest, even with that, I still have no time to > realistically get this in before beta 1. Is there a list of stuff that needs to be done? I might be able to help out. Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python startup time
On Thu, Oct 10, 2013 at 2:25 PM, Christian Heimes wrote: > Benchmark of 1000 times "python -c ''" > > Python 3.4dev with all my experimental patches: > > Avg: 0.705161 -> 0.443613: 1.59x faster > > 2.7 -> 3.4dev: > > Avg: 0.316177 -> 0.669330: 2.12x slower > > 2.7 -> 3.4dev with all my patches: > > Avg: 0.314879 -> 0.449556: 1.43x slower > > http://pastebin.com/NFrpa7Jh > > Ain't bad! The benchmarks were conducted on a fast 8 core machine with SSD. This seems promising. What OS are you using? On an older Linux server with old-style HD's, the difference between 2.7 and 3.2 is much larger for me: Avg: 0.0312 -> 0.1422: 4.56x slower (In this case, I think it might be more useful to report as 0.11s faster, though.) Cheers, Dirkjan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2 very interesting projects - Python / Finance
On 17/02/2009 17:55, Steve Holden wrote: is "for work on developing Python". Hence your posting (and your protestations of innocence) is unsolicited commercial email, AKA spam. Python users who are looking for jobs know about the jobs board, where you have already submitted vacancy notices (now jeopardized by this anti-social act). Please stop now - if you must reply, feel free to do so by private email. I'd like to mention that python-nl got this, too, so he probably spammed a bunch of lists. 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] PEP 372 -- Adding an ordered directory to collections ready for pronouncement
On 02/03/2009 22:28, Georg Brandl wrote: We're already quite inconsistent with type name casing in the collections module, so it wouldn't matter so much. (Though I'd find symmetry with defaultdict pleasing as well.) Since the odict naming is already so prevalent in the wild, it seems to me like that would be the best candidate. (Plus, it's shorter!) /bikeshedding 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?
On 04/04/2009 17:40, Aahz wrote: With Brett's (hopefully temporary!) absence, who is spearheading the Mercurial conversion? Whoever it is should probably take over PEP 374 and start updating it with the conversion plan, particularly WRT expectations for dates relative to 3.1 final and 2.7 final. I'd like to take that on. I know hardly anyone here knows me, but I'm one of the Mercurial developers. I've been in contact with Brett, saying that I'd gladly as much help as I could, and I figured I'd put a lot of time in providing the best possible migration path. While I haven't posted here much, I've been lurking for about two years now, so I know a little about what's going on. Maybe I could pair up with someone here who wants to work on it, if that makes people more confident? Anyway, I'm also on the tracker-discuss list, since Brett told me that's where infra stuff mostly takes place. 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?
On 05/04/2009 07:55, Alexandre Vassalotti wrote: - Verify that the repository at http://code.python.org/hg/ is properly converted. I'm pretty sure that we'll need to reconvert; I don't think the current conversion is particularly good. We'll also have to decide on named branches vs. clones, for example, and if we could try to reorder revlogs to make the repo smaller after conversion. I've svnsynced the SVN repo so that we can work on it efficiently, and I've already talked with Augie Fackler, the hgsubversion maintainer, about what the best way forward is. For example, we may want to leave some of the very old history behind, or prune some old branches. - Convert the current svn commit hooks to Mercurial. Some new hooks should also be discussed. For example, Mozilla uses a single-head hook, to prevent people from pushing multiple heads. They also have a pushlog extension that keeps a SQLite database of what people pushed. This is particularly useful for linearizing history, which is required for integration with buildbot infrastructure. - Add Mercurial support to the issue tracker. I don't think there's much to do there, but a regex to link up some commonly-used revision references would be good. If we use cloned branches, we'll have to come up with some syntax to make that work. - Update the developer FAQ. - Setup temporary svn mirrors for the main Mercurial repositories. How do you plan to do that? I don't think there are any tools that support that, yet. I've actually started on my own, but I haven't gotten very far with it, yet. - Augment code.python.org infrastructure to support the creation of developer accounts. Developers already have accounts, don't they? In any case, some web interface to facilitate setting up new clones (branches) is also something that's probably desirable. I think Mozilla has some tooling for that which we might be able to start off of. 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?
On 05/04/2009 02:44, "Martin v. Löwis" wrote: > I'm personally happy letting you do that (although I do wonder who would > then be in charge of the Mercurial installation in the long run, the way > I have been in charge of the subversion installation). I'd be happy to commit to that for the foreseeable future. > To proceed, I think the next step should be to discuss in the PEP the > details of the migration procedure (see PEP 347 for what level of detail > I produced for the svn migration), and to set up a demo installation > that is considered ready-to-run, except that it might get torn down > again, if the actual conversion requires that (it did for the CVS->svn > case), or if problems are found with the demo installation. Sounds sane. Would I be able to get access to PSF infrastructure to get started on that, or do you want me to get started on my own box? I'll probably do the conversion on my own box, but for authn/authz it might be useful to be able to use PSF infra. > I would personally remove all non-mercurial stuff out of PEP 374, > and retitle it, but that would be your choice. Moving the current content to a wiki page like you suggest later in this thread sounds like a good idea. 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?
On 05/04/2009 11:06, "Martin v. Löwis" wrote: In particular, the Stackless people have requested that they move along with what core Python does, so their code should also be converted. I'd be interested to hear if they want all of their stuff converted, or just the mainline/trunk of what is currently in trunk/branches/tags. - integrate with the buildbot I've setup the buildbot infra for Mercurial (though not many people are interesting in it, so it's kind of languished). Using buildbot's hg support is easy. 0.7.10 is the first version which works with hg 1.1+, though, so we probably don't want to go with anything earlier. - come up with a strategy for /external (also relevant for the buildbot slaves) I'm not sure exactly what the purpose or mechanism for /external is. Sure, it's like a snapshot dir, probably used for to pull some stuff into other process? Seems to me like it might be interesting to, for example, convert to a simple config file + script that lets you specify a package (repository) + tag, which can then be easily pulled in. But it'd be nice to know where and how exactly this is used. - decide what to do with the bzr mirrors I'm assuming the bzr people have ways of importing hg repos. It's probably more effective for them to deal with this problem. If helpful, there are some scripts that do fast-exporting from hg repos. 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?
On 05/04/2009 12:27, Antoine Pitrou wrote: There's also the issue of how we adapt the current workflow of "svnmerging" between branches when we want to back- or forward-port stuff. In particular, tracking of already done or blocked backports. Right. The canonical way to do that with Mercurial is to commit patches against the "oldest" branch where they should be applied, so that every stable branch is a strict subset of every less stable branch. From what I've understood, this doesn't fit the way the Python-dev community/process works very well. In that case, there are a number of alternatives. For example, hg's export/import commands can be used to explicitly deal with diffs that contain hg metadata, the transplant extension can be used to automate that, or in some cases, the rebase extension might be more appropriate. We can put extended examples from the PEP in the wiki to help people discovering the best workflow. 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?
On 05/04/2009 13:00, Antoine Pitrou wrote: Transplant or export/import have the right semantics IMO, but we lose the tracking that's built in svnmerge. Perhaps a new hg extension? ;) (the missing functionality is to store the list of transplanted or blocked changesets in a .hgXXX file (storing the original hashes, not the ones after transplant), and parse that file in order to compare it with the incoming changesets from an other repo) Transplant can already keep the source revision hash on the new revision (in hg's equivalent of generic revprops, the extra dict). I think that blocked revisions will not be an issue due to the nature of the DAG, but I have too little experience with svnmerge to say for sure. 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?
(going back on-list) On 05/04/2009 15:42, Alexandre Vassalotti wrote: I'm pretty sure that we'll need to reconvert; I don't think the current conversion is particularly good. What is bad about it? For one thing, it has the [svn] prefixes, which I found to be quite ugly. hgsubversion in many cases will preserve the rev order from svn so that the local revision numbers that hg shows will be the same as in SVN anyway. On top of that, good conversion tools save the svn revision in the revision metadata in hg, so that you can see it with log --debug. For another, I'd like to use an author map to bring the revision authors more in line with what Mercurial repositories usually display; this helps with tool support and is also just a nicer solution IMO. I have a stab at an author map at http://dirkjan.ochtman.nl/author-map. Could use some review, but it seems like a good start. I largely prefer clone to named branches. From personal experience, I found named branches difficult to use properly. And, I think even Mercurial developers don't use them. No, the Mercurial project currently doesn't use them. Mozilla does use them at the moment, because they found they did have some advantages (especially lower disk usage because no separate clones were needed). I think named branches are fine for long-lived branches. At the very least we should have a proper discussion over this. How do you reorder the revlog of a repository? There are scripts for this which can be investigated. I am in favor of pruning the old branches, but not of leaving the old history behind. The current Mercurial mirror of py3k is 92M on my disk which is totally reasonable. So, I don't see what would be the advantage there. The current Mercurial mirror for py3k also doesn't include any history from before it was branched, which is bad, IMO. In order to get the most of the DVCS structure, it would be helpful if py3k shared history with the normal (trunk) branches. I was thinking of something very basic—e.g., something like a commit hook that would asynchronously commit the latest revision to svn. We wouldn't to keep convert much meta-data just the committer's name and the changelog would be fine. What's the use case, who do you want to support with this? hgweb trivially provides tarballs for download on every revision, so people who don't want to use hg can easily download a snapshot. Not really. Currently, core developers can only push stuff using the Bazaar setup. Personally, I think SSH access would be a lot nicer, but this will depend how confident python.org's admins are with this idea. We could still enable pushing through http(s) for hgweb(dir). 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?
On 05/04/2009 15:11, Alexandre Vassalotti wrote: I am not sure if it would be useful to convert the old branches to Mercurial. The simplest thing to do would be to keep the current svn repository as a read-only archive. And if people needs to commit to these branches, they could request the branch to be imported into a Mercurial branch (or a simple to use script could be provided and developer could run it directly on the server to create a user branch). We should probably not include any branches that haven't been touched in the last 18 months. Then we also leave out branches that have been pruned. BTW, tags are also missing from the current conversions. We probably want to keep all release tags, but not the partial tags (e.g. the Distutils tags). Are there any other particularly useful tags we should keep? An auto-close would be a nice feature, but, as you said, not necessary for the migration. The main stumbling block to implement an auto-close feature is to define when an issue should be closed. Maybe we could add our own meta-data to the commit message. For example: Fix some nasty bug. Close-Issue: 4532 When a such commit would arrive in one of the main branches, a commit hook would close the issue if all the affected releases have been fixed. It makes more sense to me to use the syntax already used by Trac et al., e.g. "(fix|close)s? (issue|#)\d+" for closing and possibly "ref(erence)?s? (issue|#)\d+" for creating a link on the issue. BTW, this would also be a good time to split out the stdlib if that's still desirable (which I seem to have gleaned from the PyCon videos). 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?
On 05/04/2009 16:39, Antoine Pitrou wrote: The other nice thing with having "[svn rXXX]" in the patch subject line is that it makes the info easily viewable and searchable in the Web front-end. We can still make it accessible/searchable on the web if we don't put it in the commit message. I think at least 3.x and 2.x should live in separate repos. It is pointless for a clone of py3k to end up pulling all 4+ changesets from the trunk. It would add 100MB+ to every py3k clone (that is, quadrupling the size of the repository). I don't agree. It's quite annoying for things like annotate/blame, for example, where you may have to switch to another branch while chasing down a defective change. I also think 100MB+ is a cheap price to pay, given you only pay it in disk space (cheap) and initial clone time (not very often, and usually still quite fast). Also, at some point you presumably want to deprecate the whole 2.x line, right? So at that point, it'd be nice to have a full 3.x line with all the history in it, so that you can just throw away the 2.x stuff and still have full history. I do agree that 2.x and 3.x should probably be in separate clones. Is any SVN-to-hg conversion tool able to parse the commits produced by svnmerge? And, even then, turn that information into useful hg information (say, transplant metadata of which changes were ported)? I think things are these are planned for hgsubversion, yes. I'd probably want to look at implementing some support for it myself if that makes the conversion of the Python repositories better. I'm not sure what the problem is. Developer SVN access already goes through ssh. Okay, sounds like that will be easy. Would be good to enable compression on the SSH, though, if that's not already done. 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?
On 05/04/2009 17:18, Antoine Pitrou wrote: It is a cheap price to pay if there is a significant return for it. In my experience using the hg mirror of the py3k branch, I don't remember having had to run "annotate" on the trunk to hunt for a change that I'd witnessed in py3k. Other developers may have different experiences, though. As for the clone time, one of our proeminent developers is, IIRC, on a 40 kb/s line. Perhaps he wants to step in and say whether cloning the trunk is a painful experience for him, or not. Sure it's painful, but he only has to go through that once, maybe twice. The consensus seems to be that it will not happen before a couple of years. See, I think the point here is that, even though you want the branches to be clones, you also want them to all be part of the same directed acyclic graph (that DAG thing I keep nattering on about). That way, you can later merge every branch back in to some other branch (even if it's trivial merge that doesn't keep anything from one of the branches). Even if that's not for a couple of years, it's nice when you'll be able to do it in a couple of years without changing all the hashes (meaning everybody has to re-clone). For any dial-up providers, we could for example provide a repository that just has the changesets up to the split between trunk and py3k. He can clone that once, clone it locally, then pull the rest of the respective history in those local clones. If you don't have common history, a few of the niceties of having a DAG-based DVCS in the first place go away; that seems like a pity. Does the hg protocol compress that good? I would have thought there is already a lot of compression in the layout (given that it seems much more efficient than some of its competitors). When used over HTTP, hg uses bundles (which can also be used as separate file to exchange changesets informally). Bundles contain gzip- or bzip2-compressed csets. When communicating over SSH, on the other hand, hg defaults to uncompressed streams, because the assumption is that connections can use SSH's compression, which is more efficient. All of this functions on top of the already quite efficient revlogs that make up the basic storage model for hg. 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?
On 05/04/2009 19:50, "Martin v. Löwis" wrote: Ok, that's a problem. We currently run 0.7.5 on the master, and have made custom changes that need to be forward-ported. IIUC, this will also mean that the waterfall default page is gone, which might surprise people. I suppose all slaves also need to upgrade. Why is the waterfall default page gone? I had that in my 0.7.9 setup, at least. Provided the 0.7.5 slaves work with 0.7.10, then no, it's not necessary to upgrade the slaves. The problem in buildbot was strictly with the change detection in hg repos (combined with the Mercurial API, which hasn't entirely become stable -- so it changed a bit in 1.1). Take a look at the batch files in Tools/buildbot - they are the primary consumers. PCbuild/readme.txt also refers to it. Will do. 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?
On 05/04/2009 19:37, "Martin v. Löwis" wrote: Any decision to have or not have such a feature should be stated in the PEP. I personally don't use IDEs, so I don't care (although I do notice that the apparent absence of IDE support for Mercurial indicates maturity of the technology) Well, there should be good support for Eclipse (through MercurialEclipse), NetBeans (they use hg themselves, after all), and the IDE-version of Komodo 5.0+ also includes hg support. I suppose other, more Python-specific IDEs might be following suit as Python switches. Ok, I take that back. I assumed that Mercurial could work *exactly* as Subversion. Apparently, that's not the case (although I have no idea what a server-side clone is). So I wait for the PEP to explain how authentication and access control is to be implemented. Creating individual Unix accounts for committers should be avoided. Yeah, that won't be necessary. The canonical solution is to have just one Unix account called hg, to which we can add public keys. 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?
On 05/04/2009 20:18, "Martin v. Löwis" wrote: But then, I have not tried installing it, so I don't know what it actually looks like. Ah, right. In my setup, there was an index page with three lines of text, one of which had a link to the waterfall. So I think that should still be simple enough for most of the interested parties. ;) 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?
On 05/04/2009 20:29, "Martin v. Löwis" wrote: FYI: this is the list of hooks currently employed: - pre: check whitespace - post: mail python-checkins inform regular buildbot inform community buildbot trigger website rebuild if a PEP was modified (but then, whether or not the PEPs will be maintained in hg also needs to be decided) All this is easy to do with Mercurial's hook system. One caveat is that stuff (like whitespace) only gets checked at push time, not at commit time (running commit hooks would have to be done on the client, but since we don't sandbox hooks, they would be a liability to distribute by default). People could still set them up locally for pre-commit if they want, of course, but otherwise they may need some trickery to modify the changesets they want to push. For the email messages, we'll probably want to use the notify extension that comes with hg. How to authenticate in that interface? We don't have passwords per committer. Okay, so we'll use ssh. 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?
On 05/04/2009 20:36, "Martin v. Löwis" wrote: We do require full real names (i.e. no nicknames). Can Mercurial guarantee such a thing? We could pre-record the list of allowed names in a hook, then have the hook check that usernames include one of those names and an email address (so people can still start using another email address). In the long run, the current trunk may cease to exist, and the py3k branch may take over its role. Not sure whether this needs to be considered. I considered that in some other subthread. :) 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?
On Mon, Apr 6, 2009 at 00:48, Mark Hammond wrote: > Just to be clear, what input would you like on that map? Review of email addresses, pointers to names/email addresses for the usernames I don't have anything for yet. Also, there's a few commented question marks, it would be useful if someone checked those. > I'm listed twice: > > mark.hammond = Mark Hammond > mhammond = Mark Hammond > > but that email address isn't the address normally associated with any > checkins I make, nor the address in the comments of the ssh keys I use > (which is mhamm...@skippinet.com.au) Your being listed twice is normal; both mark.hammond and mhammond have been used in the commit history, and I just assumed they're both you. I'll probably change your email address to be the one associated with the checkins/public key, though. Is there a list of such email addresses? I just parsed python-dev archives to get to my list. 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?
On Mon, Apr 6, 2009 at 04:27, wrote: > Maybe once for each currently active Subversion branch (2.6, 2.7, 3.0, 3.1)? Sure, if we're doing cloned branches. But then someone will also need to clone 2.5, and maybe 2.4. The point is, as long as it's a constant factor and not an order of magnitude more, it's still quite easy to cope with. This would also be one of the arguments *for* named branches, I suppose. 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?
On Mon, Apr 6, 2009 at 06:20, Alexandre Vassalotti wrote: > But that won't work if people who are not core developers submit us > patch bundle to import. And maintaining a such white-list sounds to me > more burdensome than necessary. Well, if you need contributors to sign a contributor's agreement anyway, there's already some list out there that we can leverage. The other option is to play the consenting adults card and ask all people with push access to ascertain the correct names of committer names on patches they push. 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?
Alexandre Vassalotti peadrop.com> writes: > If I recall correctly, only ssh clients can request compression to the > server—in other words, the server cannot forces the clients to use > compression, but merely allow them use it. > > See the man page for sshd_config and ssh_config for the specific details. So we'll explain how to configure that in the .hgrc/Mercurial.ini file that people will have to create anyway. Alternatively, we do it the way Mozilla has done and let everyone clone/pull over http and push over ssh. Then everyone always gets compression for the big clones/pulls, pushes are a little slower (but they aren't usually that large), and people who don't have push access already have the right setup. 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?
Martin v. Löwis v.loewis.de> writes: > Is it possible to branch from a subdirectory? For the "different VMs" > stuff, it's rather desirable to have a branch of the test suite, and > the perhaps the standard library, than extracting it from the source. You can only branch the whole repository. Of course you could drop the other stuff right after branching it, but that would kind of defy the point of branching (since you won't really be able to merge later on). This is why it might be interesting to just split out the stdlib entirely. Though maybe we should wait for Mercurial's subrepos support to arrive before we go there (so we can a CPython repo that has the stdlib repo included automatically). Something like that is already provided by the forest extension, but it's not being maintained. Subrepo support is slated for the 1.3 release, which is planned for early July. 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?
Alexandre Vassalotti peadrop.com> writes: > With Mercurial, we will need to add support for server-side clone > ourselves. There's few ways to provide this feature. We give Unix user > accounts to all core developers and let developers manages their > private branches directly on the server. You made clear that this is > not wanted. So an alternative approach is to add a interface > accessible via SSH. As I previously mentioned, this is the approach > used by Mozilla. The easier solution here is to just allow normal local-to-remote clones. hg supports commands like hg clone . ssh://h...@hg.python.org/my-branch without the need for any extra scripts or setup. I think that would be a good start. > This makes me remember that we will have to decide how we will > reorganize our workflow. For this, we can either be conservative and > keep the current CVS-style development workflow—i.e., a few main > repositories where all developers can commit to. Or we could drink the > kool-aid and go with a kernel-style development workflow—i.e., each > developer maintains his own branch and pull changes from each others. The differences between these workflows aren't all that big, i.e. it's not like there's a big schisma between them. But I suspect that, in a setup where buildbots are important, a very much multi-repo setup probably isn't a good idea (this is also why Mozilla doesn't use that many repos; their continuous integration infra is /very/ important to them). 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?
On Mon, Apr 6, 2009 at 10:21, Philippe Fremy wrote: > One question: if somebody pushes a changeset with 3 commits, will the > pre and post hooks be applied on all of the commits, or only on the > final commit ? > > If this is applied on every commit, then you have no way to fix a > whitespace problem without rewriting your history ? Correct, so if the latter is something we want, we could run the whitespace hook just on every changegroup (group of changesets pushed). 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?
On Mon, Apr 6, 2009 at 11:14, Philippe Fremy wrote: > This is a problem I have with my daily usage of mercurial. It's supposed > to be great to work offline and to commit your intermediate versions > before it's fully working but if you do that, all those intermediate non > working versions find their way into the main repository. Well, it can also be nice to have smaller commits. They're easier to review, and will provide easier history to browse/read later on. BTW, having smaller commits doesn't necessarily equate having non-working changesets. I.e. in my work on Mercurial, I'll often push small changesets (we all do), but we try to keep the test suite passing in every single one of them. > This means that something like "all test pass 100% or close on every > version of the repository" is not really feasible unless every committer > agrees not to have any version in his local repository that does not > break any tests. Which defeats part of the purpose of being able to have > a local repository, no ? This is why you'd want something like a pushlog, to provide a way to see what revisions were actually tested by buildbots. Another thing that I discussed with Georg last night would be a setup where changesets get pushed to a gateway repo that runs the tests and only pushes to an "official" repo if everything's still green. That should probably be a topic discussed separately, though. 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?
On Mon, Apr 6, 2009 at 13:55, Michael Foord wrote: > Gated checkins can work fine but can also have many problems. For example if > we have a spuriously failing test then if you are working on an unrelated > issue it will be entirely up to chance as to whether you can checkin... Sure, it's a problem, but it does get you a tree that's always green. They're all trade-offs. But let's keep this discussion for some time *after* migration to hg is completed. 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?
On Tue, Apr 7, 2009 at 00:05, "Martin v. Löwis" wrote: > I think the identification in the SSH keys is useless. It contains > strings like "loe...@mira" or "ncogh...@uberwald", or even multiple > of them (ba...@wooz, ba...@resist, ...). Right, so we'll put up the author map somewhere with the email addresses I gathered and ask for a more thorough review at some point. > It seems that the PEP needs to spell out a policy as to what committer > information needs to look like; then we need to verify that the proposed > name mapping matches that policy. Right. It's basically "Name Lastname " -- we can verify that in a hook. > Correct. The objective was to not allow nick names, but have real names > as committer names. It appears that this policy does not directly > translate into Mercurial. One of the nicer features of Mercurial/DVCSs, in my experience, is that non-committers get to keep the credit on their patches. That means that it's impossible to enforce a policy more extensive than some basic checks (such as the format above). Unless we keep a list of people who have signed an agreement, which will mean people will have to re-do the username on commits that don't constitute a non-trivial contribution. 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?
On Tue, Apr 7, 2009 at 04:25, Steve Holden wrote: > I would remind you all that it's *very* necessary to make sure that > whatever finds its way into released code is indeed covered by > contributor agreements. The PSF (as the guardian of the IP) has to > ensure this, and so we have to find a way of ensuring that all > contributions to source are correctly logged against authors in a > traceable way. I think having full name *and* email addresses make it easier to trace code, I guess, since previously code not written by committers would be harder to trace. The fact that some stuff isn't covered just becomes more explicit, which is a good thing IMO. 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?
On Tue, Apr 7, 2009 at 08:25, Ben Finney wrote: > Remembering, of course, that full names don't follow any template > (especially not first-name last-name). The person's full name must be > treated as free-form text, since there's no format common to all. Of course, unless we lock it down through a list of people who have contributor's agreements. 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?
On Tue, Apr 7, 2009 at 13:42, Steven D'Aprano wrote: > Perhaps you should ask Aahz what he thinks about being forced to provide > two names before being allowed to contribute. Huh? The contributor's agreement list would presumably include real names only (so Aahz is out of luck), but the names wouldn't need to be limited to just one "word". I don't think I was implying otherwise; maybe my example much earlier in the thread was simplistic and I should have put it in EBNF (with Unicode character classes just to be very sure). Oh, yes, I am excluding people whose names include non-Unicode characters. Tough luck. 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?
On Tue, Apr 7, 2009 at 16:29, Aahz wrote: > What you apparently are unaware of is that "Aahz" is in fact my full > legal name. (Which was clearly the point of Steven's post since he knows > that Teller also has only one legal name -- it's not common, but we do > exist.) Ah, sorry about that. But I hope you also concluded from my email that that wouldn't be a problem. 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?
On Tue, Apr 7, 2009 at 20:25, Daniel (ajax) Diniz wrote: > BTW, keep in mind some people will prefer to submit diff-generated, > non-hg patches. IMO, this use case should be supported before the > rich-patch one. Sure, that will be in the PEP as well (and it's quite simple). 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] Dropping bytes "support" in json
On Thu, Apr 9, 2009 at 07:15, Antoine Pitrou wrote:
> The RFC also specifies a discrimination algorithm for non-supersets of ASCII
> (“Since the first two characters of a JSON text will always be ASCII
> characters [RFC0020], it is possible to determine whether an octet
> stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking
> at the pattern of nulls in the first four octets.”), but it is not
> implemented in the json module:
Well, your example is bad in the context of the RFC. The RFC states
that JSON-text = object / array, meaning "loads" for '"hi"' isn't
strictly valid. The discrimination algorithm obviously only works in
the context of that grammar, where the first character of a document
must be { or [ and the next character can only be {, [, f, n, t, ", -,
a number, or insignificant whitespace (space, \t, \r, \n).
json.loads('"hi"')
> 'hi'
json.loads(u'"hi"'.encode('utf16'))
> Traceback (most recent call last):
> File "", line 1, in
> File "/home/antoine/cpython/__svn__/Lib/json/__init__.py", line 310, in loads
> return _default_decoder.decode(s)
> File "/home/antoine/cpython/__svn__/Lib/json/decoder.py", line 344, in decode
> obj, end = self.raw_decode(s, idx=_w(s, 0).end())
> File "/home/antoine/cpython/__svn__/Lib/json/decoder.py", line 362, in
> raw_decode
> raise ValueError("No JSON object could be decoded")
> ValueError: No JSON object could be decoded
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] Dropping bytes "support" in json
On Thu, Apr 9, 2009 at 13:10, Antoine Pitrou wrote:
> Sure, but then:
>
json.loads('[]')
> []
json.loads(u'[]'.encode('utf16'))
> Traceback (most recent call last):
> File "", line 1, in
> File "/home/antoine/cpython/__svn__/Lib/json/__init__.py", line 310, in loads
> return _default_decoder.decode(s)
> File "/home/antoine/cpython/__svn__/Lib/json/decoder.py", line 344, in decode
> obj, end = self.raw_decode(s, idx=_w(s, 0).end())
> File "/home/antoine/cpython/__svn__/Lib/json/decoder.py", line 362, in
> raw_decode
> raise ValueError("No JSON object could be decoded")
> ValueError: No JSON object could be decoded
Right. :) Just wanted to point your test might not be testing what you
want to test.
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] Rethinking intern() and its data structure
On Thu, Apr 9, 2009 at 17:31, Aahz wrote: > Please do subscribe to python-dev ASAP; I also suggest that you subscribe > to python-ideas, because I suspect that this is sufficiently blue-sky to > start there. It might also be interesting to the unladen-swallow guys. 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] Issue5434: datetime.monthdelta
On Thu, Apr 16, 2009 at 11:54, Amaury Forgeot d'Arc wrote: > In my opinion: > arithmetic with months is a mess. There is no such "month interval" or > "year interval" with a precise definition. > If we adopt some kind of month manipulation, it should be a function > or a method, like you would do for features like last_day_of_month(d), > or following_weekday(d, 'monday'). > > date(2008, 1, 30).add_months(1) == date(2008, 2, 29) I concur. Trying to shoehorn month arithmetic into timedelta is a PITA, precisely because it's somewhat inexact. It's better to have some separate behavior that has well-defined behavior in edge cases. 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] PEP 383: Non-decodable Bytes in System Character Interfaces
On 22/04/2009 14:20, gl...@divmod.com wrote: -1. On UNIX, character data is not sufficient to represent paths. We must, must, must continue to have a simple bytes interface to these APIs. Covering it up in layers of obscure encoding hacks will not make the problem go away, it will just make it harder to understand. As a hg developer, I have to concur. Keeping bytes-based APIs intact would make porting hg to py3k much, much easier. You may be able to imagine that dealing with paths correctly cross-platform on a VCS is a major PITA, and py3k is currently not helping the situation. 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] Shorter release schedule?
On Wed, May 13, 2009 at 12:29 AM, Barry Warsaw wrote: > I've been in favor of that for a while now. With the move to a DVCS (how's > that coming along?) I've been rewriting PEP 374 about the Mercurial migration. Will post here once it's ready for review. 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] PEP 376 : Changing the .egg-info structure
On Fri, May 15, 2009 at 8:32 AM, Jeroen Ruigrok van der Werven wrote: > Agreed. Within FreeBSD's ports the installed package registration gets a MD5 > hash per file recorded. Size is less interesting though, since essentially > this information is encapsulated within the hash. Remove one byte from the > file and your hash is already different. And the case of a collision for > this kind of registration is sufficiently small to need the size > information. Size is nice because it's much cheaper to check. I don't know if mass uninstalls will be so common that this is actually something we have to worry about, though. 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] PEP 384: Defining a Stable ABI
On Sun, May 17, 2009 at 10:54 PM, "Martin v. Löwis" wrote: > Excluded Functions > -- > > Functions declared in the following header files are not part > of the ABI: > - cellobject.h > - classobject.h > - code.h > - frameobject.h > - funcobject.h > - genobject.h > - pyarena.h > - pydebug.h > - symtable.h > - token.h > - traceback.h What kind of effect does this have on optimization efforts, for example all the stuff done by Antoine Pitrou over the last few months, and the first few results from unladen? Will it mean we won't get to the good optimizations until 4.0? Or does it just mean unladen swallow takes longer to come back to trunk (until 4.0) and every extension author who wants to be compatible with it will basically have the same burden as now? 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] PEP 384: Defining a Stable ABI
On Mon, May 18, 2009 at 12:07 AM, "Martin v. Löwis" wrote: > I fail to see the relationship, so: no effect that I can see. > > Why do you think that optimization efforts could be related to > the PEP 384 proposal? It would seem to me that optimizations are likely to require data structure changes, for exactly the kind of core data structures that you're talking about locking down. But that's just a high-level view, I might be wrong. 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] PEP 384: Defining a Stable ABI
On Mon, May 18, 2009 at 12:43 AM, Antoine Pitrou wrote: > Unless I'm misunderstanding something, Martin doesn't advocate locking data > structures down (except a couple of outliers such as Py_buffer). An > ABI-compliant application mustn't tinker directly with Python's data > structures, > but use the ABI functions. Right. Sorry about the noise, then. 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, linefeeds, and Visual Studio
On Thu, Jun 4, 2009 at 3:02 PM, Jason R. Coombs wrote: > I wanted to share this with the community in case anyone else runs into this > issue. Also, if there's a recommended procedure for addressing this issue > (and others that might arise due to non-native line endings), I'd be > interested to hear it. Mercurial comes with a win32text extension that helps resolve issues like these. It allows you to specify in the .hg/hgrc that .sln files should always be expanded to CRLF. 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 and linefeeds
On Thu, Jun 4, 2009 at 3:49 PM, R. David Murray wrote: > The above statement seems like a really odd design choice, with the > potential for causing considerable developer coordination headaches. > > Any Mercurial boffins want to talk about how this works in practice? I'm guessing that's just because it uses Mercurial's built-in configuration file chain (.hg/hgrc, ~/.hgrc and /etc/mercurial/hgrc). Those aren't transmitted with repositories because they can contain potentially security-sensitive information (like triggers for executing interesting hooks and information on what users to trust). It would certainly be possible to write a modified win32text-like extension that takes its cues from a versioned file (like the .hgtags and .hgsigs files currently supported). I'm not sure why the original author didn't go that way, though. 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, linefeeds, and Visual Studio
On Thu, Jun 4, 2009 at 4:20 PM, Paul Moore wrote: > Silly question, but given that Mercurial itself does *no* conversion, > and CRLF is the only valid form for that file, why shouldn't the file > be checked into the repository with CRLF endings, and that's the end > of it (apart from misconfigured win32text setups on the client)? That's certainly a valid setup, and I wasn't suggesting otherwise. I have no experience with .sln files, and I haven't really used win32text either; I was just commenting on the general facilities of Mercurial wrt these kinds of issues. > Ideally, the history should be imported with CRLF throughout, which is > a task for the migration process. If that's too hard because of > limitations in the available conversion tools, then maybe the > limitation has to be accepted that pre-conversion copies of the file > have incorrect line endings and a manual fiox is committed right after > the switchover. Importing it with CRLF throughout would certainly be possible. I'll add a section to my draft PEP. > Essentially, pcbuild.sln is a binary file, and should be treated as > such. Maybe it's an error in the Subversion setup that it's treated as > text at all... Yes, it certainly seems that way. 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] Issues with process and discussions (Re: Issues with Py3.1's new ipaddr)
On Thu, Jun 4, 2009 at 5:08 PM, C. Titus Brown wrote: > In my experience this kind automated stuff is too fragile to work > reliably & specifically over time, which is what we would want -- "fire > and forget". You could a python-dev account in the tracker and allow people to nosy it. > Is there a good python-dev archive search mechanism (other than to > google "python-dev " ;) out there? Wouldn't that help? Like http://python.markmail.org/? 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
[Python-Dev] Draft PEP 385: Migrating from svn to Mercurial
So, a while ago Martin von Löwis asked who would champion the migration to Mercurial, and I volunteered. He asked me to produce a PEP outlining which steps to take, which I've been working on. The PEP is numbered 385, and is just about ready for your review. I'd really welcome any sort of feedback or questions about Mercurial and surrounding tools relevant to the migration project (I'm happy to answer other questions as well, but maybe python-dev is not the appropriate forum for that -- instead, try mercur...@selenic.com and/or #mercurial on freenode). http://www.python.org/dev/peps/pep-0385/ In particular, you may want to review (a) branches that you care about and whether they would be migrated under the current proposal, (b) non-release tags that you think are useful and (c) the author map (check if it has a correct email address for you and people you know). Thanks to Antoine, Benjamin, Georg and Martin for early feedback. 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] Draft PEP 385: Migrating from svn to Mercurial
On Mon, Jun 8, 2009 at 16:29, Frank Wierzbicki wrote: > At PyCon, we discussed moving Jython's svn repository to Python's with > Martin von Löwis. I would think that Jython would live in Python's hg > repository in the same way as stackless and distutils. Has the > parallel project strategy been determined? Will they be separate > repositories, separate "forests", something else? I think they should just be separate repositories. The svn.python.org "repository" is more like a collection of actual repositories than a repository in itself. > Also, Martin suggested we migrate to Python's svn and then go along > for the svn->hg ride. Does that still make sense now that some > planning has been done? I'd say migrating to Python's svn doesn't make a whole lot of sense at this point, but I'll leave that to Martin (since he has to do the work). For the conversion, I can just as well take the Jython repo from your current server. I've started a svnsync job with your repo so I can run some test conversions. It's a relatively small repository, so it shouldn't be much of a problem. 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] Draft PEP 385: Migrating from svn to Mercurial
On Mon, Jun 8, 2009 at 21:57, "Martin v. Löwis" wrote: > See my other message. We need to collect SSH keys, and I don't mind > moving the Jython repository. OTOH, if the Jython repository gets > converted into hg right away, it's certainly (a little) less work. Yeah, I guess if you move it to a separate repo on the svn.python.org server that might be nice. But it's not a big deal either way. > FWIW, I really think that PEP 385 should really grow a timeline > pretty soon. Are we going to switch this year, next year, or 2011? Sorry, I should've been clearer. I fully intend to complete the conversion in a few months, say by October 1st or sooner. That would be between 3.1 and whatever the next release will end up being, I hope? It's just hard to be very specific at this point. BTW, I tried my hand at rewriting the revlog for the manifest, as described in the PEP, and it made the full conversion *much* (as in 70%) smaller. I've also been looking at what branches we should keep and will ask for definitive feedback on that point soonish. 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
[Python-Dev] Tags from closed branch heads?
So ca8d05e1f1d1 changed the default for repo.heads() to closed=False,
so that calls to heads() by default will not return closed heads.
Unfortunately, this also means that any tags from those heads will not
be considered anymore. That seems inadvertent at best, and may be
should be reverted. Conceptually, it seems wrong that deleting a
branch would also delete all the tags from it. I'd like to propose
this change:
diff --git a/mercurial/localrepo.py b/mercurial/localrepo.py
--- a/mercurial/localrepo.py
+++ b/mercurial/localrepo.py
@@ -320,7 +320,7 @@
def _hgtagsnodes(self):
last = {}
ret = []
-for node in reversed(self.heads()):
+for node in reversed(self.heads(closed=True)):
c = self[node]
rev = c.rev()
try:
Is that something we can agree on?
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] Tags from closed branch heads?
Sorry about that, got dev-lists mixed up in my head somewhere...
On Tue, Jun 9, 2009 at 16:52, Dirkjan Ochtman wrote:
> So ca8d05e1f1d1 changed the default for repo.heads() to closed=False,
> so that calls to heads() by default will not return closed heads.
> Unfortunately, this also means that any tags from those heads will not
> be considered anymore. That seems inadvertent at best, and may be
> should be reverted. Conceptually, it seems wrong that deleting a
> branch would also delete all the tags from it. I'd like to propose
> this change:
>
> diff --git a/mercurial/localrepo.py b/mercurial/localrepo.py
> --- a/mercurial/localrepo.py
> +++ b/mercurial/localrepo.py
> @@ -320,7 +320,7 @@
> def _hgtagsnodes(self):
> last = {}
> ret = []
> - for node in reversed(self.heads()):
> + for node in reversed(self.heads(closed=True)):
> c = self[node]
> rev = c.rev()
> try:
>
> Is that something we can agree on?
>
> 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] Python script language or not
On Wed, Jun 17, 2009 at 12:27, abhishek goswami wrote: > Can anyone clarify me. Please let me know also it is right forum or not. This is not the right forum. This mailing list is about developing the CPython interpreter. For general questions, you may want to try the comp.lang.python newsgroup. 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] semi-regular check that all committers are subscribed to python-committers
On Thu, Jul 2, 2009 at 21:04, Brett Cannon wrote: > If you have commit privileges on Python but are not subscribed to > python-committers, please let me know and I will subscribe you. Membership > on python-committers is mandatory as that's where we announce branch > freezes, etc. Would it be helpful if I was subscribed? I'm not strictly a committer, but what with the Mercurial migration I imagine it won't be long before the first cset bearing my name appears in the Python repository (plus I just saw there was some discussion about the hg migration there which I could weigh in on). 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] semi-regular check that all committers are subscribed to python-committers
On Thu, Jul 2, 2009 at 22:08, Brett Cannon wrote: > Maybe you should just get the commit privileges now. Any objections? Not from me, obviously. 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
[Python-Dev] Mercurial migration: progress report (PEP 385)
In response to some rumblings on python-committers and just to request more feedback, a progress report. I know it's long, I've tried to put to keep it concise and chunked, though. - First of all, I've got the basic conversion down, I've done it a few times now, with progressively better results. You can view some results at http://hg.python.org/, which has a preliminary cpython repository. *** The changeset hashes for that repo will change, so you won't be able to commit or pull from it in the future.*** - Second of all, some planning. I've thought about it a bit, and I think we should aim for going live with hg on August 1. Given that I'm on vacation from 8-18 July (and I'm not sure whether I'll be able to actually work on it during that time, though I imagine I'll be able to spend some time on it at least), that's quite ambitious, so I'm going to say it's okay if it slips by a few days. Putting a deadline out there is a good thing, anyway. - Third of all, to make this possible, it would be helpful if I got more feedback on the PEP. Last time I raised it, there was virtually nothing. This time, I'll include it inline so there's hopefully less of a barrier to reviewing it. - Fourth, Mercurial 1.3 was just released! Bet you didn't see that coming. It's looking like a pretty good release, with an experimental version of the much-coveted subrepository support (like svn:externals). This also means that the latest version of hgsubversion, the tool I used for the conversion, will be more accessible for converting other projects. You know you want to! - Fifth, here's a list of things, off the top of my head, that still need doing: * Get agreement on branch strategy and branch processing (list of branches + proposed handling at http://hg.python.org/pymigr/file/tip/all-branches.txt) <--- PLEASE REVIEW * Get agreement on tag processing (first come up with a list) * Set up hg-ssh infra (should be easy) * Set up hooks (should be mostly straightforward) * Set up roundup integration (should be made easier by quick revision map hgweb extension) * Write docs - Sixth (this is the good part), less obvious things that have been done or don't need doing: * .hgignore generation (I've been convinced it's too hard, the current version will do) * revlog reordering (it's painless and a big win) I'll get through all of these myself, but obviously any help would be welcome. For any hg users, writing docs should be an easy start. For others, please review the PEP (below), the branch map in http://hg.python.org/pymigr/file/tip/all-branches.txt and the author map at http://hg.python.org/pymigr/file/tip/author-map (not that much has changed since the start, so if you've looked at it already, feel free to skip this part). Right now I'm a little stuck on branch processing, because it's a long running script that needs a bunch of debugging, but I'll get going on that again. I think that's all I can think of for now, I'll update the PEP with new bits soon. Here it is, ready for your review: == Motivation After having decided to switch to the Mercurial DVCS, the actual migration still has to be performed. In the case of an important piece of infrastructure like the version control system for a large, distributed project like Python, this is a significant effort. This PEP is an attempt to describe the steps that must be taken for further discussion. It's somewhat similar to PEP 347 [1], which discussed the migration to SVN. To make the most of hg, I (Dirkjan) would like to make a high-fidelity conversion, such that (a) as much of the svn metadata as possible is retained, and (b) all metadata is converted to formats that are common in Mercurial. This way, tools written for Mercurial can be optimally used. In order to do this, I want to use the hgsubversion [2] software to do an initial conversion. This hg extension is focused on providing high-quality conversion from Subversion to Mercurial for use in two-way correspondence, meaning it doesn't throw away as much available metadata as other solutions. Such a conversion also seems like a good time to reconsider the contents of the repository and determine if some things are still valuable. In this spirit, the following sections also propose discarding some of the older metadata. Timeline TBD; needs fully working hgsubversion and consensus on this document. Transition plan Branch strategy Mercurial has two basic ways of using branches: cloned branches, where each branch is kept in a separate repository, and named branches, where each revision keeps metadata to note on which branch it belongs. The former makes it easier to distinguish branches, at the expense of requiring more disk space on the client. The latter makes it a little easier to switch between branches, but often has somewhat unintuitive results for people (though this has been getting better in recent versions of Mercurial). I'm still a bit on the fence abo
Re: [Python-Dev] Mercurial migration: progress report (PEP 385)
On Fri, Jul 3, 2009 at 01:01, Mark Hammond wrote: > Although this has come up in the past, I don't recall a resolution. > > What is your plan to handle svn:eol-style? We have some files in the tree > which need that support and it isn't clear to me how that would work with > the existing win32text extension provided with current mercurial releases. > (I've an outstanding patch to hg which should address some of these issues, > but without the 'rules' being versioned I fear that would still fall short.) What files would need what? Are there any files that really need to be \r\n on Windows and \n on Unix (and possibly \r on Mac)? I remember one file was discussed separately, but I think the outcome there was that it could just always be \r\n (since it wasn't used at all on non-Windows platforms). Anyway, knowing specific requirements (or where to find them) would help here. > Even more generally, how will you suggest Windows users work? Will local > files, in general, have windows line endings or unix? If the latter, will > there be hooks in-place to prevent editors on Windows 'accidently' mixing > eol styles? If so, this cycles back to the first question - how would we > know which files get treated that way? There will be a server-side hook to check whitespace. People will also be able to install it for commit-time. I think just using \n by default everywhere is a good default (though I almost always use Windows client machine, I do all nearly all of my development through a terminal on several Linux boxen), except where it isn't. People who want to use can set up the win32text stuff to get \r\n on Windows if they feel they need that -- we can provide information about that in the dev FAQ (although it would be nice if someone else who was more familiar with it -- like yourself! -- would write it). 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 migration: progress report (PEP 385)
On Fri, Jul 3, 2009 at 15:31, Mark Hammond wrote: > So we must work without effective EOL support? I fear we will end up like > the mozilla hg repo with some files in windows line endings and some with > linux. While my editing tools are good enough to preserve existing EOL > styles, I've found myself accidentally checking in new \r\n terminated files > in a repo which otherwise uses \n line endings. IMO, SVN's EOL support was > better than no EOL support. This is why we'll have hooks -- to prevent you from pushing changesets with inappropriate, to say the least, and, if you're willing to do a little bit of extra work, to prevent you from committing them. > This is exactly why I was asking for your advice - I can't work out how to > work effectively with win32text as it stands myself, so remain stuck > accidently checking in files with inappropriate line endings and stuck > working out how to move pywin32's CVS repo with abandoning the very > primitive EOL safety it offers... As long as the difference between \r\n- and \n-based files is clear and can be reasoned about, I don't see why having some of both (I'm assuming an overwhelming majority will have one, and only a few the other) is a big problem. But feel free to enlighten me! 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 migration: progress report (PEP 385)
On Fri, Jul 3, 2009 at 15:29, Stephen J. Turnbull wrote: > I'll have to try them again now that 1.3 is out, but I found Mercurial > named branches fundamentally unsuited to release management. Can you explain why, please? It's not clear from what you say below. > Ditto named branches. The problem is that (unless the internal > implementation has changed very recently) a Mercurial revision can be > on exactly one named branch (or on the trunk). That's still true. > Which defeats the purpose of having named branches, really. (I mean > the version control purpose; obviously it still can save disk space.) Why does it defeat the purpose? What, in your opinion, is the purpose? > Unless you're really short on space, though, that's not a big deal. > What would be more important to me (not that I matter for the purpose > of Python, but in XEmacs -- also a Mercurial shop -- I do :-) would be > the other way around: pulling an external branch into a named branch. > I have a feeling that working with such a repository with others would > be a little difficult. Can you give an example? > Stick with the CPython notation. At XEmacs, continuity of tags has > made our beta testers happy. (Well, the two of them who bothered to > mention it, anyway. :-) Right; Benjamin also mentioned that processing the tags just to be consistent with the recent tagging scheme would probably be the best solution. > As others (MvL, I think) have commented, this isn't really relevant to > Python which generally has four mainlines going at once. I don't see > why the requirements are going to change with the shift to hg, and I > see no reason why hg won't handle the existing workflow just fine. It will handle it, for sure, but I think it would all go easier if we could work with stricter subset branches (and leave the effective cherrypicking for the occasional problem). 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 migration: progress report (PEP 385)
On Fri, Jul 3, 2009 at 23:41, Brett Cannon wrote: > If we make it universal I say it should be '2.x' and '3.x'. The whole 'py' > prefix is redundant. Right, I was aiming for /python/2.x and /python/3.x as well. Actually, I currently have /cpython to also make CPython less special among it's peers, but that idea was met with some resistance on #python-dev. 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 migration: progress report (PEP 385)
On Fri, Jul 3, 2009 at 20:04, Brett Cannon wrote: > Fine by me as long as people realize that if anything is questionable then > the switch will not happen. Getting this right takes precedence over any > deadline. And obviously we will need to do at least one live conversion on > python.org hardware to make sure everything will work smoothly. I'm not sure I see the need to do a (live? what does that mean in this context) on python.org hardware. Why exactly is that better than me doing it on one of my boxes, as long as all the necessary tools and an idea of how to do it are publically available (from the pymigr repo, for example)? > And will make the idea of splitting out the standard library and tests a > reasonable thing to do. In due time, yes. > While I really like the idea of using named branches for each release so > that there is a single py3k branch that contains all relevant history for > every release, I think we should start simple and go with cloned branches. > That way the workflow does not radically shift from what we do now for svn > to start. Once the conversion is done and people are comfortable with hg we > can then discuss moving towards a named branch approach. I don't think the cloned branches is much simpler than the named branches approach, in several ways. For example, populating the branch part of a sys.whatever value is significantly harder. Also, if you follow a useful tagging approach, doing cloned branches means that release tags aren't available on trunk/main/default. That seems like a step backwards. > Sounds reasonable to me. We can just make a list and send it to > python-committers to make final decisions of what should stick around. This list exists and has been referenced in my email a few times. > I don't use tags so I don't really care, but in the name of easy transition > I say we don't change the naming scheme (although I have no issue dropping > obscure tags). The current proposal is to clean up old tags to agree with the current naming scheme (and dropping obscure and partial tags). > Something else that can go out to python-committers before the switch. This should just be done ASAP, it helps with a smooth conversion process. > I don't think there is a single project we host -- all two of them -- that > have not said they want to convert. So I say convert everything and let's > turn off the svn server by the end of the year. I say we tackle each one as we go. I say doing a good conversion job is valuable, and we should take as much time as we need (though not more). You advocate something similar below for the Python conversion. > Can we check these scripts into the repository itself? That way there is a > chance of reuse as hg commands, e.g. ``hg pydev-ci`` as a replacement for > ``make patchcheck``. I'm not sure there's an easy way to make them into commands (although I guess you could make an extension to that effect), but hooks would be very easy. > How about hg.python.org for the official branches and we keep > code.python.org for personal branches of the developers like we have done > with the bzr experiments? I think that's just confusing. Most people seem to like hg.python.org, and it's obvious that hg goes to hg.p.o. Dividing up the namespace only makes it harder to find things. > As I have said, we should change our workflow habits after the switch and > people are comfortable with hg. Well, not everyone agrees, and although I think it doesn't matter much for the conversion itself, it may affect the branching strategy discussion. (sys.revision discussion elided because some others have already been bikeshedding on it.) 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 migration: progress report (PEP 385)
On Sat, Jul 4, 2009 at 07:13, Nick Coghlan wrote: > I'd guess that the only way to keep those functional is to keep > svn.python.org around in read-only mode. No, actually: the idea (I think I floated it in the PEP, as well), is that I can write a simple extension for hgweb that knows the mapping of SVN rev to hg rev and so can make hg.python.org/python/2.x/rev/r32542 come out to the changeset that resulted from converting that revision. 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 migration: progress report (PEP 385)
On Fri, Jul 3, 2009 at 17:17, Georg Brandl wrote: > Do you have a key to the second column in that file? E.g. the difference > between "strip" and "discard" is not clear to me. "strip partial"? strip == discard. strip = remove, merged should be obvious, keep-clone means we'll keep the branch, in a separate clone, and keep-named means we'll keep the branch as a named branch in one of the other clones. > Why are there branch names starting with "../"? Because some people in the history put their branch at /python/branchname instead of /python/branches/branchname. That part will get cleaned up. [Regarding clone#branch syntax:] > * Does it work with "hg pull" etc. too, afterwards? Yes. > * Does it support more than one branch? You can only reference one branch at a time using the fragment specifier. > I would just kill all feature branches unless someone indicates it is > still used. There are very few active feature branches. > > (I guess in the case a branch gets killed erroneously it could still be > re-created after the conversion?) Re-creating it after the conversion could be done, I guess, but I'd prefer to get it right, the first time. As the branch map says, I'm mostly removing all the feature branches anyway. > As long as it can send diffs... It can. > That gets very ugly as soon as you start pulling from repos that just > fix a small typo or so. Okay, so we do no automatic checking. We can always write a script that walks the repository and finds all significant contributors. 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 migration: progress report (PEP 385)
On Sat, Jul 4, 2009 at 00:09, "Martin v. Löwis" wrote: > I would drop the roundup integration from the things that need to > be done pre-migration - there currently is no svn integration, so > not having it for hg is not a step backwards. Yeah, I mean just the linking here. > In the first sentence, you say that it can't actually work - so I > think we should drop the test. Okay. > I would like to see this well before the switch also. It could be > a patch (unified diff) stored in the tracker, or it could be an actual > branch that then needs to get merged with all active branches (IIUC). Yeah. Some help here would be welcome, too, as C is not a language I use often. 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 migration: progress report (PEP 385)
On Sat, Jul 4, 2009 at 00:37, Barry Warsaw wrote: > Doesn't Mercurial support an Subversion bridge? Would it be possible to > provide a /read-only/ copy of the hg branches for 2.4 (maybe), 2.5, 2.6, and > 3.1? If so, then the release managers would simply have to cut their > releases from the svn copy instead of the hg master. /All/ other work would > be done from the hg master. This shouldn't be too much of a burden since > it's done so rarely and would end with the EOL of each of those branches. There is some push support in hgsubversion, but it doesn't do tags at this time, for example. I think this setup would be needlessly complicated (and tools will need to learn the new revision specifier anyway, so why not have it learn them sooner rather than later)? 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 migration: progress report (PEP 385)
On Tue, Jul 7, 2009 at 10:16, M.-A. Lemburg wrote:
> Is there a standard notation for hg revisions that roundup could
> detect and turn into links (much like it does for svn) ?
[a-f0-9]{12} should mostly do.
(Sorry for my absence from the discussion for some time. I'll try to
update the PEP and summarize ongoing discussions here soon.)
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 migration: progress report (PEP 385)
On Tue, Jul 7, 2009 at 15:32, M.-A. Lemburg wrote: > Hmm, no prefix or suffix ? No, not really. hg often shows revision integers as well, but as they aren't globally consistent, they're of little value in communicating changeset pointers. > So we'll always have to write "see deadbeefdeadbeefff for details" > or "Reverting f00fl33df00fl33d00 after problems on Pentium CPUs" ?! Yes. And it's really not that bad. 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] 64-bit values in XML RPC: OverflowError: int exceeds XML-RPC limits
On Wed, Jul 15, 2009 at 16:42, Peter Hanecak wrote: > So my subsequent question is: What can help me solve the "writing" part? The XML-RPC protocol, as specified at [1], doesn't support integers with more than 32 bits (in fact, the i4 alias can be used to make the use of 4 bytes explicit). So, either don't use XML-RPC, or encode it in some other type (e.g. a string or base64). Cheers, Dirkjan [1] http://www.xmlrpc.com/spec ___ 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] PEP 385: updating the PEP
The diff below should reflect changes from the discussion we had last time. Please review. (Some comments may be more appropriate for the other threads I just kicked off.) Cheers, Dirkjan Index: pep-0385.txt === --- pep-0385.txt(revision 74294) +++ pep-0385.txt(revision 74296) @@ -59,27 +59,25 @@ often has somewhat unintuitive results for people (though this has been getting better in recent versions of Mercurial). -I'm still a bit on the fence about whether Python should adopt cloned -branches and named branches. Since it usually makes more sense to tag releases -on the maintenance branch, for example, mainline history would not contain -release tags if we used cloned branches. Also, Mercurial 1.2 and 1.3 have the -necessary tools to make named branches less painful (because they can be -properly closed and closed heads are no longer considered in relevant cases). +The current proposal is to use named branches for release branches and adopt +cloned branches for feature branches, with one exception to this rule: the 3.x +branches will be kept in separate clones from the 2.x branches. I think this +provides an optimal hybrid approach for Python's uses of branching. -A disadvantage might be that the used clones will be a good bit larger (since -they essentially contain all other branches as well). This can me mitigated by -keeping non-release (feature) branches in separate clones. Also note that it's -still possible to clone a single named branch from a combined clone, by -specifying the branch as in hg clone http://hg.python.org/main/#2.6-maint. -Keeping the py3k history in a separate clone problably also makes sense. +Differences between named branches and cloned branches: -XXX To do: size comparison for selected separation scenarios. +* Tags in a different (maintenance) clone aren't available in the local clone +* Clones with named branches will be larger, since they contain more data +(The Mercurial book discourages the use of named branches, but it is, in this +respect, somewhat outdated. Named branches have gotten much easier to use +since that comment was written, due to improvements in hg.) + Converting branches --- There are quite a lot of branches in SVN's branches directory. I propose to -clean this up a bit, by employing the following the strategy: +clean this up a bit, by following this basic strategy: * Keep all release (maintenance) branches * Discard branches that haven't been touched in 18 months, unless somone @@ -87,6 +85,21 @@ * Keep branches that have been touched in the last 18 months, unless someone indicates the branch can be deprecated +There's a `branch map`_ available that shows info about each branch: + +* keep-clone means we'll keep that branch in a separate clone +* keep-named means we'll keep that branch as a named branch in one of the clones +* strip means we won't keep that branch +* streamed-merge means that it got merged by committing several new revisions + to the other branch +* merged-r* means the branch got merged in the named revision +* merges? means I haven't checked/found out yet whether that branch was ever + merged +* ? means that your input would be even more helpful than for the other items +* some items have no action yet, feel free to treat that as just '?' + +.. _branch map: http://hg.python.org/pymigr/file/tip/all-branches.txt + Converting tags --- @@ -95,8 +108,8 @@ we should keep all release tags, and consider other tags for inclusion based on requests from the developer community. I'd like to consider unifying the release tag naming scheme to make some things more consistent, if people feel -that won't create too many problems. For example, Mercurial itself just uses -'1.2.1' as a tag, where CPython would currently use r121. +that won't create too many problems. The current proposal is to bring old +release tags in line with the current practice of release tag naming. Author map -- @@ -119,17 +132,19 @@ possible forms of pattern matching. The current Python repository already includes a rudimentary .hgignore file to help with using the hg mirrors. -It might be useful to have the .hgignore be generated automatically from -svn:ignore properties. This would make sure all historic revisions also have -useful ignore information (though one could argue ignoring isn't really -relevant to just checking out an old revision). +Since the current Python repository already includes a .hgignore file (for use +with hg mirrors), we'll just use that. Generating full history of the file +was debated but deemed impractical (because it's relatively hard with fairly +little gain, since ignoring is less important for older revisions). Revlog reordering - -As an optional optimization technique, we should consider trying a reordering -pass on the revlogs (internal Mercurial files) resulting from the conversion.
[Python-Dev] PEP 385: the eol-type issue
So, I've been not-working on this, which I feel bad about. Suffice it to say the day job has required more of my time then usual for the past few weeks. I want to get back into it, so let's start by re-raising this issue, which Mark Hammond conveniently summarized below. > On 4/07/2009 2:03 PM, Mark Hammond wrote: >> On 4/07/2009 12:30 PM, Nick Coghlan wrote: >>> And since Mercurial doesn't even allow us to say "this is a binary file" >>> the way CVS used to I'm currently not seeing any way for that to happen >>> except for win32text to be updated to correctly handle wild cards in >>> combination with negative filters. >> >> I agree with your conclusion. My ruminating on this over the last few >> months leaves me thinking this would involve: >> >> * my older 'accepted but then lost' hg patch to allow an explicit 'none' >> rule for a single file to override wildcards. This was and still is a good idea. It would be very nice if you could un-bitrot it and submit it for inclusion into crew-stable (so that it may land in the next release, which would hopefully be a somewhat near 1.3.2). >> * win32text be enhanced to use a normal versioned file in the root of >> the repo, much like hgingore, where a project can maintain project wide >> rules. I'm thinking that it should take stuff from .hgeols or whatever and apply rules from .hg/hgrc after that, so both may be used (and for backwards compatibility), but it sounds like a good idea in principle. >> * win32text be enhanced such that all python developers, regardless of >> platform, are willing to use this extension, even if the majority of >> files happen to use their native line ending (sauce for the goose is >> sauce for the gander, and all that...) I don't think that is necessary, I will elaborate below. >> * commit hooks be implemented to enforce this - but this should not be >> necessary if the above was implemented and socially enforced. You seem to advocate a two-step approach: enforce line endings through win32text, catch any errors that slipped through in a hook (commit hook is an optional first line of defense, changegroup hooks on the server to protect the rest of the world). I think inverting that approach would be better: have strict hooks on the server to prevent people from pushing inappropriate EOLs, and provide help on configuring win32text as an extra help for developers on Windows who use editors that work better with \r\n. That leaves people to pick their own weapon of choice against propagation of \r\n (e.g. better editor, commit hooks, whatever) while still making sure no inappropriate line endings land in the python.org repositories. It also seems to fit well with the whole consenting adults thing (but that might just be me). On Sun, Jul 19, 2009 at 15:27, Mark Hammond wrote: > Sorry Dirkjan - I just noticed I didn't CC you on this mail originally. I'm > wondering if you have any more thoughts on these EOL issues and if there is > anything I can do to help? Taking up the 'none' filter, first, and .hgeols, secondly, in the win32text extension would be wonderfully helpful, since I don't do much development on Windows and am therefore not that familiar with the extension in the first place. 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
[Python-Dev] PEP 385: pruning/reorganizing branches
So PEP 385 proposes to clean up the old branches we still have lying around in SVN. This list of branch: action items is what I've come up with to do this cleanup. Legend first: - keep-clone means we'll keep that branch in a separate clone - keep-named means we'll keep that branch as a named branch in one of the clones - strip means we won't keep that branch - streamed-merge means that it got merged by committing several new revisions to the other branch - merged-r* means the branch got merged in the named revision - merges? means I haven't checked/found out yet whether that branch was ever merged - ? means that your input would be even more helpful than for the other items - some items have no action yet, feel free to treat that as just '?' The actual List: py3k: keep-clone default: keep-clone tk_and_idle_maintenance: keep-clone release26-maint: keep-named release30-maint: keep-named pep-0383: keep-clone py3k-short-float-repr: strip streamed-merge multiprocessing-autoconf: keep-clone? release25-maint: keep-named io-c: keep-clone? py3k-issue1717: keep-clone tlee-ast-optimize: keep-clone release24-maint: keep-named empty: keep-clone? py3k-urllib: keep-clone tnelson-trunk-bsddb-47-upgrade: strip benjaminp-testing: strip py3k-importlib: keep-clone release23-maint: keep-named py3k-importhook: keep-clone ctypes-branch: strip decimal-branch: merged-r58143 bcannon-objcap: keep-clone? p3yk_no_args_on_exc: strip amk-mailbox: keep-clone? twouters-dictviews-backport: keep-clone? bcannon-sandboxing: keep-clone? release22-maint: keep-named theller_modulefinder: strip hoxworth-stdlib_logging-soc: strip partial tim-exc_sanity: merged-r46426 IDLE-syntax-branch: merged-r41480 strip-later ast-objects: strip ast-arena: merged-r41739 jim-doctest: strip ast-branch: merged-r39758 release23-branch: merges? jim-modulator: strip release21-maint: keep-named indexing-cleanup-branch: strip r23c1-branch: merged-r33637 r23b2-branch: merges? anthony-parser-branch: merged-r35460 r23b1-branch: merged-r32490 idlefork-merge-branch: strip getargs_mask_mods: strip cache-attr-branch: strip folding-reimpl-branch: strip streamed-merge r23a2-branch: merges? bsddb-bsddb3-schizo-branch: merged-r31008 r23a1-branch: merged-r30482 py-cvs-vendor-branch: strip DS_RPC_BRANCH: strip streamed-merge SourceForge: strip release22-branch: merged-r24921 r22rc1-branch: strip r22b2-branch: merges? merged-r24426 r22b1-branch: merges? r22a4-branch: merges? r22a3-branch: merges? r22a2-branch: merged-r22674 descr-branch: merged-r22139 release20-maint: keep-named gen-branch: merged-r21181 iter-branch: merged-r20492 r161-branch: merges? cnri-16-start: strip universal-33: merges? None: strip avendor: strip Distutils_0_1_3-branch: strip partial release152p1-patches: merges? string_methods: merged-r13927 PYIDE: strip OSAM: strip PYTHONSCRIPT: strip BBPY: strip jar: merges? alpha100: strip streamed-merge unlabeled-2.36.4: strip partial unlabeled-2.1.4: strip partial unlabeled-2.25.4: strip partial fix-test-ftplib: merged-r66673 trunk-math: py3k-grandrenaming: okkoto-sizeof py3k-ctypes-pep3118: merged-r62597 trunk-bytearray: merged-r61936 libffi3-branch: merged-r61234 alex-py3k: strip cpy_merge: strip py3k-pep3137: merged-r5 ../ctypes-branch: strip pep302_phase2: strip py3k-buffer: merged-r57181 p3yk-noslice py3k-struni p3yk: rename int_unification unlabeled-1.1.1: strip unlabeled-1.5.4: strip unlabeled-1.1.2: strip unlabeled-2.9.2: strip unlabeled-2.9.4: strip unlabeled-1.5.2: strip unlabeled-2.1.2: strip unlabeled-2.36.2: strip unlabeled-2.108.2: strip unlabeled-2.10.2: strip unlabeled-2.54.2: strip unlabeled-1.3.2: strip unlabeled-1.23.4: strip unlabeled-2.25.2: strip unlabeled-1.2.2: strip unlabeled-1.98.2: strip unlabeled-2.16.2: strip unlabeled-2.3.2: strip unlabeled-1.9.2: strip unlabeled-1.8.2: strip aimacintyre-sf1454481: merged-r46919 tim-current_frames: merged-r50541 bippolito-newstruct: merges? runar-longslice-branch: strip steve-notracing: strip rjones-funccall: merged-r46096 sreifschneider-newnewexcept: merged-r46456 tim-doctest-branch: merged-r36839 blais-bytebuf: strip ../bippolito-newstruct: rename rjones-prealloc: strip sreifschneider-64ints: strip stdlib-cleanup: strip ssize_t: merged-r42382 sqlite-integration: merged-r43514 tim-obmalloc: merged-r43059 Further actions: - implement branch map support in hgsubversion to be able to do named/unnamed/no branch on a branch-by-branch basis - implement splice map support in hgsubversion to be able to convert given merges to hg-native merge data 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] PEP 385: pruning/reorganizing branches
On Tue, Aug 4, 2009 at 08:06, "Martin v. Löwis" wrote: > I use that as a branch to tell build slaves to clean out their > current checkouts. So keep-clone sounds right, assuming it is possible > to target buildslaves at either clones or branches (which, IIUC, would > be necessary anyway, since we are using a mix of branches and clones). Yes, that should be straightforward. >> amk-mailbox: keep-clone? >> twouters-dictviews-backport: keep-clone? >> bcannon-sandboxing: keep-clone? >> bippolito-newstruct: merges? > > You'll probably need to explicitly ping the specific owners > (Andrew Kuchling, Thomas Wouters, Brett Cannon, Bob Ippolito) > to understand the fate of these branches. Will do. > This also raises the question how developers should publish their > "own" branches. For the bzr setup, there was apparently a proposal > to use directories for that, i.e. giving each developer a directory > on code.python.org to publish branches. User repositories has apparently worked well for Mozilla, so yeah, it's worth discussing. > Not doing that, but keeping owner information encoded in the clone > name, would be fine as well. > >> release23-branch: merges? >> r23b2-branch: merges? >> r22rc1-branch: strip >> r22b1-branch: merges? >> r22a4-branch: merges? >> r22a3-branch: merges? >> r161-branch: merges? > > It seems we had been creating CVS branches for every release around > that time; I don't remember the details. Each such branch should end > up in a tag. For example, release23-branch should (and does) ultimately > lead to tags/r23. cvs2svn wasn't able to recognize this correctly (as > CVS branches apply to each file individually), so it created the r23 > tag out of various copies that were current when the tag was made. > > I don't know what your plan is wrt. release tags, i.e. whether you > want to keep them all. If you are stripping out some of the branches, > but plan to keep the release tags, I wonder what the tags look like. The plan was to keep all maintenance branches and all release tags but not all release branches (since they seem to contain few commits anyway). >> release22-branch: merged-r24921 > > Not really. Jack Jansen merged some changes that got first applied > to the 2.2 > >> r22b2-branch: merges? merged-r24426 >> r22b2-branch: merges? merged-r24426 > >> release20-maint: keep-named > > See above. So you do plan to keep all past releases? > >> release152p1-patches: merges? > > Probably merged. I don't recall whether 1.5.2p1 really happened; > in r14966, Fred claims that he merged all changes from 1.5.2p2 (!). > > "Hopefully I got all this right!" > > I surely hope the same - I doubt anybody would go back and check > whether anything is missing. Thanks for the thorough review, 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] PEP 385: the eol-type issue
On Wed, Aug 5, 2009 at 01:43, Mark Hammond wrote: > Thanks Nick; I didn't want to be the only one saying that. There is a fine > line between asserting reasonable requirements for Windows users and being > obstructionist and unhelpful, and I'm trying to stay on the former side :) I'm not trying to be obstructionist and unhelpful (I hope that should be obvious). On the other hand, I'm working from the point of view of hg, which has two assumptions: - we're a distributed system, there's fairly little we can assume about clients - we exchange checksummed byte streams (even if we have some tools that assume those streams are code) - because of the previous point, there's one native (and therefore better, in a sense) serialization of what you consider "structured" data The first point means, for example, there will always be some clients who don't have win32text enabled, no matter what, so you can't rely on it, which is why I want to make the server hooks the primary line of defense, and view the client-side tools as helper tools (to make it easy not to trigger the server-side hooks). That doesn't mean I think Windows users are second-rate, or anything like that! > I'm not that happy with the server being the primary line of defense. Let's > say I make a branch of the hg repo, myself and a few others work on it > committing as we go, then attempt to merge back upstream. Let's say some of > the early commits on that clone introduced "bad" line endings. I'm guessing > I would be forced to make a number of whitespace-only checkins to normalize > the line-endings before it could merge - and these checkins would then be in > the history forever. Or I could attempt to recreate the clone by somehow > "replaying" the commits with line endings corrected. Either way, the > situation doesn't seem good. I don't think either is bad. In the first case, you have one or maybe two extra changesets. As we like to advocate small changesets that fix one thing, a changeset fixing up whitespace is par for the course. ;) The other solution would be to employ mq, for example, to fix up the commits, which mq excels at (although admittedly it has a learning curve). > I agree. It isn't fair to make this windows users problem. It would be > like me proposing the repo get imported with \r\n line endings, enforce that > with server side hooks, and let non-Windows users worry about the > ramifications of that - somehow I doubt that would fly - so neither should > it fly for Windows users... > > I'm more than willing to help on this; I haven't resurrected my stale patch > because I find win32text only 1/2 a solution that doesn't work in practice. > Therefore that patch is as stale for me as it is anyone. However, if a plan > is put in place which offers a full solution and the hg developers are > committed to it, I promise I'll put my hand up to help with implementation > in a fairly timely manner... Well, I'd be happy to help convince the hg crew to accept whatever we come up with, but I'm not sure I'm the best person to come up with it. It sounds like a versioned .hgeols would help a bunch of issues, but I have the feeling you know that better than me, so I'm hoping you can come up with a concrete proposal on what should change in win32text to fix all the problems you see. 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] PEP 385: the eol-type issue
On Wed, Aug 5, 2009 at 10:51, "Martin v. Löwis" wrote: > Not as Mercurial, no. As Python, we can certainly expect that all of our > contributors have read the developer FAQ, and set up their systems > accordingly. If all else fails, we can revoke commit access (or is > it "push access"?) if some committer doesn't get the configuration > right. We would, of course, prefer if it was very easy to get the > configuration right, so that problems don't occur in the first place. There will also be non-committers who forge changesets that you want to be able to push directly to the Python repositories. > If the client machines were the primary line of defense, Windows users > were treated equally: they would make as few mistakes as Unix users, > because the hooks do what they want correctly. Similarly, if Python kept its .py files in \r\n line endings by default instead of \n endings, Unix-like users would be more prone to mistake, so by keeping the .py files in \n-format, so Python is making Windows users second-rate by keeping the line endings in \n format. To cope with that, hg needs to do extra work on the client side. 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] PEP 385: the eol-type issue
On Wed, Aug 5, 2009 at 11:02, Mark Hammond wrote: > In general I agree - although I think we can enforce a "social contract" > which puts requirements on people who commit to the Python repository - and > therefore we can consider the server-side hooks a "secondary" defense. IOW, > the system (including the social aspects of the system) are setup such that > the server-side hooks are very rarely called upon. Agreed. > With all due respect, I suspect that is because you don't expect to see the > issue regularly. I suspect so, too! > I'm yet to work on a hg repository without mixed line endings. If I > understand correctly, every such repository would have involved a developer > checking in locally, than at some point in the future pushing these changes > upstream. I really really don't want hg to tell me at this final step that > I need to perform whitespace only fixes purely because I am running Windows. > > I understand we are discussing how win32text can offer that - but I must > object to your assertion that the situation I described isn't bad when you > hit it. I agree it is to be avoided, I'm just saying that I think it will be exceptional and therefore not a large burden, given other kinds of defenses we can put in place. > Actually, I think it is easy to make this problem much easier to understand; > mandate every platform should use win32text, then start collating the issues > people, including yourself, will no doubt face. I'm happy to get this ball > rolling, but again, don't want this left purely in the domain of "it is a > windows problem" - it isn't. I'm not sure how win32text will provide anything other than performance degradation for non-Windows developers, but if there's functionality to be had, I'm happy to mandate its use on every platform. 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] PEP 385: the eol-type issue
On Wed, Aug 5, 2009 at 12:04, Paul Moore wrote: > Given that my preference is to use Unix-style EOL for "text" files on > Windows, as every text editor I use (barring notepad!) understands LF > format, it seems to me that this proposal also means that the hook > would be optional for me. That suits me fine - I'd prefer to avoid > having hooks that are required for Python checkouts, as that means I > have to remember to configure them on each clone (IIUC). Yeah, this may also be what's making it harder for me to understand the issues. I am actually a Windows user, although I do most of my development on Linux servers through PuTTY. I just always make sure I use editors that respect the file's line endings, and so for those things where I've used hg to version code on Windows (for example, when testing a Firefox extension) and when my colleague who does edit his code inside Windows, I've just used editors that deal with line endings. Typically, in my case, that was either Notepad2 (an awesomely light-weight Notepad replacement) or Komodo (Edit). That solved all of my issues, so I haven't had a need for win32text so far. 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] PEP 385: the eol-type issue
On Wed, Aug 5, 2009 at 13:19, Mark Hammond wrote: > Configuring on each clone would certainly be sub-optimal, so the proposal is > this configuration be stored in a versioned file in the repo. Even if we do that, enabling hg extensions will still need to be done locally -- although it can be done per-user/box instead of per-clone. 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] PEP 385: the eol-type issue
On Wed, Aug 5, 2009 at 15:35, MRAB wrote: > Instead of just talking about line endings, could each file have a > specific 'filetype'? This would define what kind of data it contains, > how it's stored in the repository, and what actions to perform for > fetching and committing, including any checks: Sounds like YAGNI to me. The outline Nick provided seems to me to be quite close to the current win32text settings in syntax and purpose and staying close to that would help making adoption easier. 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] PEP 385: Mercurial issues
On Wed, Aug 5, 2009 at 15:57, Oleg Broytmann wrote: > Dirkjan, how does Mercurial handles charsets? If I have three files in > my repository - one in utf-8, another in koi8-r, and the third in cp1251 > encoding - I certainly don't want to convert them back and force, but I > want hg web interface to provide charset in the Content-Type header. It doesn't currently have any way to provide out-of-band charset info. 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] PEP 385: Mercurial issues
On Wed, Aug 5, 2009 at 16:35, Oleg Broytmann wrote: > Perhaps that's not a big issue for Python, but it's certainly a big > issue for me. I think there are extensions that try to deal with it. Have a look: http://mercurial.selenic.com/wiki/UsingExtensions If not, it should be easy to come up with something and write an extension for it. 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] www/svn python.org status update
On Sat, Aug 8, 2009 at 22:22, A.M. Kuchling wrote: > svn.python.org was deliberately not brought up again. The backups > were a few hours behind and missing the ~10 most recent commits. Not > disastrous, but it could probably mess up people's SVN trees, so after > some IRC discussion, the decision was to wait until the original disks > are available again. That will probably not occur until Monday, maybe > Tuesday. What's the last revision supposed to be? I keep a somewhat regularly updated full sync of the Python repo. 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 migration: help needed
On Tue, Aug 18, 2009 at 10:12, "Martin v. Löwis" wrote: > In this thread, I'd like to collect things that ought to be done > but where Dirkjan has indicated that he would prefer if somebody else > did it. I think the most important item here is currently the win32text stuff. Mark Hammond said he would work on this; Mark, when do you have time for this? Then I could set apart some time for it as well. Have stalled a bit on the fine-grained branch processing, hope to move that forward tomorrow. 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 migration: help needed
On Tue, Aug 18, 2009 at 13:32, Mark Hammond wrote: > I can make time, somewhat spasmodically, starting fairly soon. Might I > suggest that as a first task I can resurrect my old stale patch, and you can > arrange to install win32text locally and start experimenting with how mixed > line-endings can work for you. Once we are all playing in the same ballpark > I think we should be able to make good progress. Sounds good to me. 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 migration: help needed
On Tue, Aug 18, 2009 at 21:46, Brett Cannon wrote: > Can we possibly get these todo items in the PEP? I keep looking at the > PEP out of habit to see what the blockers are and they are not there, > at which point I have to dig up Martin's email. Will do. 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 migration: help needed
On Fri, Aug 21, 2009 at 09:16, Mark Hammond wrote: > I'm resurrecting my patch to support a filter called 'none' (which is > turning out to be harder than I thought). Off the top of my head, it would > the following would give us a pretty solid solution: > > * Finish my patch for 'none' as a filter, so '**=cleverencode' can be > reasonably used (currently you can't specify specific files *not* have > cleverencode, making it unsuitable in practice without the concept of > 'none') > > * Add support for versioned 'filter rules' - eg, /.hgfilters or similar. > > * This might be pushing my luck, but: add 'defensive' support to core hg for > this feature - if /.hgfilters exists, hg should refuse to operate on the > working tree unless the win32text extension is enabled. Sounds great to me. The latter might indeed be hard to get into the core, but seems like a good idea to try. 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
