Re: [Python-Dev] The Meaning of Resolotion (Re: bug tracker permissions request)

>> You only have resolutions on closed issues, > > Only for 'closed' or also for 'pending' and 'languishing'? Probably for all of them. I don't understand languishing, though (neither as an English word, nor as a status). > 'Languishing' is new (its first use was two months ago). Is it a form of

Re: [Python-Dev] Two small PEP ideas

> As to Guido's point about the decision making process, Nick's right. I just > want to make sure we can capture the resolution in the PEP, be it by BDFL > pronouncement or "hey, silence is acceptance" email. I don't think "silence is acceptance" will work out in practice. For issues where a PEP

Re: [Python-Dev] Two small PEP ideas

>> Without a BDFL, I think we need a committee to make decisions, e.g. by >> majority vote amongst committers. > > Couldn't we just go with the FLUFL? Not sure whether that's a serious proposal (April 1 is already some days back now). As a starting point, Barry would have to indicate whether he i

Re: [Python-Dev] Two small PEP ideas

Steve Holden wrote: > Martin v. Löwis wrote: >>>> Without a BDFL, I think we need a committee to make decisions, e.g. by >>>> majority vote amongst committers. >>> Couldn't we just go with the FLUFL? >> Not sure whether that's a serious propo

Re: [Python-Dev] patch for review: __import__ documentation

> I see the confusion. I think Martin meant more about open issues that > required discussion, not simply issues that had a patch ready to go. I actually think it is perfectly fine to point out that specific issues are need committer action on this list. This is what the list is there for. Waitin

Re: [Python-Dev] Two small PEP ideas

> IIRC in the IETF this is done by the committee chair. I think it's a > good idea to have this be a single person to avoid endless indecision. It then seems that this role should go to the release manager of the upcoming feature release. Assuming Georg can accept this additional responsibility.

Re: [Python-Dev] Two small PEP ideas

> Of course some PEPs could concern several categories, so we would > still need some kind of Pep dictator if there's no consensus. So what > about electing a BPC every year ? I think having a single body/person pronounce on all PEPs is sufficient; as that person should certainly listen to the o

Re: [Python-Dev] Two small PEP ideas

> Then it's not obvious that we will have many PEPs in the future. Given Guido's Theorem: the PEPs yet to be written will hopefully outnumber the PEPs written so far. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.o

Re: [Python-Dev] Frequency of the dev docs autobuild

R. David Murray wrote: > On Sat, 01 May 2010 16:18:19 +0100, Paul Moore wrote: >> On 1 May 2010 15:28, R. David Murray wrote: >>> Unless I'm missing something, I don't see any docs there about the >>> automated build process and when and where it runs. >> I assume Georg was referring to "Developm

Re: [Python-Dev] Frequency of the dev docs autobuild

> I wasn't asking for more precision than daily (I just hadn't seen it), but > now that I think about it it would indeed be nice to know when the cron > job starts, so that we know that if the checkin didn't happen before then, > it won't show up in the online docs until the next day. I don't thin

Re: [Python-Dev] Two small PEP ideas

> In the meantime, let's groom Benjamin to be the Sacred Next Uncle Galvanizing > the Gamut of Language Evolution. I don't think anybody having such a position permanently can really work. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.or

Re: [Python-Dev] Should we drop active support of OSF/1?

Jesus Cea wrote: > On 26/04/10 22:00, "Martin v. Löwis" wrote: >>> Maybe we can drop OSF/1 safely supporting Tru64 yet, but we don't have >>> any buildbot running any of this systems... >> Dropping support is fine with me, in the long term. If PEP 11

Re: [Python-Dev] Running Clang 2.7's static analyzer over the code base

> Will changing the indentation of source files to 4 space indents break > patches on the bug tracker? Plain patch will choke, but "patch -l" might accept them. I have only read the documentation, though, and don't know whether it does in practice. Regards, Martin

Re: [Python-Dev] Running Clang 2.7's static analyzer over the code base

Steve Holden wrote: > Antoine Pitrou wrote: >> Le Mon, 03 May 2010 16:11:53 -0700, Brett Cannon a écrit : >>> And in reply to Benjamin's question about the whitespace, I guess it >>> actually doesn't matter. More important to clean up in py3k. >> Would it be finally time to standardize all C files

[Python-Dev] Daily DMGs

David Bolen and I started producing daily OSX installers, at http://www.python.org/dev/daily-dmg/ If you find problems with these, please report them to bugs.python.org. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.pyth

Re: [Python-Dev] What's New text on future maintenance

> * It's very likely the 2.7 release will have a longer period of > maintenance compared to earlier 2.x versions. Python 2.7 will > continue to be maintained while the transition to 3.x is in > progress, and that transition will itself be lengthy. Most 2.x > versions are maintained for ab

Re: [Python-Dev] What's New text on future maintenance

A.M. Kuchling wrote: > On Fri, May 07, 2010 at 09:30:00AM +0200, "Martin v. Löwis" wrote: >> I agree with Terry: how did you arrive at the 4 years for 2.x releases? >> Bug fixes releases stopped after the next feature release being made, >> which gave (counting betwe

Re: [Python-Dev] Parallel test execution on buildbot

> Has anyone considered using regrtest's -j option in the buildbot > configuration to speed up the test runs? Yes, I did. I turned it off again when the tests started failing because of it. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.o

Re: [Python-Dev] Parallel test execution on buildbot

> FWIW I *usually* run the test suite with parallelization (it is just so > much quicker) and these days *rarely* see spurious failures as a result. > This is on Mac OS X, YMMV. I may misremember the details, but IIRC, the multiprocessing tests would fail to terminate on Solaris. This made it unsu

Re: [Python-Dev] HEADS UP: Compilation risk with new GCC 4.5.0

> Short history: new GCC 4.5.0 (released a month ago), when compiling with > -O3, is adding MMX/SSE instructions that requires stack aligned to 16 > byte. This is wrong, since x86 ABI only requires stack aligned to 4 bytes. I think this is debatable. It depends on the operating system also; ultima

Re: [Python-Dev] configuring the buildbot to skip some tests?

Bill Janssen wrote: > I've got parc-tiger-1 up and running again. It's failing on test_tk, > which makes sense, because it's running as a background twisted process, > and thus can't access the window server. It doesn't really make sense. It should skip the test, instead of failing it. I.e. abort

Re: [Python-Dev] configuring the buildbot to skip some tests?

>> I've got parc-tiger-1 up and running again. It's failing on test_tk, >> which makes sense, because it's running as a background twisted process, >> and thus can't access the window server. I should configure that out. >> >> I'm looking for documentation on how to configure the build slave so >

Re: [Python-Dev] configuring the buildbot to skip some tests?

exar...@twistedmatrix.com wrote: > On 03:17 am, jans...@parc.com wrote: >> I've got parc-tiger-1 up and running again. It's failing on test_tk, >> which makes sense, because it's running as a background twisted process, >> and thus can't access the window server. I should configure that out. > >

Re: [Python-Dev] configuring the buildbot to skip some tests?

> (Having said that, a similar situation with my buildslave prompted me > to spend the time fixing the bug so I didn't have to keep restarting > the slave, so maybe it's a good thing after all :-)) Indeed. More generally, I'd question the point of automated testing if people try to work around ser

Re: [Python-Dev] configuring the buildbot to skip some tests?

Bill Janssen wrote: > Martin v. Löwis wrote: > >> Bill Janssen wrote: >>> I've got parc-tiger-1 up and running again. It's failing on test_tk, >>> which makes sense, because it's running as a background twisted process, >>> and thus can

Re: [Python-Dev] configuring the buildbot to skip some tests?

> This is running /usr/bin/python in a session as a user that doesn't > have access to the GUI. The text above says that there is an > uncaught ObjC exception, caused by the lack of a connection to the > window server. Tk should have converted that to its own style of > errors but didn't. That m

Re: [Python-Dev] configuring the buildbot to skip some tests?

Vincent Davis wrote: > Not to interrupt you you conversation but I am interested in setting > up a buildbot on one of my Macs. Is there any documentations or advise > that is different from that of a linux machine? Any advise would be > appreciated. This is a little bit out of context: what exac

Re: [Python-Dev] configuring the buildbot to skip some tests?

> Yes thanks this is what I was thinking "set up a build slave for Python > testing", No reason this would not work on a leopard 10.6 machine? In my experience, it is mandatory that the slave admin has really good understanding of Python, and of the operating system that the slave runs on. Otherwi

Re: [Python-Dev] robots exclusion file on the buildbot pages?

> The buildbots are sometimes subject to a flood of "svn exception" > errors. It has been conjectured that these errors are caused by Web > crawlers pressing "force build" buttons without filling any of the > fields (of course, the fact that we get such ugly errors in the > buildbot results, rather

Re: [Python-Dev] robots exclusion file on the buildbot pages?

>> Hmm. Before doing any modifications, I'd rather have a definite analysis >> on this. Are you absolutely certain that, when that happened, the >> individual builds that caused this svn exception where actually >> triggered over the web, rather than by checkin? > > How can I be "absolutely certa

Re: [Python-Dev] robots exclusion file on the buildbot pages?

> I caused a few of those myself yesterday updating my PPC buildbots. > > Apologies! No need to apologize! these are not the ones Antoine is talking about. By convention, filling out the "Your name" field in a web build is recommended, so people know that this was an intentional build. I usually

Re: [Python-Dev] robots exclusion file on the buildbot pages?

> I'd find it useful if the "branch" field was a choice pull-down listing > valid branches, rather than a plain text field, and if the "revision" > field always defaulted to "HEAD". Seems to me that since the form is > coming from the buildmaster, that should be possible. Unfortunately, these for

Re: [Python-Dev] buildbot svn exceptions again...

Bill Janssen wrote: > parc-leopard-1 (and most of the other builders) are failing the svn > checkout with the following error: > > svn: PROPFIND of '/projects/python/trunk': Could not resolve hostname > `svn.python.org': Temporary failure in name resolution > (http://svn.python.org) > > When I l

Re: [Python-Dev] buildbot svn exceptions again...

> A workaround is to just put them in the /etc/hosts file. That doesn't really help: the test suite also relies on a number of host names. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-d

Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

Bill Janssen wrote: > Nick Coghlan wrote: > >> Bill Janssen wrote: >>> As far as I'm concerned, just tying all of >>> the program's threads to a single core would be fine, though I imagine >>> others would differ. >> Which can be done through the OS tools for setting an application's CPU >> affin

Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

> Not fixing this is a big problem. It relegates the only Python which > will be usable by many many people for many years, 2.x, to a toy > language status on modern machines. It will have threads, but the use > of them, either directly or indirectly by modules you may import, may > cause unpredi

Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

> But some of these, like JCC+pylucene, nltk, and vobject, were > developed with idiosyncratic funding resources which no longer exist. > Others, like pyglet, were developed for a completely different > purpose, and I doubt the developers care what I want. So, > realistically, I doubt it will be l

Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

Lennart Regebro wrote: > On Tue, May 18, 2010 at 14:52, Antoine Pitrou wrote: >> Le mardi 18 mai 2010 à 14:16 +0200, Lennart Regebro a écrit : Please read and understand the issue report mentioned by Nir before trying to make statements based on rumours heard here and there. >>> Oh, so D

Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

> I think the new GIL should be given a year or so in the wild before > you start trying to optimize theoretical issues you may run into. If > in a year people come back and have some examples of where a proper > scheduler would help improve speed on multi-core systems even more, > then we can addr

Re: [Python-Dev] pybuildbot.identify?

Bill Janssen wrote: > The PPC buildbots are running pretty well, now that I've opened a few > more ports, but I'd like to find this script "pybuildbot.identify" that > they keep complaining about, and install it. I've poked around the > Python sources, but haven't found it. You don't need to both

Re: [Python-Dev] pybuildbot.identify?

Bill Janssen wrote: > Matthias Klose wrote: > >> On 19.05.2010 18:09, Bill Janssen wrote: >>> The PPC buildbots are running pretty well, now that I've opened a few >>> more ports, but I'd like to find this script "pybuildbot.identify" that >>> they keep complaining about, and install it. I've po

Re: [Python-Dev] Fixing the GIL (with a BFS scheduler)

Peter Portante wrote: > Does anybody think that by having problems with the new GIL that it might > further weaken the adoption rate for 3k? -peter No, to the contrary. By having the new GIL being superior to the old implementation, the adoption rate for 3k will increase. Regards, Martin

Re: [Python-Dev] Unordered tuples/lists

> I think it'd be useful enough to go in the standard library. Now that > there's a sample implementation, should I still try to demonstrate why I > believe it's worth adding to the stdlib and get support? Most definitely. Just in case it isn't clear: nobody else seems to think this is useful (let

Re: [Python-Dev] Adding a new C API function in 2.6

Should we start thinking about releasing 2.6.6 soonish? By tradition, it should come out soon after 2.7 and be the last bugfix (except for security patches). I guess what I mean is, should we have (at least) one more point release before the post-2.7 last-bug-fix-release? Because it's a secu

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

In it he says that PEP 382 is being deferred until it can address PEP 302 loaders. I can't find any follow-up to this. I don't see any discussion in PEP 382 about PEP 302 loaders, so I assume this issue was never resolved. Does it need to be before PEP 382 is implemented? Are we wasting our time b

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

Am 29.05.2010 21:06, schrieb P.J. Eby: At 08:45 PM 5/29/2010 +0200, Martin v. Löwis wrote: In it he says that PEP 382 is being deferred until it can address PEP 302 loaders. I can't find any follow-up to this. I don't see any discussion in PEP 382 about PEP 302 loaders, so I assume

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

Looking at that proposal, I don't follow how changing *loaders* (vs. importers) would help. If an importer's find_module doesn't natively support PEP 382, then there's no way to get a loader for the package in the first place. True. However, this requires no changes to the API, AFAICT. The *find

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

For finders, their search algorithm is changed in a couple of ways. One is that modules are given priority over packages (is that intentional, Martin, or just an oversight?). That's an oversight. Notice, however, that it's really not the case that currently directories have precedence over modul

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

The PEP says the goal is to span packages across directories. If you split something like zope into multiple directories, does having a separate zope.pth file in each of those directories really cause a problem here? I think pje already answered this: yes, you do split zope into multiple packag

Re: [Python-Dev] Bugfix releases should not change APIs

Is it possible with svn or hg to get a list of the commits that changed version x to version y? A regular "svn log" on the maintenance branch will give you all the changes. You'll recognize from the checkin messages when the previous release was. Would is not be possible to get a diff betwe

[Python-Dev] _XOPEN_SOURCE on Solaris

In issue 1759169 people have been demanding for quite some time that the definition of _XOPEN_SOURCE on Solaris should be dropped, as it was unneeded and caused problems for other software. Now, issue 8864 reports that the multiprocessing module fails to compile, and indeed, if _XOPEN_SOURCE i

Re: [Python-Dev] ssl

In general, gettin all those „external“ projects seem to be complex to build. Is there a fast way? Run Tools\buildbot\external.bat. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev U

Re: [Python-Dev] ssl

Am 07.06.2010 12:44, schrieb Kristján Valur Jónsson: Thanks martin. I did as you suggested, and by installing nasm (creating nasmw.exe as a copy of nasm.exe) and without installing perl, was able to build the 32 bit debug version. The 64 bit version didn't want to build, probably because of som

Re: [Python-Dev] Reintroduce or drop completly hex, bz2, rot13, ... codecs

But in both cases you probably want bytes -> bytes and str -> str. If you want text out then put text in, if you want bytes out then put bytes in. No, I don't think so. If I'm using hex "encoding", it's because I want to see a text representation of some arbitrary bytestring (in order to displ

Re: [Python-Dev] Future of 2.x.

It might be useful to copy the identifiers and URLs of all the backport request tickets into some other repository, or to create some unique state in roundup for these. Rationale: it's almost certain that if the existing Python core maintainers won't evolve Python 2.X past 2.7, some other group

Re: [Python-Dev] Future of 2.x.

Am 09.06.2010 05:58, schrieb Alexandre Vassalotti: Is there is any plan for a 2.8 release? If not, I will go through the tracker and close outstanding backport requests of 3.x features to 2.x. Closing the backport requests is fine. For the feature requests, I'd only close them *after* the 2.7

Re: [Python-Dev] debug and release python

Some external software comes with proprietary .pyd bindings. Can you please explain what a "proprietary .pyd binding" is? Do you mean they come with extension modules? If so, there is no chance of using them in debug mode, anyway, right? So what specifically is the problem? Regards, Martin ___

Re: [Python-Dev] Sharing functions between C extension modules in stdlib

$ nm build/lib.macosx-10.4-x86_64-3.2-pydebug/datetime.so | grep _PyTime_DoubleToTimet f4e2 T __PyTime_DoubleToTimet $ nm build/lib.macosx-10.4-x86_64-3.2-pydebug/time.so | grep _PyTime_DoubleToTimet 0996 T __PyTime_DoubleToTimet I have two questions: 1) how does this happ

Re: [Python-Dev] debug and release python

Am 15.06.2010 14:48, schrieb Kristján Valur Jónsson: What I mean is that a third party software vendor supplies a foobarapp.pyd and a foobarapp_d.pyd dlls that link to python2x.dll and python2x_d.dll respectively. But the latter will have been compiled to match a certain settings of the objimpl.

Re: [Python-Dev] debug and release python

I.e. even with the change, it would *still* depend on objimpl.h (and other) settings what ABI this debug DLL exactly has. I think it does. My proposal was perhaps not clear: For existing python versions, always export _PyObject_DebugMalloc et al. Hmm. That's still not clear. What are "exist

Re: [Python-Dev] Mercurial

Am 19.06.2010 14:33, schrieb Barry Warsaw: On Jun 19, 2010, at 05:43 PM, Senthil Kumaran wrote: On Sat, Jun 19, 2010 at 01:51:04PM +0200, Antoine Pitrou wrote: FWIW, the EOL extension is now part of Mercurial: http://mercurial.selenic.com/wiki/EolExtension Should we all move soon now? Any ta

Re: [Python-Dev] Python Library Support in 3.x (Was: email package status in 3.X)

This anti-Py3 rhetoric is damaging to the community and needs to stop. We're moving forward toward Python 3.2 and beyond, complaining about it only saps valuable developer time (including your own) from getting these libraries you need ported faster. No, it's not damaging. Critical self-evaluati

Re: [Python-Dev] Mercurial

Am 19.06.2010 15:05, schrieb James Mills: On Sat, Jun 19, 2010 at 10:42 PM, Antoine Pitrou wrote: I should point out that I am in no way responsible for the migration. I think Dirkjan and Brett said they would tackle this after the 2.7 release. But they'd better answer by themselves :) I'm wi

Re: [Python-Dev] Python Library Support in 3.x (Was: email package status in 3.X)

Am 20.06.2010 19:01, schrieb Antoine Pitrou: On Mon, 21 Jun 2010 01:00:03 +0900 Steve Holden wrote: Given the amount of interest this thread has generated I can't help wondering why it isn't more prominent in python.org content. Is the developer community completely disjoint with the web conte

Re: [Python-Dev] #Python3 ! ? (was Python Library Support in 3.x)

Am 20.06.2010 18:20, schrieb Laurens Van Houtven: 2.x or 3.x? http://tinyurl.com/py2or3 If you are interested, we could host any material that somebody would want to provide on http://python.org/py2or3 (which would be one letter shorter :-). We could also make this a redirect. Regards, Mart

Re: [Python-Dev] email package status in 3.X

I can only imagine how difficult can it be to do such a conversion in a project like Twisted or Django where the I/O plays a fundamental role. For Django, you don't need to imagine, but can look at the actual changes: http://bitbucket.org/loewis/django-3k/ The choice of forcing the user to us

Re: [Python-Dev] #Python3 ! ? (was Python Library Support in 3.x)

Am 20.06.2010 19:48, schrieb Stephen J. Turnbull: Laurens Van Houtven writes: > Also, I'm pretty sure nobody has ever said that Python 3.x was a > "failure", or anything like it. #python has claims that Python 3.x, as > a platform for building production apps, is a work in progress How

Re: [Python-Dev] red buildbots on 2.7

If OS X is a supported and important platform for Python then fixing all problems that it reveals (or being willing to) should definitely not be a pre-requisite of providing a buildbot (which is already a service to the Python developer community). Fixing bugs / failures revealed by Bill's buildbo

Re: [Python-Dev] red buildbots on 2.7

Am 21.06.2010 21:45, schrieb Michael Foord: On 21/06/2010 20:30, Benjamin Peterson wrote: 2010/6/21 Bill Janssen: They are at the end of the buildbot list, so off-screen if you are using a normal browser. You have to scroll to see them. But not on the "stable" view and that's the only one I lo

Re: [Python-Dev] red buildbots on 2.7

Bill listed several other failures he saw on the buildbots and I see the same set, plus test_posix. Still, the question would be whether any of these failures can manage to block a release. Are they regressions from 2.6? That would make them good candidates for release blockers. Except that I

Re: [Python-Dev] red buildbots on 2.7

The test_posix failure is a regression from 2.6 (but it only shows up on some machines - it is caused by a fairly braindead implementation of a couple of posix apis by Apple apparently). http://bugs.python.org/issue7900 Ah, that one. I definitely think this should *not* block the release: a) th

Re: [Python-Dev] red buildbots on 2.7

This effectively substitutes getgrouplist called on the current user for getgroups. In 3.x, I believe the correct action will be to provide direct access to getgrouplist which is while not POSIX (yet?), is widely available. As a policy, adding non-POSIX functions to the posix module is perfectl

Re: [Python-Dev] os.getgroups() on MacOS X Was: red buildbots on 2.7

The problem that _DARWIN_C_SOURCE introduces is that it replaces system getgroups with a database query effectively making the true process' list of supplementary group IDs inaccessible to programs. See source code at . If

Re: [Python-Dev] "2 or 3" link on python.org

Am 25.06.2010 01:28, schrieb Stephen Thorne: > Steve Holden Wrote: >> Given the amount of interest this thread has generated I can't help >> wondering why it isn't more prominent in python.org content. Is the >> developer community completely disjoint with the web content editor >> community? >> >>

Re: [Python-Dev] "2 or 3" link on python.org

>>> I am extremely keen for this to happen. Does anyone have ownership of this >>> project? There was some discussion of it up-list but the discussion fizzled. >> >> Can you please explain what "this project" is, in the context of your >> message? GSoC? GHOP? > > Oh, I thought this was quite clear

Re: [Python-Dev] docs - Copy

Am 25.06.2010 18:57, schrieb Terry Reedy: > On 6/24/2010 8:51 PM, Rich Healey wrote: >> http://docs.python.org/library/copy.html > > Discussion of the wording of current docs should go to python-list. > Py-dev is for development of future Python. No no no. Mis-worded documentation is a bug, just

Re: [Python-Dev] docs - Copy

> My apologies guys, I see now. > > I will see if I can think of a less ambiguous way to word this and submit a > bug. Please don't take out or rephrase the word "shallow", though. This has a long CS tradition of meaning exactly what is meant here. Regards, Martin __

Re: [Python-Dev] Schedule for Python 2.6.6

Am 25.06.2010 18:18, schrieb Barry Warsaw: > Benjamin is still planning to release Python 2.7 final on 2010-07-03, so it's > time for me to work out the release schedule for Python 2.6.6 - likely the > last maintenance release for Python 2.6. > > Because summer schedules are crazy, and I want to l

Re: [Python-Dev] "2 or 3" link on python.org

> What page were we suggesting linking to? I don't think anybody proposed anything specific. Steve Holden suggested it should go to "reasoned discussion of the pros and cons as evinced in this thread". Stephen Thorne didn't propose anything specific but to have a large button. > I'll move the dis

Re: [Python-Dev] Schedule for Python 2.6.6

> Would that be bad or good (slipping into September)? I'd like to get a > release out as soon after 2.7 final as possible, but it's an entirely > self-imposed deadline. There's no reason why we can't push the whole 2.6.6 > thing later if that works better for you. OTOH, I can't go much earlier

Re: [Python-Dev] "2 or 3" link on python.org

Am 26.06.2010 02:41, schrieb Stephen Thorne: > On 2010-06-25, "Martin v. Löwis" wrote: >>> What page were we suggesting linking to? >> >> I don't think anybody proposed anything specific. Steve Holden >> suggested it should go to "reasoned dis

Re: [Python-Dev] #Python3 ! ? (was Python Library Support in 3.x)

Am 21.06.2010 17:13, schrieb Stephan Richter: > On Monday, June 21, 2010, Nick Coghlan wrote: >> A decent listing of major packages that already support Python 3 would >> be very handy for the new Python2orPython3 page I created on the wiki, >> and easier to keep up-to-date. (the old Early2to3Migra

Re: [Python-Dev] OS X buildbots: why am I skipping these tests?

> Seems to work fine. So this I don't understand. Any ideas, anyone? Didn't we discuss this before? The buildbot slave has no controlling terminal anymore, hence it cannot open /dev/tty. If you are curious, just patch your checkout to output the exact errno (e.g. to stdout), and trigger a build

[Python-Dev] Taking over the Mercurial Migration

It seems that both Dirkjan and Brett are very caught up with real life for the coming months. So I suggest that some other committer who favors the Mercurial transition steps forward and takes over this project. If nobody volunteers, I propose that we release 3.2 from Subversion, and reconsider Me

Re: [Python-Dev] OS X buildbots: why am I skipping these tests?

Am 30.06.2010 13:32, schrieb exar...@twistedmatrix.com: > On 05:24 am, mar...@v.loewis.de wrote: >>> Seems to work fine. So this I don't understand. Any ideas, anyone? >> >> Didn't we discuss this before? The buildbot slave has no controlling >> terminal anymore, hence it cannot open /dev/tty. If

Re: [Python-Dev] OS X buildbots: why am I skipping these tests?

> The whole "unexpected" skipping is somewhat of a mess. In an ideal > situation modules that are optionally built should be allowed to skip, While this may be the wide-spread interpretation, it is definitely *not* the original intention of the feature. When Tim Peters added it, he wanted it to t

Re: [Python-Dev] OS X buildbots: why am I skipping these tests?

>> When Tim Peters added it, he wanted it to tell him whether he did the >> Windows build correctly, INCLUDING ALL OPTIONAL PACKAGES that can >> possibly work on Windows. If you try to generalize this beyond Windows, >> then the only skips that are expected are the ones for tests that >> absolutely

Re: [Python-Dev] How are the bdist_wininst binaries built ?

> I would like to modify the code of the bdist installers, but I don't > see any VS project for VS 9.0. How are the wininst-9.0*exe built ? See PC/bdist_wininst. HTH, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailma

Re: [Python-Dev] Taking over the Mercurial Migration

Am 01.07.2010 02:01, schrieb Dan Buch: > /me throws hat into ring. I'm in the middle of migrating fairly > large chunks of an overgrown codebase from Subversion to Mercurial, > so I might actually have worthwhile input :) To all the volunteers: an issue that apparently requires immediate attentio

Re: [Python-Dev] How are the bdist_wininst binaries built ?

>> See PC/bdist_wininst. > > Hm, my question may not have been clear: *how* is the wininst-9.0 > built from the bdist_wininst sources ? I see 6, 7.0, 7.1 and 8.0 > versions of the visual studio build scripts, but nothing for VS 9.0. Ah. See PCbuild/bdist_wininst.vcproj. Regards, Martin _

Re: [Python-Dev] Mercurial migration readiness

Am 01.07.2010 23:57, schrieb Paul Moore: > will Roundup extract an attachment from an email and add > it to the issue as a file? That would be particularly neat... It actually does. Feel free to try it out on the life system (i.e. not worrying about bogus issues - we have several test issues alrea

Re: [Python-Dev] Can Python implementations reject semantically invalid expressions?

> We know that many semantic errors in Python lead to runtime errors, e.g. > 1 + "1". If an implementation rejected them at compile time, would it > still be Python? E.g. if the keyhole optimizer raised SyntaxError (or > some other exception) on seeing this: > > def f(): > return 1 + "1" >

Re: [Python-Dev] Can Python implementations reject semantically invalid expressions?

Am 02.07.2010 08:55, schrieb Craig Citro: >> This question has an easy answer - can you possibly tell the difference? >> > > Ok, I'm obviously being silly here, but sure you can: The dis module is deliberately (*) not part of the Python language and standard library; it's an implementation detail

Re: [Python-Dev] Mercurial migration readiness

> I don't know about "try" -- personally I don't see a difference for > the release procedure, no matter where the source comes from. I guess you haven't done a release yet, then :-) Assuming you are going to use https://svn.python.org/projects/sandbox/trunk/release/release.py then you'll have

Re: [Python-Dev] Mercurial migration readiness

Am 02.07.2010 15:09, schrieb Fred Drake: > On Fri, Jul 2, 2010 at 8:34 AM, Antoine Pitrou wrote: >> The two sets of repositories use different conversion tools and rules. >> They have nothing in common (different changeset IDs, different >> metadata, different branch/clone layout). > > I'd love t

Re: [Python-Dev] Mercurial migration readiness

> Can somebody comment on how much ongoing effort is required to keep that > mirror running? As everybody else indicated: none (I believe). FWIW, the bzr mirror wasn't that self-maintaining: the process started to consume too much memory and got killed; the cron jobs broke, and so on, so we final

Re: [Python-Dev] Are you ready for Mercurial migration?

Am 02.07.2010 17:08, schrieb Antoine Pitrou: > On Fri, 2 Jul 2010 17:29:02 +0300 > anatoly techtonik wrote: >> To shed some light on the readiness of Python community for the switch >> I've opened public Google Wave. Please add your opinion if you can and >> send this link to other contributors yo

Re: [Python-Dev] More detailed build instructions for Windows

> I'm trying to test out a patch to add a timeout in subprocess.py on > Windows, so I need to build Python with Visual Studio. The docs say > the files in PCBuild/ work with VC 9 and newer. Which docs did you look at specifically that said "and newer"? That would be a bug. > I downloaded Visual

Re: [Python-Dev] More detailed build instructions for Windows

Am 03.07.2010 16:34, schrieb Christian Heimes: > Am 03.07.2010 09:00, schrieb "Martin v. Löwis": >>> I'm trying to test out a patch to add a timeout in subprocess.py on >>> Windows, so I need to build Python with Visual Studio. The docs say >>> t

Re: [Python-Dev] Mercurial migration readiness

>>> I'd love to see a more detailed description of this, including why >>> someone new to Mercurial would choose one over the other. > >> I think someone new to Mercurial shouldn't choose either one. > >> Just sit back and wait for the real migration to happen. > > I would say that using the SVN

<    7   8   9   10   11   12   13   14   15   16   >