Re: [Python-Dev] WebM MIME type in mimetypes module

Apologies if it has already been mentioned in the issue, but could the webm project be nudged towards officializing their mimetype? On Wed, Dec 3, 2014, 05:56 Cameron Simpson wrote: > On 02Dec2014 21:16, Terry Reedy wrote: > >On 12/2/2014 7:07 PM, Chris Rebert wrote: > >>To summarize the issue,

Re: [Python-Dev] WebM MIME type in mimetypes module

On 02Dec2014 21:16, Terry Reedy wrote: On 12/2/2014 7:07 PM, Chris Rebert wrote: To summarize the issue, it proposes adding an entry for WebM ( http://www.webmproject.org/docs/container/#naming ) to the mimetypes standard library module's file-extension to MIME-type database. (Specifically: .we

Re: [Python-Dev] WebM MIME type in mimetypes module

On 12/2/2014 7:07 PM, Chris Rebert wrote: Hi all, I'm seeking to move http://bugs.python.org/issue16329 towards conclusion. Since the discussion on the issue itself seems to have petered out, I thought I'd bring it up here. To summarize the issue, it proposes adding an entry for WebM ( http://w

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On 3 Dec 2014 08:47, "Donald Stufft" wrote: > > >> On Dec 2, 2014, at 5:42 PM, Guido van Rossum wrote: >> >> Before anyone gets too excited about Rietveld (which I originally wrote as an APp Engine demo), AFAIK we're using a fork that only Martin von Loewis can maintain -- and it's a dead-end for

[Python-Dev] WebM MIME type in mimetypes module

Hi all, I'm seeking to move http://bugs.python.org/issue16329 towards conclusion. Since the discussion on the issue itself seems to have petered out, I thought I'd bring it up here. To summarize the issue, it proposes adding an entry for WebM ( http://www.webmproject.org/docs/container/#naming )

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

On Tue, Dec 2, 2014 at 9:19 AM, Antoine Pitrou wrote: > On Mon, 1 Dec 2014 21:38:45 + > Nathaniel Smith wrote: >> >> object_set_class is responsible for checking whether it's okay to take >> an object of class "oldto" and convert it to an object of class >> "newto". Basically it's goal is jus

[Python-Dev] Python 2.x vs 3.x survey - new owner?

Last year in late December, I did a brief, 9 question survey of 2.x vs 3.x usage. I like the think the results were interesting, but I don't have the spare cash to do it again this year. I probably shouldn't have done it last year. ^_^ Is anyone interested in taking over the survey? It's on Su

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On 12/02/2014 02:47 PM, Donald Stufft wrote: On Dec 2, 2014, at 5:42 PM, Guido van Rossum mailto:gu...@python.org>> wrote: Before anyone gets too excited about Rietveld (which I originally wrote as an APp Engine demo), AFAIK we're using a fork that only Martin von Loewis can maintain -- and

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

> On Dec 2, 2014, at 5:42 PM, Guido van Rossum wrote: > > Before anyone gets too excited about Rietveld (which I originally wrote as an > APp Engine demo), AFAIK we're using a fork that only Martin von Loewis can > maintain -- and it's a dead-end fork because the Rietveld project itself only

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

Before anyone gets too excited about Rietveld (which I originally wrote as an APp Engine demo), AFAIK we're using a fork that only Martin von Loewis can maintain -- and it's a dead-end fork because the Rietveld project itself only supports App Engine, but Martin's fork runs on our own server infras

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Tue, Dec 2, 2014 at 9:50 AM, Brett Cannon wrote: > So I was waiting for Nick to say what he wanted to do for the peps repo > since I view it as I get 2/3 of the choices and he gets the other third. > > The way I view it, the options are: > > Move to GitHub > Move to Bitbucket > Improve our curr

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Tue, Dec 2, 2014 at 6:24 AM, Nick Coghlan wrote: > P.S. I'll also bring up some of the RFEs raised in this discussion > around making it possible for folks to submit pull requests via > GitHub/BitBucket, even if the master repositories are hosted on PSF > infrastructure. In case it helps with

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Tue Dec 02 2014 at 3:14:20 PM Barry Warsaw wrote: > On Dec 02, 2014, at 07:20 PM, Brett Cannon wrote: > > >No because only two people have said they like the experiment idea so > >that's not exactly enough to say it's worth the effort. =) Plus GitHub > >could be chosen in the end. > > Experime

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On 12/02/2014 08:50 AM, Brett Cannon wrote: > > So do people want PEPs or experimentation first? Experiments are good -- then we'll have real (if limited) data... which is better than no data. ;) -- ~Ethan~ signature.asc Description: OpenPGP digital signature ___

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

Brett Cannon writes: > Well, if I'm going to be the Great Decider on this then I can say > upfront I'm taking a pragmatic view of preferring open but not > mandating it, preferring hg over git but not ruling out a switch, > preferring Python-based tools but not viewing it as a negative to not > u

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Dec 02, 2014, at 07:20 PM, Brett Cannon wrote: >No because only two people have said they like the experiment idea so >that's not exactly enough to say it's worth the effort. =) Plus GitHub >could be chosen in the end. Experimenting could be useful, although if the traffic is disproportionate

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On 12/02/2014 11:21 AM, Brett Cannon wrote: > > I should say I will take a few days to think about this and then I will start > a new thread outlining what I think we should be aiming for to help frame the > whole discussion and to give proponents something to target. Thanks for taking this on, Br

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

I should say I will take a few days to think about this and then I will start a new thread outlining what I think we should be aiming for to help frame the whole discussion and to give proponents something to target. On Tue Dec 02 2014 at 2:20:16 PM Brett Cannon wrote: > On Tue Dec 02 2014 at 2:

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Tue Dec 02 2014 at 2:15:09 PM Donald Stufft wrote: > > On Dec 2, 2014, at 2:09 PM, Brett Cannon wrote: > > > > On Tue Dec 02 2014 at 1:59:20 PM Barry Warsaw wrote: > >> On Dec 02, 2014, at 06:21 PM, Brett Cannon wrote: >> >> >Well, if I'm going to be the Great Decider on this then I can say

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

> On Dec 2, 2014, at 2:09 PM, Brett Cannon wrote: > > > > On Tue Dec 02 2014 at 1:59:20 PM Barry Warsaw > wrote: > On Dec 02, 2014, at 06:21 PM, Brett Cannon wrote: > > >Well, if I'm going to be the Great Decider on this then I can say upfront > >I'm taking a pragmat

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Tue Dec 02 2014 at 1:59:20 PM Barry Warsaw wrote: > On Dec 02, 2014, at 06:21 PM, Brett Cannon wrote: > > >Well, if I'm going to be the Great Decider on this then I can say upfront > >I'm taking a pragmatic view of preferring open but not mandating it, > >preferring hg over git but not ruling

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Tue Dec 02 2014 at 1:52:49 PM Antoine Pitrou wrote: > On Tue, 02 Dec 2014 18:21:39 + > Brett Cannon wrote: > > > > So if we did have a discussion at the summit and someone decided to argue > > for FLOSS vs. not as a key factor then I would politely cut them off and > > say that doesn't ma

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Dec 02, 2014, at 06:21 PM, Brett Cannon wrote: >Well, if I'm going to be the Great Decider on this then I can say upfront >I'm taking a pragmatic view of preferring open but not mandating it, >preferring hg over git but not ruling out a switch, preferring Python-based >tools but not viewing it

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Tue, 02 Dec 2014 18:21:39 + Brett Cannon wrote: > > So if we did have a discussion at the summit and someone decided to argue > for FLOSS vs. not as a key factor then I would politely cut them off and > say that doesn't matter to me and move on. As I said, I would moderate the > conversat

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Tue, Dec 2, 2014 at 10:21 AM, Brett Cannon wrote: > > > On Tue Dec 02 2014 at 1:05:22 PM Guido van Rossum > wrote: > >> Thanks for taking charge, Brett. >> >> I personally think this shouldn't be brought up at the summit -- it's >> likely to just cause lots of heat about git vs. hg, free vs.

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Tue Dec 02 2014 at 1:05:22 PM Guido van Rossum wrote: > Thanks for taking charge, Brett. > > I personally think this shouldn't be brought up at the summit -- it's > likely to just cause lots of heat about git vs. hg, free vs. not-free, > "loyalty" to free or open tools, the weighing of core co

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

Thanks for taking charge, Brett. I personally think this shouldn't be brought up at the summit -- it's likely to just cause lots of heat about git vs. hg, free vs. not-free, "loyalty" to free or open tools, the weighing of core committers' preferences vs. outside contributors' preferences, GitHub'

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On Tue, Dec 2, 2014 at 9:23 AM, Tres Seaver wrote: > I'd vote for experimentation, to ground the discussion in actual practice. +1. There may be a number of practical gotchas that very well might not surface in PEPs and should be documented and planned for. Likewise with benefits. ___

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/02/2014 11:50 AM, Brett Cannon wrote: > So do people want PEPs or experimentation first? I'd vote for experimentation, to ground the discussion in actual practice. Tres. - -- ===

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

So I was waiting for Nick to say what he wanted to do for the peps repo since I view it as I get 2/3 of the choices and he gets the other third. The way I view it, the options are: 1. Move to GitHub 2. Move to Bitbucket 3. Improve our current tooling (either through new hosting setup and

Re: [Python-Dev] [Python-checkins] cpython (3.4): - Issue #22966: Fix __pycache__ pyc file name clobber when pyc_compile is

On Dec 02, 2014, at 06:44 AM, Jeremy Kloth wrote: >This test is failing on the Windows buildbots due to the hard-coded >path separator. Using `os.pathsep` should work assuming that >importlib returns normalized paths. Good catch, thanks, however os.path would be the one to use. Here's the patch

Re: [Python-Dev] [Python-checkins] cpython (3.4): - Issue #22966: Fix __pycache__ pyc file name clobber when pyc_compile is

On Mon, Dec 1, 2014 at 4:17 PM, barry.warsaw wrote: > summary: > - Issue #22966: Fix __pycache__ pyc file name clobber when pyc_compile is > asked to compile a source file containing multiple dots in the source file > name. > > diff --git a/Lib/test/test_py_compile.py b/Lib/test/test_py_comp

Re: [Python-Dev] PEP 481 - Migrate Some Supporting Repositories to Git and Github

On 2 December 2014 at 01:38, Guido van Rossum wrote: > As far as I'm concerned I'm just waiting for your decision now. The RhodeCode team got in touch with me offline to suggest the possibility of using RhodeCode Enterprise as a self-hosted solution rather than a volunteer-supported installation

Re: [Python-Dev] advice needed: best approach to enabling "metamodules"?

On Mon, 1 Dec 2014 21:38:45 + Nathaniel Smith wrote: > > object_set_class is responsible for checking whether it's okay to take > an object of class "oldto" and convert it to an object of class > "newto". Basically it's goal is just to avoid crashing the interpreter > (as would quickly happen