Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

>> I still fail to see the rationale for removing these >> two methods. > > I believe there was a thread (in January 2008) with a decision to keep > qsize() but to drop empty() and full(). That's something different: even if there was a decision, it doesn't mean that there was a rationale, and th

Re: [Python-Dev] Regexp 2.7

> Matthew Barnett has been doing a lot of work on the regular expressions engine > (it seems he hasn't finished yet) under http://bugs.python.org/issue2636. > However, the patches are really huge and touch all of the sre internals. I > wonder what the review process can be for such patches? Is ther

Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() and Queue.full()

> I would be happy to restore the documentation. You want the methods > back and I think that's sufficient reason to bring it back. Thanks! I'll look into the docstrings. Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/m

Re: [Python-Dev] Forgotten Py3.0 change to remove Queue.empty() andQueue.full()

> Skip changed it to the present wording last year: > http://svn.python.org/view/python/trunk/Doc/library/queue.rst?r1=59750&r2=59969 I see. I agree that the change was for the better. Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

> In light of this, what I'd love to see (but sadly can't really help > with, and am not optimistic about happening) is for: > > - python to grow a decent, cross platform, package management system > > - the standard library to actually shrink to a point where only > libraries that are not releas

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

> I have mixed feelings. It is great that the batteries are included, but > some batteries are showing their age or not maintained (who maintains > IDLE? - does the calendar module really warrant being in the standard > library? - imaplib is really not useful and IMAPClient which isn't in > the sta

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

> Perhaps we could encourage more "jumbo" distributions, like Enthought's > and ActiveState's. I suspect many people would rather be able to > maintain their Python functionality as a single product. I think the concept of "jumbo distribution" has been lost. I mentioned it to one of the Enthought

Re: [Python-Dev] Python 3.0 grammar ambiguous?

Fabio Zadrozny wrote: > I was wondering how does Python > disambiguate that... anyone has any pointers on it? That is easy to answer: py> parser.expr("f(*x)").totuple() (258, (326, (303, (304, (305, (306, (307, (309, (310, (311, (312, (313, (314, (315, (316, (317, (1, 'f')), (321, (7, '('), (329,

Re: [Python-Dev] Python 3.0 grammar ambiguous?

> To be honest I wasn't aware of this ambiguity. It seems that whoever > wrote the patch for argument unpacking (a, b, *c = ...) got "lucky" > with an ambiguous grammar. This surprises me, because IIRC usually > pgen doesn't like ambiguities. So how does it resolve the ambiguity? Regards, Martin

Re: [Python-Dev] IDLE maintenance

> As I said, I don't know the plans or people surrounding IDLE are. If it > needs a new maintainer I hereby volunteer. Can you please start by looking into the issues reported for the IDLE component? (there are currently 71 of them) For those with a patch in particular (17 currently), make a rec

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

> I'd like to suggest that any new candidate for the standard library be > discussed and then set aside for a cooling off period of ONE YEAR. If > then folks can all agree the library is not only Goodness, but of > general interest, especially for bootstrapping small projects, then take > a vote,

Re: [Python-Dev] RELEASED Python 3.1 alpha 1

>> On behalf of the Python development team and the Python community, I'm >> happy to announce the first alpha release of Python 3.1. > > Are there any plans for a Windows installer? Yes. However, I cannot produce them on weekends. Regards, Martin ___

Re: [Python-Dev] reviewing patches

> I have seen it said that one very useful activity is reviewing patches. > Of the issues in the tracker, it is not immediately clear to me what is > required of such a review. Many of these patches appear to be bundled in > with feature requests, leaving the question of whether the review it > jud

Re: [Python-Dev] Ext4 data loss

> If I understand the post properly, it's up to the app to call fsync(), Correct. > and it's only necessary when you're doing one of the rename dances, or > updating a file in place. No. It's in general necessary when you want to be sure that the data is on disk, even if the power is lost. So e

Re: [Python-Dev] Ext4 data loss

>> We already have os.fsync() and os.fdatasync(). Should the sync() (and >> datasync()?) method be added as an object-oriented convenience? > > It's more than an object oriented convenience. fsync() takes a file > descriptor as argument. Therefore I assume fsync() only syncs the data > to disk tha

Re: [Python-Dev] Ext4 data loss

> This is especially true given Windows has recently introduced a > transactional API for NTFS. Although the tone is - err - gushing - it > (a) should give some information on what is available, and (b) was high > on my google search list > > http://msdn.microsoft.com/en-us/magazine/cc163388.asp

Re: [Python-Dev] Ext4 data loss

> Maybe it would make more sense for "synced" to force fsync() on each > flush, not only on close. I'm not sure how useful it is, but that's > what "synced" would imply to me. That should be implement by passing O_SYNC on open, rather than explicitly calling fsync. Regards, Martin __

Re: [Python-Dev] Ext4 data loss

> Something that doesn't require deterministicly named tempfiles was Ted > T'so's explanation linked to earlier. > > read data from important file > modify data > create tempfile > write data to tempfile > *sync tempfile to disk* > mv tempfile to filename of important file > > The sync is necessa

Re: [Python-Dev] Building Py3K branch docs with Sphinx

> Can I ask which flavour of Sphinx is being used to build the py3k docs? The proper procedure to build the documentation is make update make htmlhelp #say Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman

Re: [Python-Dev] wait time [was: Ext4 data loss]

> It is starting to look as though flush (and close?) should take an > optional wait parameter, to indicate how much re-assurance you're > willing to wait for. Unfortunately, such a thing would be unimplementable on most of today's operating systems. Regards, Martin __

Re: [Python-Dev] wait time [was: Ext4 data loss]

> Let me try some examples. > > Suppose I'm running my applications on a laptop and I don't want the > disk to be spinning continually while I work. I'm willing to take the > risk of data loss in order to extend my battery life. So when you select "Save" in your application, would you like the d

Re: [Python-Dev] wait time [was: Ext4 data loss]

Jim Jewett wrote: > On 3/12/09, "Martin v. Löwis" wrote: >>> It is starting to look as though flush (and close?) should take an >>> optional wait parameter, to indicate how much re-assurance you're >>> willing to wait for. > >> Unfortuna

Re: [Python-Dev] Ext4 data loss

>>> The sync is necessary to ensure that the data is written to the disk >>> before the old file overwrites the new filename. >> You still wouldn't use the tempfile module in that case. Instead, you >> would create a regular file, with the name base on the name of the >> important file. >> > Uhm...

Re: [Python-Dev] Python-Dev] wait time [was: Ext4 data loss

Cameron Simpson wrote: > On 12Mar2009 22:09, Martin v. L?wis wrote: > | > Let me try some examples. > | > Suppose I'm running my applications on a laptop and I don't want the > | > disk to be spinning continually while I work. I'm willing to take the > | > risk of data loss in order to extend my

Re: [Python-Dev] Ext4 data loss

> auto-delete is one of the nice features of tempfile. Another feature > which is entirely appropriate to this usage, though, though, is creation > of a non-conflicting filename. Ok. In that use case, however, it is completely irrelevant whether the tempfile module calls fsync. After it has gener

Re: [Python-Dev] Building Py3K branch docs with Sphinx

Tim Golden wrote: > Martin v. Löwis wrote: >>> Can I ask which flavour of Sphinx is being used to build the py3k docs? >> >> The proper procedure to build the documentation is >> >> make update >> make htmlhelp #say > > > I think you misundersto

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

>> I don't like the standard library to shrink. It's good that batteries >> are included. > > If a decent package management system *was* included, this wouldn't be > an issue.. You can prove anything with a false premise... I believe that a package management system that is decent cannot possibl

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

Chris Withers wrote: > Jim Jewett wrote: - python to grow a decent, cross platform, package management system >> >> As stated, this may be impossible, because of the difference in what a >> package should mean on Windows vs Unix. >> >> If you just mean a way to add python packages from pypi as

Re: [Python-Dev] Ext4 data loss

> Think about the security implications of a file name that is in advance > known to an attacker as well as the fact that the said file will replace > an *important* system file. You should always use O_EXCL in that case. Relying on random name will be a severe security threat to the application.

Re: [Python-Dev] Python 2.6.2 and 3.0.2

Jason R. Coombs wrote: > I'm still holding my breath for Python 2.6.2, which fixes a Windows > DLL linking issue that was already fixed in 3.0.1. Obviously, the > proposed schedule has passed, but I would prefer a release sooner > than later. I suggest you start breathing again. Martin _

Re: [Python-Dev] PEP 377 - allow __enter__() methods to skip the statement body

> Note that using exceptions for control flow can be bad for other > implementations of Python. For example exceptions on the .NET framework > are very expensive. Why do you say that? What specific implementation of .NET are you referring to? What do you mean by "very"? > Isn't it better practis

Re: [Python-Dev] PEP 377 - allow __enter__() methods to skip the statement body

> I'm talking about IronPython on the Microsoft .NET framework - although > it is likely that the same is true of IronPython on Mono. I see. It would be interesting to find out why this is so much slower - I cannot believe that it is inherent in the commercial .NET framework, but rather expect tha

Re: [Python-Dev] PEP 377 - allow __enter__() methods to skip the statement body

> Well, StopIteration is still an implementation detail that only > occasionally bleeds through to actual programming. It says nothing about > whether using exceptions for non-exceptional circumstances (control > flow) is good practise. Personally I think it makes the intent of code > less easy to

Re: [Python-Dev] In-place operators

> I'm sure that consistency/completeness/safe_vs_sorry was the reason they > were added. But, if they aren't useful, they never should have been > (IMO). Why is that? [you are then giving a reason:] > It wastes the time of people who try to use them and then > find-out that they don't act as exp

Re: [Python-Dev] In-place operators

> I give up. My original question was whether anyone thought these > were a good idea. Look's like the answer is yes, Correct. > everyone is happy with > the functions and are glad they were added in 2.5. No. I don't really care - I don't use them, nor do I use anything else of the operator mod

Re: [Python-Dev] tracker status options

> It would be great to put in some of those extra status options that were > discussed recently... > >"Open/New" >"Needs help / Chatting" >"Under development" >"Pending feedback" >"Closed" Are you sure that you want them to be status options? Why not stages? ISTM that an issue

[Python-Dev] Security fixes in 2.5 and 2.4

I just got a few questions on how to apply security fixes. To clarify, I recommend the following guidelines: - whether something constitutes a security bug is sometimes debatable - in case of doubt, discussion is needed. I would be in favor of fixing it if the patch is small and obviously co

Re: [Python-Dev] tracker status options

> On Wed, Mar 18, 2009 at 23:47, "Martin v. Löwis" <mailto:mar...@v.loewis.de>> wrote: > > > It would be great to put in some of those extra status options > that were > > discussed recently... > > > >"Open/

Re: [Python-Dev] Multiprocessing on Solaris

> Today I was in contact with a Python user who tried to compile > pyprocessing - the ancestor of multiprocessing - on Solaris. It failed > to run because Solaris is missing two features (HAVE_FD_TRANSFER and > HAVE_SEM_TIMEDWAIT). Does anybody have a Solaris box at his disposal to > test the setti

Re: [Python-Dev] Multiprocessing on Solaris

> According to the user's experience multiprocessing should not compile > and run correctly unless this patch is applied. Can this please be more qualified? I can confirm Scott's observation: for the trunk, it compiles just fine, using SunPro CC on Solaris 10, on SPARC. Also, test_multiprocessing

Re: [Python-Dev] an unimportant question, ...

> Now, the internals are very clear to me. What I don't understand > is where the three saved bytes should be. If you look at the various patches in http://bugs.python.org/issue576101 then there is a three-byte saving in all versions from 1 to 6. Consequentially, the API was changed in those ver

Re: [Python-Dev] Multiprocessing on Solaris

> Sorry, I mistakenly said "without issue" and then copied the issues > below. I meant to say "not without issues." _multiprocessing does *not* > build on Solaris 8. Hmm. They are all warnings - did you omit the actual error message? The lack of CMSG_LEN seems to suggest that control messages are

Re: [Python-Dev] GSoC: Replace MS Windows Console with Unicode UI

> 2) IDLE does much better but its support seems to still be imcomplete. > Upgrade tk/tkinter/IDLE (wherever the problems lie) and make IDLE's > shell an alternate UI. That is certainly *no* good SoC project. Instead, just report it as a *specific* bug report (rather than saying "it seems incomple

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

In some environments, each new component must be approved. Once python is approved, the standard library is OK, but adding 7 packages from pypi requires 7 more sets of approvals. >>> True, but as I mentioend elsewhere, I myself haven't done a python >>> project where I only needed p

Re: [Python-Dev] Multiprocessing on Solaris

> I've started with a autoconf file for the multiprocessing backport > package. The tests should produce the same set of definitions but I'm > not able to test it on different platforms expect Linux. > http://python-multiprocessing.googlecode.com/svn/trunk/configure.ac If you want to see how it fa

Re: [Python-Dev] GSoC: Core Python development tools

> Everything I've seen from Daniel so far seems to be about either making > things we already do more efficient, or else providing additional > features in ways that don't make the tools any more confusing for others > already used to a particular way of doing things. So he seems to be > navigating

Re: [Python-Dev] GSoC: Core Python development tools

> The real issues with svnmerge are its occasional bugs or failures (it forgot > some changesets when merging in the io-c branch!), its slowness, and its > limitations (which are really inherent to the SVN model: e.g., if someone > commits to the branch you have just started doing an svnmerge to, y

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

I was always able to get what I need through aptitude. >>> Yes, well known for its ability to run on Windows and Mac OS... >> Is it? I had never heard before that aptitude works well on >> Windows (although it does work on OSX). > > I'm actually not quite sure if that was a sarcastic response

Re: [Python-Dev] GSoC: Core Python development tools

>> P.S. I don't believe your claim that it forgot changesets. Could it be >> that it simply forgot adding files, and that it did so because you >> already had the files in the sandbox, so that the merging failed? > > It's more weird actually, it actively forgot some changes in some files but > so

Re: [Python-Dev] Core projects for Summer of Code

> I don't disagree, I just don't want to volunteer projects for something > they don't want. Right, there must be clear indication that they are willing to accept the work when it's done. > Note also that some of the largest Python-based projects, Django, I have a working port of Django to Py3k,

Re: [Python-Dev] Core projects for Summer of Code

> Maybe I'm misunderstanding you but I didn't mean to say that this > version should work on both python 2.x and python 3.x. Ideally, there > would be a PIL distribution for 2.x only and another one for 3.x only. I don't know what Fredrik thinks, but I would not consider this ideal. Ideally, there

Re: [Python-Dev] tracker status options

> That would be great. It occurs to me that if we wanted to use > "Stage" settings, it would be easy to search for issues which are > not closed by literally searching for 'not closed' rather than > 'open'. I think it's also unclear whether the 'pending' stage means > 'suspended

Re: [Python-Dev] Issue workflow doc is now live

> I sent this out as a Google Doc a while back, but I just did a > proof-reading, converted it, and pushed it live to the > python.org > : http://www.python.org/dev/workflow/ . > So now people >

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

> Seems to me that while all this is fine for developers and Python users > it's completely unsatisfactory for people who just want to use Python > applications. For them it's much easier if each application comes with > all dependencies including the interpreter. I think it depends on your engine

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

> I do develop applications myself, and had only once in ten years > the desire to package everything in a stand-alone way, and then ended > up using freeze. I'm genuinely curious what the scenarios are where > people desire such packaging - I did hear the desire often, but never > fully explained.

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

> But I don't think that a "normal" Lunix user should ever have to involve > themselves directly with distutils or setuptools (it's OK to invoke them > from the installation routine, but not to require the user to unpack the > application then run setup.py). I completely agree. It would be best if

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

> If the problem is to get a recent enough version of the library, then > the library would better be installed "locally", for the application. > If it is too much a problem because the application depends on > billions of libraries which are 6 months old, the problem is to allow > such a dependenc

Re: [Python-Dev] tracker status options

> o consensus needed > o test needed > o patch needed > o patch needs work > o patch review > o commit review > > The first of these additional items is equivalent to your bullet item > above. I would propose that the issue, regardless of whether or not > it is a bug fix o

Re: [Python-Dev] Test failures under Windows?

> There was a discussion about this on the py3k mailing list back in > mid-2007 ("buildbots" thread) and perhaps later as well, at which > point I believe Martin added an "-n" option to regrtest and the > buildbot test.bat file to disable the assertions. Is that the py3k > branch piece you are ref

Re: [Python-Dev] GSoC: Replace MS Windows Console with Unicode UI

> Hi. I'm Japanese and non-ascii charactor user. (cp932) > > We have to use "IME" to input non-ascii charactor in Windows. > When "> chcp 65001" in cmd.exe, we cannot use IME on cmd.exe. > > So setting codepage to 65001 make output universal but make input ascii-only. > Sit!!! Is there a code pa

Re: [Python-Dev] tracker status options

> So, 'confirmed' instead of 'consensus needed' (or confirmed/approved, > to cover feature requests), and 'patch is appropriate' that comes...I'm > not quite sure where? If the person who did the triage actually thinks the patch is ready to be committed, it would be "commit review". Not sure in wh

Re: [Python-Dev] tracker status options

> OK, so given this then I revise the way I understand what is happening > in the ticket I'm looking at: a reviewer has said "this patch needs > work" and the submitter has not responded. Since the behavior has been > accepted as a valid bug this means...I can either work on the patch, or > post a

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

> * The creation of an *installer* is something quite different. An > installer for a py2exe based tool also doesn't need dependency > management. Right. I wasn't really talking about py2exe (anymore), but about installers for libraries. > An installer for a pure-python package that made no atte

Re: [Python-Dev] Test failures under Windows?

> Note that I previously opened http://bugs.python.org/issue5116 with a > patch to enable this to be controlled from Python via the msvcrt module. > This would enable the test suite to disable assertions for its entire run. This patch is fine with me. It might need some documentation, though. Ho

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

Tools like setuptools, zc.buildout, etc. seem great for developers but not very good for distributions. At last year's Pycon I think there was agreement from the Linux distributors that distutils, etc. just wasn't very useful for them. I think distutils is different here - it not only helps c

Re: [Python-Dev] version compare function into main lib

Correct me if I wrong, but shouldn't Python include function for version comparisons? On the packaging summit yesterday, people agreed that yes, we should have something like that in the standard library, and it should be more powerful than what distutils currently offers. There was no conclusi

Re: [Python-Dev] version compare function into main lib

I got the impression that people are generally happy with what setuptools provides for version parsing and comparison. Does anyone think that's not a good model? Procedurally, I think it's a very bad approach. I don't mind the setuptools implementation being used as a basis (assuming it gets

Re: [Python-Dev] splitting out bdist_* (was: interminable 'setuptools' thread)

I do think that it's relevant that the respective operating system packagers don't find bdist_rpm, bdist_deb, et. al. useful. It's not very useful to have a bdist_deb that nobody actually builds debs with. I think that conclusion is invalid: just because the distributions don't use it doesn't

[Python-Dev] Version strings

I just collected the version strings of versions that got released to PyPI, and put up the list on http://www.dcl.hpi.uni-potsdam.de/home/loewis/versions Most of them probably fit into any schema we come up with, but there are certainly some unconventional ones: 1 to 3 1.* Verrsion 1 working pr

Re: [Python-Dev] My summit notes (packaging)

PEP 345 introduces "Requires" and "Provides" wich are are implemented in Distutils and PyP, but are not widely used. 40 out of +4000 if I remember correctly. Martin will correct me here if I am wrong. Here are the actual numbers of packages that had a certain specifier in atleast one o

Re: [Python-Dev] bdist_linux (was: setuptools has divided the Python community)

I think that each OS community should maintain its own tool, that complies to the OS standard (wich has its own evolution cycle) Of course this will be possible as long as Distutils let the system packager find/change the metadata in an easy way. In the specific case of RPMs, I still think that

Re: [Python-Dev] bdist_linux

Maybe I don't understand what is meant by metadata, but I don't understand why we can't provide the same metadata as autotools Likewise, *this* I do not understand. In what way does autotools *provide* metadata? I can understand that it *uses* certain metadata, but it doesn't *provide* them...

Re: [Python-Dev] Test failures under Windows?

I guess I'll stop asking after this note, but can anyone give a final verdict on whether the older "-n" option can be restored to the buildbot test.bat (from the revision history I'm not actually sure it was intentionally removed in the first place)? I have now restored it; it was removed by an

[Python-Dev] PEP 382: Namespace Packages

I propose the following PEP for inclusion to Python 3.1. Please comment. Regards, Martin Abstract Namespace packages are a mechanism for splitting a single Python package across multiple directories on disk. In current Python versions, an algorithm to compute the packages __path__ must

Re: [Python-Dev] PyDict_SetItem hook

> I think it's worse to give the poor guy the run around > by making him run lots of random benchmarks. "the poor guy" works for Wingware (a company you may have heard of) and has contributed to Python at several occasions. His name is John Ehresmann. > In the end, someone will run a timeit or ha

Re: [Python-Dev] Should the io-c modules be put in their own directory?

>> I just noticed that the new io-c modules were merged in the py3k >> branch (I know, I am kind late on the news—blame school work). Anyway, >> I am just wondering if it would be a good idea to put the io-c modules >> in a sub-directory (like sqlite), instead of scattering them around in >> the Mo

Re: [Python-Dev] Getting values stored inside sets

> I've stumbled upon an oddity using sets. It's trivial to test if a > value is in the set, but it appears to be impossible to retrieve a > stored value, other than by iterating over the whole set. Of course it is. That's why it is called a set: it's an unordered collection of objects, keyed by

Re: [Python-Dev] PEP 382: Namespace Packages

> Perhaps we could add something like a sys.namespace_packages that would > be updated by this mechanism? Then, pkg_resources could check both that > and its internal registry to be both backward and forward compatible. I could see no problem with that, so I have added this to the PEP. Thanks fo

Re: [Python-Dev] PEP 382: Namespace Packages

Chris Withers wrote: > Martin v. Löwis wrote: >> I propose the following PEP for inclusion to Python 3.1. >> Please comment. > > Would this support the following case: > > I have a package called mortar, which defines useful stuff: > > from mortar impor

Re: [Python-Dev] PEP 382: Namespace Packages

> I'd like to extend the proposal to Python 2.7 and later. I don't object, but I also don't want to propose this, so I added it to the discussion. My (and perhaps other people's) concern is that 2.7 might well be the last release of the 2.x series. If so, adding this feature to it would make 2.7

Re: [Python-Dev] PEP 382: Namespace Packages

> Note that there is no such thing as a "defining namespace package" -- > namespace package contents are symmetrical peers. With the PEP, a "defining package" becomes possible - at most one portion can define an __init__.py. I know that the current mechanisms don't support it, and it might not be

Re: [Python-Dev] issue5578 - explanation

Alexandre Vassalotti wrote: > On Tue, Mar 31, 2009 at 11:25 PM, Guido van Rossum wrote: >> Well hold on for a minute, I remember we used to have an exec >> statement in a class body in the standard library, to define some file >> methods in socket.py IIRC. > > FYI, collections.namedtuple is also

Re: [Python-Dev] Integrate BeautifulSoup into stdlib?

> That's not entirely true; Cygwin comes with a package management tool > that probably could be used to set up a repository of python packages > for native Windows: Ah, ok. It has the big disadvantage of not being Microsoft-endorsed, though. In t

Re: [Python-Dev] Should the io-c modules be put in their own directory?

> I think Benjamin is right. While most of the C source is indeed > exactly one level below the root, there's plenty of code that isn't, > e.g. _ctypes, cjkcodecs, expat, _multiprocessing, zlib. And even > Objects/stringlib. It's fine with me either way. Martin __

Re: [Python-Dev] Mercurial?

> 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. I'm personally happy le

Re: [Python-Dev] UnicodeDecodeError bug in distutils

>>> Meanwhile, the 'register' command accepts Unicode, but is broken in >>> handling it. […] >>> >>> Unfortunately, this isn't fixable until there's a new 2.5.x release. >>> For previous Python versions, both register and write_pkg_info() >>> accepted 8-bit strings and passed them on as-is, so the

Re: [Python-Dev] Mercurial?

> I second not tossing the data and history. It serves as partial > justification for the decision, which has been and will occasionally > again be discussed on python-list. It's in subversion, so the history won't be tossed. To keep it online, it doesn't have to be in the PEP - putting it in a w

Re: [Python-Dev] Mercurial?

> Off the top of my head, the following is needed for a successful migration: > >- Verify that the repository at http://code.python.org/hg/ is > properly converted. I see that this has four branches. What about all the other branches? Will they be converted, or not? What about the stuff outsi

Re: [Python-Dev] Mercurial?

> 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

Re: [Python-Dev] Mercurial?

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

Re: [Python-Dev] Mercurial?

> 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. Now that Alexandre has also volunteere

Re: [Python-Dev] Mercurial?

Dirkjan Ochtman wrote: > 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 w

Re: [Python-Dev] Mercurial?

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

Re: [Python-Dev] Mercurial?

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

Re: [Python-Dev] Mercurial?

> 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. That would work fine for me. We currently call the account pythondev, but calling it hg would be shorter, and therefore better (plus, pythondev is associated with

Re: [Python-Dev] Mercurial?

> 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. I'm -1 on remov

Re: [Python-Dev] Mercurial?

> 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. We do require full real names (i.e. no nicknames). Can Mercurial guarantee such a thing?

Re: [Python-Dev] Mercurial?

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

Re: [Python-Dev] Mercurial?

>> 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). > > What about commits from other people, e.g. pulled from a repo or imported > via h

Re: [Python-Dev] Mercurial?

Nick Coghlan wrote: > Dirkjan Ochtman wrote: >> 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. > > Martin may be able to provide a better list of names based on the > checkin name<->SSH public key mapping in the SVN

<    1   2   3   4   5   6   7   8   9   10   >