Re: [Python-Dev] Mercurial migration: progress report (PEP 385)
2009/7/4 Brett Cannon : >> > 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. > > I personally prefer named branches, but that's just me and I am not about to > force my preferences on everyone. Guess we just have to see if others have > opinions against named branches. Personally, I prefer clones, as it seems to me that Mercurial named branches are not quite what people generally think of when they think of "branches", in some subtle respects. I could be wrong, as I don't personally use named branches. However, there's been a small thread on distutils-sig recently with a new Mercurial user complaining that he's got confused and messed up a repository. Without digging particularly deeply, it appears that the problems were caused by confusion over named branches. FWIW, the Mercurial book (http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html) describes named branches with the comment "If you're more in the “power user” category (*and* your collaborators are too)" (author's emphasis). I'm not sure we want to require contributors to be "power users" of Mercurial... Paul. PS Sorry for responding to an old thread - I couldn't locate more recent discussion, although I thought there had been some. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Experiment: Adding "re" to string objects.
MRAB wrote:
Sean Reifschneider wrote:
I'm mailing this to python-dev because I'd like feedback on the idea of
adding an "re" attribute to strings. I'm not sure if it's a good
idea or
not yet, but I figure it's worth discussion. The module mentioned here
includes a class called "restr()" which allows you to play with "s.re".
As some of you may recall, I'm not particularly fond of the recipe:
m = re.match(r'whatever(.*)', s)
if m:
m.group(1)
The other morning I came up on the idea of adding an "re" to strings, so
you could do things like:
if s.re.match(r'whatever(.*)'):
print s.re.group(1)
or:
if (date.re.match(r'(?P\d\d\d\d)-(?P\d\d)' or
date.re.match(r'(?P\d\d)-(?P\d\d\d\d)'):
print date.re.groupdict('year')
[snip]
Why not drop the ".re" part? You would, however, then need a new name
for the re split, eg "re_split".
Or you could make the string the pattern, eg r'whatever(.*)'.match(s).
+1 for re support built-in to strings.
Michael Foord
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk
--
http://www.ironpythoninaction.com/
http://www.voidspace.org.uk/blog
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Remove site-packages?!? [was: [Distutils] PEP 376 - from PyPM's point of view]
Michael Foord wrote: >> I agree. People with versioning issues *should* be using virtualenv. Tarek Ziadé replied (and several people later agreed) > Let's remove site-packages from Python then. What about those people *without* versioning issues? I have no qualms suggesting that package management programs avoid the use of site-packages. Such programs do need to cater to edge cases. But a single drop-it-in directory works great for the vast majority of *my* needs; requiring me to drink the Kool-Aid from a specific package management system just to get access to any add-ons -- even those I wrote myself in pure python -- would be a huge step backwards. -jJ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove site-packages?!? [was: [Distutils] PEP 376 - from PyPM's point of view]
At 04:07 PM 7/18/2009 -0400, Jim Jewett wrote: Michael Foord wrote: >> I agree. People with versioning issues *should* be using virtualenv. Tarek Ziadé replied (and several people later agreed) > Let's remove site-packages from Python then. What about those people *without* versioning issues? I have no qualms suggesting that package management programs avoid the use of site-packages. Such programs do need to cater to edge cases. But a single drop-it-in directory works great for the vast majority of *my* needs; requiring me to drink the Kool-Aid from a specific package management system just to get access to any add-ons -- even those I wrote myself in pure python -- would be a huge step backwards. IIUC, the new "user" directories supported by the 'site' module would fill this purpose. That is, rather than having a site-wide packages directory, there'd just be the user-specific package directories. (That having been said, I'm not actually in favor of the idea.) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove site-packages?!? [was: [D istutils] PEP 376 - from PyPM's point of view]
On Sat, 18 Jul 2009 16:07:39 -0400, Jim Jewett wrote: > What about those people *without* versioning issues? > > I have no qualms suggesting that package management programs avoid the > use of site-packages. Such programs do need to cater to edge cases. I'm just wondering how that is possible? Given that a package management system (pythonpkgmgr - for example) is a tool to assist in the management of packages in site-packages. If you take away the drop in directory (site-packages), effectively you're taking away the place for system drop in packages. I can't see the point in that. > But a single drop-it-in directory works great for the vast majority of > *my* needs; requiring me to drink the Kool-Aid from a specific package > management system just to get access to any add-ons -- even those I > wrote myself in pure python -- would be a huge step backwards. Where you keep your packages is entirely up to you. Even with the Python Package Manager, you can still have unversioned packages in project directories. That doesn't change. And you can still have unversioned packages in site-packages. So I can't really see that having a Package Manager program takes your use case scenerio backwards because it wouldn't really change it. (repeating) > But a single drop-it-in directory works great for the vast majority of > *my* needs; That's exactly what site-packages is. So it isn't clear why you want to remove the thing that you are advocating works so great David ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove site-packages?!? [was: [Distutils] PEP 376 - from PyPM's point of view]
David Lyon wrote: > So it isn't clear why you want to remove the thing that you are > advocating works so great Jim was quoting someone *else* that had suggested removing it (I'm not sure how serious the original suggestion actually was though). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia --- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
