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

[Yann Kaiser]

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, 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: .webm => video/webm ) [...]
> >
> >If it has remained a defacto standard for the two years since your
> >made that list, that would be a point in favor of recognizing it.
> >Have .webm files become more common in actual use?
>
> Subjectively I've seen a few more about that I think I used to.
> And there are definitely some .webm files on some websites I support.
>
> Can't say if they're more common in terms of hard data though. But if most
> browsers expect them, arguably we should recognise their existence.
>
> Usual disclaimer: I am not a python-dev.
>
> Cheers,
> Cameron Simpson 
>
> The nice thing about standards is that you have so many to choose from;
> furthermore, if you do not like any of them, you can just wait for next
> year's model.   - Andrew S. Tanenbaum
> ___
> 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/
> kaiser.yann%40gmail.com
>
___
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] WebM MIME type in mimetypes module

[Cameron Simpson]

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: .webm => video/webm ) [...]


If it has remained a defacto standard for the two years since your 
made that list, that would be a point in favor of recognizing it.  
Have .webm files become more common in actual use?


Subjectively I've seen a few more about that I think I used to.
And there are definitely some .webm files on some websites I support.

Can't say if they're more common in terms of hard data though. But if most 
browsers expect them, arguably we should recognise their existence.


Usual disclaimer: I am not a python-dev.

Cheers,
Cameron Simpson 

The nice thing about standards is that you have so many to choose from;
furthermore, if you do not like any of them, you can just wait for next
year's model.   - Andrew S. Tanenbaum
___
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] WebM MIME type in mimetypes module

[Terry Reedy]

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://www.webmproject.org/docs/container/#naming ) to the mimetypes
standard library module's file-extension to MIME-type database.
(Specifically: .webm => video/webm )
Mozilla, Microsoft, Opera, and freedesktop.org (the de facto standard
*nix MIME type database package) all acknowledge the existence of a
video/webm MIME type (see the issue for relevant links), and this MIME
type is in WebM's documentation.
However, there is no official IANA registration for WebM's MIME type,
and none seems to be forthcoming/planned.

As R.D.M. said in the issue:

So we have two choices:
leave it to the platform mime types file to define because it is not even on 
track to be an official IANA standard,
or include it with a comment that it is a de-facto standard.

[...]

I guess I'd be OK with adding it as a de-facto standard, though I'm not 
entirely comfortable with it. But that would represent a change in policy, so 
others may want to weigh in.



Nobody has weighed in during the subsequent ~2 years, so I'm hoping a
few of y'all could weigh in one way or the other, and thus bring the
issue to a definitive conclusion.


If it has remained a defacto standard for the two years since your made 
that list, that would be a point in favor of recognizing it.  Have .webm 
files become more common in actual use?




--
Terry Jan Reedy

___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Nick Coghlan]

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 fork because the Rietveld
project itself only supports App Engine, but Martin's fork runs on our own
server infrastructure. These environments are *very* different (App Engine
has its own unique noSQL API) and it took a major hack (not by MvL) to get
it to work outside App Engine. That fork is not supported, and hence our
Rietveld installation still has various bugs that have long been squashed
in the main Rietveld repo. (And no, I don't have time to help with this --
my recommendation is to move off Rietveld to something supported.)

Thanks Guido - I'd started thinking in that direction for PEP 462 (in terms
of potentially using Kallithea/RhodeCode for the review component rather
than Reitveld), so it's good to know you'd be OK with such a change.

> It probably makes sense to include code reviews in the matrix of what
tools we’re going to use then yea?

I'd suggest asking for discussion of a more general path forward for
CPython workflow improvements.

Not a "this must be included in the proposal", but rather answering the
question, "if we choose this option for the support repos, how will it
impact the future direction of CPython maintenance itself?".

Cheers,
Nick.

>
> Like Github/Bitbucket/etc have review built in. Other tools like
Phabricator do as well but are self hosted instead.
>
> ---
> Donald Stufft
> PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
>
___
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

[Python-Dev] WebM MIME type in mimetypes module

[Chris Rebert]

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 ) to the mimetypes
standard library module's file-extension to MIME-type database.
(Specifically: .webm => video/webm )
Mozilla, Microsoft, Opera, and freedesktop.org (the de facto standard
*nix MIME type database package) all acknowledge the existence of a
video/webm MIME type (see the issue for relevant links), and this MIME
type is in WebM's documentation.
However, there is no official IANA registration for WebM's MIME type,
and none seems to be forthcoming/planned.

As R.D.M. said in the issue:
> So we have two choices:
> leave it to the platform mime types file to define because it is not even on 
> track to be an official IANA standard,
> or include it with a comment that it is a de-facto standard.
[...]
> I guess I'd be OK with adding it as a de-facto standard, though I'm not 
> entirely comfortable with it. But that would represent a change in policy, so 
> others may want to weigh in.


Nobody has weighed in during the subsequent ~2 years, so I'm hoping a
few of y'all could weigh in one way or the other, and thus bring the
issue to a definitive conclusion.

Cheers,
Chris
--
https://github.com/cvrebert
___
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] advice needed: best approach to enabling "metamodules"?

[Nathaniel Smith]

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 just to avoid crashing the interpreter
>> (as would quickly happen if you e.g. allowed "[].__class__ = dict").
>> Currently the rules (spread across object_set_class and
>> compatible_for_assignment) are:
>>
>> (1) both oldto and newto have to be heap types
>> (2) they have to have the same tp_dealloc
>> (3) they have to have the same tp_free
>> (4) if you walk up the ->tp_base chain for both types until you find
>> the most-ancestral type that has a compatible struct layout (as
>> checked by equiv_structs), then either
>>(4a) these ancestral types have to be the same, OR
>>(4b) these ancestral types have to have the same tp_base, AND they
>> have to have added the same slots on top of that tp_base (e.g. if you
>> have class A(object): pass and class B(object): pass then they'll both
>> have added a __dict__ slot at the same point in the instance struct,
>> so that's fine; this is checked in same_slots_added).
>>
>> The only place the code assumes that it is dealing with heap types is
>> in (4b)
>
> I'm not sure. Many operations are standardized on heap types that can
> have arbitrary definitions on static types (I'm talking about the tp_
> methods). You'd have to review them to double check.

Reading through the list of tp_ methods I can't see any other that
look problematic. The finalizers are kinda intimate, but I think
people would expect that if you swap an instance's type to something
that has a different __del__ method then it's the new __del__ method
that'll be called. If we wanted to be really careful we should perhaps
do something cleverer with tp_is_gc, but so long as type objects are
the only objects that have a non-trivial tp_is_gc, and the tp_is_gc
call depends only on their tp_flags (which are unmodified by __class__
assignment), then we should still be safe (and anyway this is
orthogonal to the current issues).

> For example, a heap type's tp_new increments the type's refcount, so
> you have to adjust the instance refcount if you cast it from a non-heap
> type to a heap type, and vice-versa (see slot_tp_new()).

Right, fortunately this is easy :-).

> (this raises the interesting question "what happens if you assign to
> __class__ from a __del__ method?")

subtype_dealloc actually attempts to take this possibility into
account -- see the comment "Extract the type again; tp_del may have
changed it". I'm not at all sure that it's handling is *correct* --
there's a bunch of code that references 'type' between the call to
tp_del and this comment, and there's code after the comment that
references 'base' without recalculating it. But it is there :-)

>> -- same_slots_added unconditionally casts the ancestral types
>> to (PyHeapTypeObject*). AFAICT that's why step (1) is there, to
>> protect this code. But I don't think the check actually works -- step
>> (1) checks that the types we're trying to assign are heap types, but
>> this is no guarantee that the *ancestral* types will be heap types.
>> [Also, the code for __bases__ assignment appears to also call into
>> this code with no heap type checks at all.] E.g., I think if you do
>>
>> class MyList(list):
>> __slots__ = ()
>>
>> class MyDict(dict):
>> __slots__ = ()
>>
>> MyList().__class__ = MyDict()
>>
>> then you'll end up in same_slots_added casting PyDict_Type and
>> PyList_Type to PyHeapTypeObjects and then following invalid pointers
>> into la-la land. (The __slots__ = () is to maintain layout
>> compatibility with the base types; if you find builtin types that
>> already have __dict__ and weaklist and HAVE_GC then this example
>> should still work even with perfectly empty subclasses.)
>>
>> Okay, so suppose we move the heap type check (step 1) down into
>> same_slots_added (step 4b), since AFAICT this is actually more correct
>> anyway. This is almost enough to enable __class__ assignment on
>> modules, because the cases we care about will go through the (4a)
>> branch rather than (4b), so the heap type thing is irrelevant.
>>
>> The remaining problem is the requirement that both types have the same
>> tp_dealloc (step 2). ModuleType itself has tp_dealloc ==
>> module_dealloc, while all(?) heap types have tp_dealloc ==
>> subtype_dealloc. Here again, though, I'm not sure what purpose this
>> check serves. subtype_dealloc basically cleans up extra slots, and
>> then calls the base class tp_dealloc. So AFAICT it's totally fine if
>> oldto->tp_dealloc == module_dealloc, and newto->tp_dealloc ==
>> subtype_dealloc, so long as newto is a subtype of oldto -- b/c this
>> means newto->tp_dealloc will end up calling oldto->tp_dealloc anyway.
>> OTOH it's not actually a guarantee of anything useful to see that
>> oldto->tp_dealloc == newto

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

[Dan Stromberg]

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 SurveyMonkey.

It was mentioned last year, that it might be interesting to see how
things change, year to year.  It was also reported that some people
felt that late December wasn't necessarily the best time of year to do
the survey, as a lot of people were on vacation.

The Python wiki has last year's results:
https://wiki.python.org/moin/2.x-vs-3.x-survey
___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Pierre-Yves David]

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 it's a dead-end fork because the
Rietveld project itself only supports App Engine, but Martin's fork
runs on our own server infrastructure. These environments are *very*
different (App Engine has its own unique noSQL API) and it took a
major hack (not by MvL) to get it to work outside App Engine. That
fork is not supported, and hence our Rietveld installation still has
various bugs that have long been squashed in the main Rietveld repo.
(And no, I don't have time to help with this -- my recommendation is
to move off Rietveld to something supported.)


It probably makes sense to include code reviews in the matrix of what
tools we’re going to use then yea?

Like Github/Bitbucket/etc have review built in. Other tools like
Phabricator do as well but are self hosted instead.


I think the people/company behind phabricator are planning to offer an 
hosting solution. Could be worth poking at them to have and idea of what 
is the status of it.



--
Pierre-Yves David
___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Donald Stufft]

> 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 
> supports App Engine, but Martin's fork runs on our own server infrastructure. 
> These environments are *very* different (App Engine has its own unique noSQL 
> API) and it took a major hack (not by MvL) to get it to work outside App 
> Engine. That fork is not supported, and hence our Rietveld installation still 
> has various bugs that have long been squashed in the main Rietveld repo. (And 
> no, I don't have time to help with this -- my recommendation is to move off 
> Rietveld to something supported.)


It probably makes sense to include code reviews in the matrix of what tools 
we’re going to use then yea?

Like Github/Bitbucket/etc have review built in. Other tools like Phabricator do 
as well but are self hosted instead.

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Guido van Rossum]

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
infrastructure. These environments are *very* different (App Engine has its
own unique noSQL API) and it took a major hack (not by MvL) to get it to
work outside App Engine. That fork is not supported, and hence our Rietveld
installation still has various bugs that have long been squashed in the
main Rietveld repo. (And no, I don't have time to help with this -- my
recommendation is to move off Rietveld to something supported.)

On Tue, Dec 2, 2014 at 2:33 PM, Eric Snow 
wrote:

> 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 current tooling (either through new hosting setup and/or
> adding
> > first-world support for downloading PRs from GitHub/Bitbucket)
>
> I'd argue that option #3 here is somewhat orthogonal to switching
> hosting.  It makes sense regardless unless we plan on ditching roundup
> and reitveld (to which I'd be opposed).
>
> >
> > Regardless of what we do, I think we should graduate the mirrors on
> GitHub
> > and Bitbucket to "official" -- for the proposed repos and cpython -- and
> get
> > their repos updating per-push instead of as a cron job. I also think we
> > should also flip on any CI we can (e.g. turn on Travis for GitHub along
> with
> > coveralls support using coverage.py's encodings trick). This will get us
> the
> > most accessible repo backups as well as the widest tool coverage for
> > contributors to assist them in their contributions (heck, even if we just
> > get regular coverage reports for Python that would be a great win out of
> all
> > of this).
>
> +1 to all of this.  Doing this would allow us to move forward with
> GH/BB-roundup/reitveld integration (option #3) sooner rather than
> later, regardless of moving to other hosting.
>
> > So do people want PEPs or experimentation first?
>
> +1 to PEPs.  It's basically already happening.  I'd like to see where
> 474/481/etc. end up, particularly with what Nick brought up earlier.
>
> Furthermore, I'm not sure how effectively we can experiment when it
> comes to moving hosting.  There's overhead involved that biases the
> outcome and in part contributes to the momentum of the initial
> experimental conditions.  I doubt any external solution is going to
> prove drastically better than another, making it harder to justify the
> effort to move yet again.
>
> -eric
>



-- 
--Guido van Rossum (python.org/~guido)
___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Eric Snow]

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 current tooling (either through new hosting setup and/or adding
> first-world support for downloading PRs from GitHub/Bitbucket)

I'd argue that option #3 here is somewhat orthogonal to switching
hosting.  It makes sense regardless unless we plan on ditching roundup
and reitveld (to which I'd be opposed).

>
> Regardless of what we do, I think we should graduate the mirrors on GitHub
> and Bitbucket to "official" -- for the proposed repos and cpython -- and get
> their repos updating per-push instead of as a cron job. I also think we
> should also flip on any CI we can (e.g. turn on Travis for GitHub along with
> coveralls support using coverage.py's encodings trick). This will get us the
> most accessible repo backups as well as the widest tool coverage for
> contributors to assist them in their contributions (heck, even if we just
> get regular coverage reports for Python that would be a great win out of all
> of this).

+1 to all of this.  Doing this would allow us to move forward with
GH/BB-roundup/reitveld integration (option #3) sooner rather than
later, regardless of moving to other hosting.

> So do people want PEPs or experimentation first?

+1 to PEPs.  It's basically already happening.  I'd like to see where
474/481/etc. end up, particularly with what Nick brought up earlier.

Furthermore, I'm not sure how effectively we can experiment when it
comes to moving hosting.  There's overhead involved that biases the
outcome and in part contributes to the momentum of the initial
experimental conditions.  I doubt any external solution is going to
prove drastically better than another, making it harder to justify the
effort to move yet again.

-eric
___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Eric Snow]

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 any GH/BB-to-roundup/reitveld integration we
might do, I've already done something similar for GH-to-reviewboard at
work.  All the code is on-line:

https://bitbucket.org/ericsnowcurrently/rb_webhooks_extension

-eric
___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Brett Cannon]

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.
>
> Experimenting could be useful, although if the traffic is disproportionate
> (e.g. peps are updated way more often than devinabox) or folks don't
> interact
> with each of the repos, it might not be very representative.  Still, I
> think
> it's better to get a visceral sense of how things actually work than to
> speculate about how they *might* work.
>

That's my thinking. It's more about the workflow than measuring engagement
on GitHub vs. Bitbucket (we already know how that skews). If I had my wish
we would put the same repo in all three scenarios, but that is just asking
for merge headaches.

But I think if we go to the community and say, "help us test dev workflows
by submitting spelling and grammar fixes" then we should quickly get an
idea of the workflows (and I purposefully left devinabox out of a move
since it is never touched after it essentially became a build script and a
README and so represents our existing workflow; any benefit on our own
infrastructure can go straight to cpython anyway which we can all
experience).
___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Ethan Furman]

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
___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Ben Finney]

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
> use Python, etc.

(and you've later clarified that these will all be factors weighing in
favour of a candidate.)

Thanks for expressing your thoughts. Big thanks for taking on the role
of consulting, evaluating, and deciding on this issue.

-- 
 \ “I think Western civilization is more enlightened precisely |
  `\ because we have learned how to ignore our religious leaders.” |
_o__)—Bill Maher, 2003 |
Ben Finney

___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Barry Warsaw]

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
(e.g. peps are updated way more often than devinabox) or folks don't interact
with each of the repos, it might not be very representative.  Still, I think
it's better to get a visceral sense of how things actually work than to
speculate about how they *might* work.

Cheers,
-Barry


signature.asc
Description: PGP signature
___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Ethan Furman]

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, Brett.

--
~Ethan~



signature.asc
Description: OpenPGP digital signature
___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Brett Cannon]

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: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
>>> 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 use Python, etc. I would
>>> like
>>> >to think I have earned somewhat of a reputation of being level-headed
>>> and
>>> >so none of this should really be a surprise to anyone.
>>>
>>> I think it's equally important to describe what criteria you will use to
>>> make
>>> this decision.  E.g. are you saying all these above points will be
>>> completely
>>> ignored, or all else being equal, they will help tip the balance?
>>>
>>
>> Considering Guido just gave me this position I have not exactly had a ton
>> of time to think the intricacies out, but they are all positives and can
>> help tip the balance or break ties (I purposely worded all of that with
>> "prefer", etc.). For instance, if a FLOSS solution came forward that looked
>> to be good and close enough to what would be a good workflow along with
>> support commitments from the infrastructure team and folks to maintain the
>> code -- and this will have to people several people as experience with the
>> issue tracker has shown -- then that can help tip over the closed-source,
>> hosted solution which might have some perks. As for Python over something
>> else, that comes into play in open source more from a maintenance
>> perspective, but for closed source it would be a tie-breaker only since it
>> doesn't exactly influence the usability of the closed-source solution like
>> it does an open-source one.
>>
>> Basically I'm willing to give brownie points for open source and Python
>> stuff, but it is just that: points and not deal-breakers.
>>
>>
>> This sounds like a pretty reasonable attitude to take towards this.
>>
>> If we’re going to be experimenting/talking things over, should I withdraw
>> my PEP?
>>
>
> 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.
>
> Basically a PEP staying in draft is no big deal.
>
___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Brett Cannon]

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 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 use Python, etc. I would
>> like
>> >to think I have earned somewhat of a reputation of being level-headed and
>> >so none of this should really be a surprise to anyone.
>>
>> I think it's equally important to describe what criteria you will use to
>> make
>> this decision.  E.g. are you saying all these above points will be
>> completely
>> ignored, or all else being equal, they will help tip the balance?
>>
>
> Considering Guido just gave me this position I have not exactly had a ton
> of time to think the intricacies out, but they are all positives and can
> help tip the balance or break ties (I purposely worded all of that with
> "prefer", etc.). For instance, if a FLOSS solution came forward that looked
> to be good and close enough to what would be a good workflow along with
> support commitments from the infrastructure team and folks to maintain the
> code -- and this will have to people several people as experience with the
> issue tracker has shown -- then that can help tip over the closed-source,
> hosted solution which might have some perks. As for Python over something
> else, that comes into play in open source more from a maintenance
> perspective, but for closed source it would be a tie-breaker only since it
> doesn't exactly influence the usability of the closed-source solution like
> it does an open-source one.
>
> Basically I'm willing to give brownie points for open source and Python
> stuff, but it is just that: points and not deal-breakers.
>
>
> This sounds like a pretty reasonable attitude to take towards this.
>
> If we’re going to be experimenting/talking things over, should I withdraw
> my PEP?
>

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.

Basically a PEP staying in draft is no big deal.
___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Donald Stufft]

> 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 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 use Python, etc. I would like
> >to think I have earned somewhat of a reputation of being level-headed and
> >so none of this should really be a surprise to anyone.
> 
> I think it's equally important to describe what criteria you will use to make
> this decision.  E.g. are you saying all these above points will be completely
> ignored, or all else being equal, they will help tip the balance?
> 
> Considering Guido just gave me this position I have not exactly had a ton of 
> time to think the intricacies out, but they are all positives and can help 
> tip the balance or break ties (I purposely worded all of that with "prefer", 
> etc.). For instance, if a FLOSS solution came forward that looked to be good 
> and close enough to what would be a good workflow along with support 
> commitments from the infrastructure team and folks to maintain the code -- 
> and this will have to people several people as experience with the issue 
> tracker has shown -- then that can help tip over the closed-source, hosted 
> solution which might have some perks. As for Python over something else, that 
> comes into play in open source more from a maintenance perspective, but for 
> closed source it would be a tie-breaker only since it doesn't exactly 
> influence the usability of the closed-source solution like it does an 
> open-source one.
> 
> Basically I'm willing to give brownie points for open source and Python 
> stuff, but it is just that: points and not deal-breakers.

This sounds like a pretty reasonable attitude to take towards this.

If we’re going to be experimenting/talking things over, should I withdraw my 
PEP?

---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA

___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Brett Cannon]

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 out a switch, preferring
> Python-based
> >tools but not viewing it as a negative to not use Python, etc. I would
> like
> >to think I have earned somewhat of a reputation of being level-headed and
> >so none of this should really be a surprise to anyone.
>
> I think it's equally important to describe what criteria you will use to
> make
> this decision.  E.g. are you saying all these above points will be
> completely
> ignored, or all else being equal, they will help tip the balance?
>

Considering Guido just gave me this position I have not exactly had a ton
of time to think the intricacies out, but they are all positives and can
help tip the balance or break ties (I purposely worded all of that with
"prefer", etc.). For instance, if a FLOSS solution came forward that looked
to be good and close enough to what would be a good workflow along with
support commitments from the infrastructure team and folks to maintain the
code -- and this will have to people several people as experience with the
issue tracker has shown -- then that can help tip over the closed-source,
hosted solution which might have some perks. As for Python over something
else, that comes into play in open source more from a maintenance
perspective, but for closed source it would be a tie-breaker only since it
doesn't exactly influence the usability of the closed-source solution like
it does an open-source one.

Basically I'm willing to give brownie points for open source and Python
stuff, but it is just that: points and not deal-breakers.
___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Brett Cannon]

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 matter to me and move on.  As I said, I would moderate
> the
> > conversation to keep it on-task and not waste my time with points that
> have
> > already been made and flagged by me and you as not deal-breakers. And any
> > votes would be to gauge the feeling of the room and not as a binding
> > decision; I assume either me or someone else is going to be the dictator
> on
> > this and this won't be a majority decision.
>
> Can we stop making decisions at summits where it's always the same
> people being present?
>

I already said I'm not going to make a decision there, but you have to
admit having an in-person discussion is a heck of a lot easier than going
back and forth in email and so I'm not willing to rule out at least talking
about the topic at PyCon. I wouldn't hold it against a BDFAP talking about
something at EuroPython and happening to make a decision while there and so
I would expect the same courtesy.

-Brett


>
> Thanks
>
> Antoine.
>
>
> ___
> 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/
> brett%40python.org
>
___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Barry Warsaw]

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 as a negative to not use Python, etc. I would like
>to think I have earned somewhat of a reputation of being level-headed and
>so none of this should really be a surprise to anyone.

I think it's equally important to describe what criteria you will use to make
this decision.  E.g. are you saying all these above points will be completely
ignored, or all else being equal, they will help tip the balance?

Cheers,
-Barry
___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Antoine Pitrou]

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
> conversation to keep it on-task and not waste my time with points that have
> already been made and flagged by me and you as not deal-breakers. And any
> votes would be to gauge the feeling of the room and not as a binding
> decision; I assume either me or someone else is going to be the dictator on
> this and this won't be a majority decision.

Can we stop making decisions at summits where it's always the same
people being present?

Thanks

Antoine.


___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Guido van Rossum]

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. not-free,
>> "loyalty" to free or open tools, the weighing of core committers'
>> preferences vs. outside contributors' preferences, GitHub's diversity track
>> record, with no new information added. Even if we *just* had a vote by
>> show-of-hands at the summit that would just upset those who couldn't be
>> present.
>>
>
> 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 use Python, etc. I would like
> to think I have earned somewhat of a reputation of being level-headed and
> so none of this should really be a surprise to anyone.
>
> 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
> conversation to keep it on-task and not waste my time with points that have
> already been made and flagged by me and you as not deal-breakers. And any
> votes would be to gauge the feeling of the room and not as a binding
> decision; I assume either me or someone else is going to be the dictator on
> this and this won't be a majority decision.
>
>
>>
>> But I'll leave that up to you. The only thing I ask you is not to give me
>> the last word. I might just do something you regret. :-)
>>
>
> What about me doing something that *I* regret like taking this on? =)
>

I trust you more than myself in this issue, Brett. You'll do fine. I may
just leave the room while it's being discussed.

-- 
--Guido van Rossum (python.org/~guido)
___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Brett Cannon]

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 committers'
> preferences vs. outside contributors' preferences, GitHub's diversity track
> record, with no new information added. Even if we *just* had a vote by
> show-of-hands at the summit that would just upset those who couldn't be
> present.
>

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 use Python, etc. I would like
to think I have earned somewhat of a reputation of being level-headed and
so none of this should really be a surprise to anyone.

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
conversation to keep it on-task and not waste my time with points that have
already been made and flagged by me and you as not deal-breakers. And any
votes would be to gauge the feeling of the room and not as a binding
decision; I assume either me or someone else is going to be the dictator on
this and this won't be a majority decision.


>
> But I'll leave that up to you. The only thing I ask you is not to give me
> the last word. I might just do something you regret. :-)
>

What about me doing something that *I* regret like taking this on? =)

-Brett


>
> --Guido
>
> On Tue, Dec 2, 2014 at 8: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:
>>
>>1. Move to GitHub
>>2. Move to Bitbucket
>>3. Improve our current tooling (either through new hosting setup
>>and/or adding first-world support for downloading PRs from 
>> GitHub/Bitbucket)
>>
>> Regardless of what we do, I think we should graduate the mirrors on
>> GitHub and Bitbucket to "official" -- for the proposed repos and cpython --
>> and get their repos updating per-push instead of as a cron job. I also
>> think we should also flip on any CI we can (e.g. turn on Travis for GitHub
>> along with coveralls support using coverage.py's encodings trick
>> ). This
>> will get us the most accessible repo backups as well as the widest tool
>> coverage for contributors to assist them in their contributions (heck, even
>> if we just get regular coverage reports for Python that would be a great
>> win out of all of this).
>>
>> Now as for whether we should move the repos, I see two possibilities to
>> help make that decision. One is we end up with 3 PEPs corresponding to the
>> 3 proposals outlined above, get them done before PyCon, and then we have a
>> discussion at the language summit where we can either make a decision or
>> see what the pulse at the conference and sprints then make a decision
>> shortly thereafter (I can moderate the summit discussion to keep this
>> on-task and minimize the rambling; if Guido wants I can even make the final
>> call since I have already played the role of "villain" for our issue
>> tracker and hg decisions).
>>
>> The other option is we take each one of the 3 proposed repos and
>> pilot/experiment with them on a different platform. I would put peps on
>> GitHub (as per Guido's comment of getting PRs from there already), the
>> devguide on Bitbucket, and leave devinabox on hg.python.org but with the
>> motivation of getting better tooling in place to contribute to it. We can
>> then see if anything changes between now and PyCon and then discuss what
>> occurred there (if we can't get the word out about this experiment and get
>> new tooling up and going on the issue tracker in the next 4 months then
>> that's another data point about how much people do/don't care about any of
>> this). Obviously if we end up needing more time we don't *have* to make
>> a decision at PyCon, but it's a good goal to have. I don't think we can
>> cleanly replicate a single repo on all three solutions as I sure don't want
>> to deal with that merging fun (unless someone comes forward to be basically
>> a "release manager" for one of the repos to make that experiment happen).
>>
>> So do people want PEPs or experimentation first?
>>
>> On Tue Dec 02 2014 at 8:24:16 AM Nick Coghlan  wrote:
>>
>>> 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 Enterpr

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

[Guido van Rossum]

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's diversity track
record, with no new information added. Even if we *just* had a vote by
show-of-hands at the summit that would just upset those who couldn't be
present.

But I'll leave that up to you. The only thing I ask you is not to give me
the last word. I might just do something you regret. :-)

--Guido

On Tue, Dec 2, 2014 at 8: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:
>
>1. Move to GitHub
>2. Move to Bitbucket
>3. Improve our current tooling (either through new hosting setup
>and/or adding first-world support for downloading PRs from 
> GitHub/Bitbucket)
>
> Regardless of what we do, I think we should graduate the mirrors on GitHub
> and Bitbucket to "official" -- for the proposed repos and cpython -- and
> get their repos updating per-push instead of as a cron job. I also think we
> should also flip on any CI we can (e.g. turn on Travis for GitHub along
> with coveralls support using coverage.py's encodings trick
> ). This
> will get us the most accessible repo backups as well as the widest tool
> coverage for contributors to assist them in their contributions (heck, even
> if we just get regular coverage reports for Python that would be a great
> win out of all of this).
>
> Now as for whether we should move the repos, I see two possibilities to
> help make that decision. One is we end up with 3 PEPs corresponding to the
> 3 proposals outlined above, get them done before PyCon, and then we have a
> discussion at the language summit where we can either make a decision or
> see what the pulse at the conference and sprints then make a decision
> shortly thereafter (I can moderate the summit discussion to keep this
> on-task and minimize the rambling; if Guido wants I can even make the final
> call since I have already played the role of "villain" for our issue
> tracker and hg decisions).
>
> The other option is we take each one of the 3 proposed repos and
> pilot/experiment with them on a different platform. I would put peps on
> GitHub (as per Guido's comment of getting PRs from there already), the
> devguide on Bitbucket, and leave devinabox on hg.python.org but with the
> motivation of getting better tooling in place to contribute to it. We can
> then see if anything changes between now and PyCon and then discuss what
> occurred there (if we can't get the word out about this experiment and get
> new tooling up and going on the issue tracker in the next 4 months then
> that's another data point about how much people do/don't care about any of
> this). Obviously if we end up needing more time we don't *have* to make a
> decision at PyCon, but it's a good goal to have. I don't think we can
> cleanly replicate a single repo on all three solutions as I sure don't want
> to deal with that merging fun (unless someone comes forward to be basically
> a "release manager" for one of the repos to make that experiment happen).
>
> So do people want PEPs or experimentation first?
>
> On Tue Dec 02 2014 at 8:24:16 AM Nick Coghlan  wrote:
>
>> 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 of Kallithea. I'll be
>> talking to them tomorrow, and if that discussion goes well, will
>> update PEP 474 (and potentially PEP 462) accordingly.
>>
>> Given that that would take away the "volunteer supported" vs
>> "commercially supported" distinction between self-hosting and using
>> GitHub (as well as potentially building a useful relationship that may
>> help us resolve other workflow issues in the future), I'd like us to
>> hold off on any significant decisions regarding the fate of any of the
>> repos until I've had a chance to incorporate the results of that
>> discussion into my proposals.
>>
>> As described in PEP 474, I'm aware of the Mercurial team's concerns
>> with RhodeCode's current licensing, but still consider it a superior
>> alternative to an outright proprietary solution that doesn't get us
>> any closer to solving the workflow problems with the main CPython
>> repo.
>>
>> Regards,
>> Nick.
>>
>> 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
>> 

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

[Demian Brecht]

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.
___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Tres Seaver]

-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.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAlR99X8ACgkQ+gerLs4ltQ7dpACgsGq7Rii7seJXHCOVMUymbOdL
2KQAn3qcOGWynKU4rd/H39hpBxwSsbk9
=93kJ
-END PGP SIGNATURE-

___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Brett Cannon]

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/or
   adding first-world support for downloading PRs from GitHub/Bitbucket)

Regardless of what we do, I think we should graduate the mirrors on GitHub
and Bitbucket to "official" -- for the proposed repos and cpython -- and
get their repos updating per-push instead of as a cron job. I also think we
should also flip on any CI we can (e.g. turn on Travis for GitHub along
with coveralls support using coverage.py's encodings trick
). This will
get us the most accessible repo backups as well as the widest tool coverage
for contributors to assist them in their contributions (heck, even if we
just get regular coverage reports for Python that would be a great win out
of all of this).

Now as for whether we should move the repos, I see two possibilities to
help make that decision. One is we end up with 3 PEPs corresponding to the
3 proposals outlined above, get them done before PyCon, and then we have a
discussion at the language summit where we can either make a decision or
see what the pulse at the conference and sprints then make a decision
shortly thereafter (I can moderate the summit discussion to keep this
on-task and minimize the rambling; if Guido wants I can even make the final
call since I have already played the role of "villain" for our issue
tracker and hg decisions).

The other option is we take each one of the 3 proposed repos and
pilot/experiment with them on a different platform. I would put peps on
GitHub (as per Guido's comment of getting PRs from there already), the
devguide on Bitbucket, and leave devinabox on hg.python.org but with the
motivation of getting better tooling in place to contribute to it. We can
then see if anything changes between now and PyCon and then discuss what
occurred there (if we can't get the word out about this experiment and get
new tooling up and going on the issue tracker in the next 4 months then
that's another data point about how much people do/don't care about any of
this). Obviously if we end up needing more time we don't *have* to make a
decision at PyCon, but it's a good goal to have. I don't think we can
cleanly replicate a single repo on all three solutions as I sure don't want
to deal with that merging fun (unless someone comes forward to be basically
a "release manager" for one of the repos to make that experiment happen).

So do people want PEPs or experimentation first?

On Tue Dec 02 2014 at 8:24:16 AM Nick Coghlan  wrote:

> 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 of Kallithea. I'll be
> talking to them tomorrow, and if that discussion goes well, will
> update PEP 474 (and potentially PEP 462) accordingly.
>
> Given that that would take away the "volunteer supported" vs
> "commercially supported" distinction between self-hosting and using
> GitHub (as well as potentially building a useful relationship that may
> help us resolve other workflow issues in the future), I'd like us to
> hold off on any significant decisions regarding the fate of any of the
> repos until I've had a chance to incorporate the results of that
> discussion into my proposals.
>
> As described in PEP 474, I'm aware of the Mercurial team's concerns
> with RhodeCode's current licensing, but still consider it a superior
> alternative to an outright proprietary solution that doesn't get us
> any closer to solving the workflow problems with the main CPython
> repo.
>
> Regards,
> Nick.
>
> 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.
>
> --
> Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
>
___
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-checkins] cpython (3.4): - Issue #22966: Fix __pycache__ pyc file name clobber when pyc_compile is

[Barry Warsaw]

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
that should fix it.  This passes for me on Ubuntu, but I don't have a Windows
machine to do a test build on atm, so I'll just commit this and see how the
buildbots handle it.

diff -r 8badbd65840e Lib/test/test_py_compile.py
--- a/Lib/test/test_py_compile.py   Tue Dec 02 09:24:06 2014 +0200
+++ b/Lib/test/test_py_compile.py   Tue Dec 02 11:27:16 2014 -0500
@@ -106,9 +106,13 @@
 weird_path = os.path.join(self.directory, 'foo.bar.py')
 cache_path = importlib.util.cache_from_source(weird_path)
 pyc_path = weird_path + 'c'
+head, tail = os.path.split(cache_path)
+penultimate_tail = os.path.basename(head)
 self.assertEqual(
-'/'.join(cache_path.split('/')[-2:]),
-'__pycache__/foo.bar.{}.pyc'.format(sys.implementation.cache_tag))
+os.path.join(penultimate_tail, tail),
+os.path.join(
+'__pycache__',
+'foo.bar.{}.pyc'.format(sys.implementation.cache_tag)))
 with open(weird_path, 'w') as file:
 file.write('x = 123\n')
 py_compile.compile(weird_path)


signature.asc
Description: PGP signature
___
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-checkins] cpython (3.4): - Issue #22966: Fix __pycache__ pyc file name clobber when pyc_compile is

[Jeremy Kloth]

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_compile.py
> --- a/Lib/test/test_py_compile.py
> +++ b/Lib/test/test_py_compile.py
> @@ -99,5 +99,21 @@
>  self.assertFalse(os.path.exists(
>  importlib.util.cache_from_source(bad_coding)))
>
> +def test_double_dot_no_clobber(self):
> +# http://bugs.python.org/issue22966
> +# py_compile foo.bar.py -> __pycache__/foo.cpython-34.pyc
> +weird_path = os.path.join(self.directory, 'foo.bar.py')
> +cache_path = importlib.util.cache_from_source(weird_path)
> +pyc_path = weird_path + 'c'
> +self.assertEqual(
> +'/'.join(cache_path.split('/')[-2:]),
> +'__pycache__/foo.bar.cpython-34.pyc')
> +with open(weird_path, 'w') as file:
> +file.write('x = 123\n')
> +py_compile.compile(weird_path)
> +self.assertTrue(os.path.exists(cache_path))
> +self.assertFalse(os.path.exists(pyc_path))
> +
> +

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.

-- 
Jeremy Kloth
___
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 481 - Migrate Some Supporting Repositories to Git and Github

[Nick Coghlan]

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 of Kallithea. I'll be
talking to them tomorrow, and if that discussion goes well, will
update PEP 474 (and potentially PEP 462) accordingly.

Given that that would take away the "volunteer supported" vs
"commercially supported" distinction between self-hosting and using
GitHub (as well as potentially building a useful relationship that may
help us resolve other workflow issues in the future), I'd like us to
hold off on any significant decisions regarding the fate of any of the
repos until I've had a chance to incorporate the results of that
discussion into my proposals.

As described in PEP 474, I'm aware of the Mercurial team's concerns
with RhodeCode's current licensing, but still consider it a superior
alternative to an outright proprietary solution that doesn't get us
any closer to solving the workflow problems with the main CPython
repo.

Regards,
Nick.

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.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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] advice needed: best approach to enabling "metamodules"?

[Antoine Pitrou]

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 if you e.g. allowed "[].__class__ = dict").
> Currently the rules (spread across object_set_class and
> compatible_for_assignment) are:
> 
> (1) both oldto and newto have to be heap types
> (2) they have to have the same tp_dealloc
> (3) they have to have the same tp_free
> (4) if you walk up the ->tp_base chain for both types until you find
> the most-ancestral type that has a compatible struct layout (as
> checked by equiv_structs), then either
>(4a) these ancestral types have to be the same, OR
>(4b) these ancestral types have to have the same tp_base, AND they
> have to have added the same slots on top of that tp_base (e.g. if you
> have class A(object): pass and class B(object): pass then they'll both
> have added a __dict__ slot at the same point in the instance struct,
> so that's fine; this is checked in same_slots_added).
> 
> The only place the code assumes that it is dealing with heap types is
> in (4b)

I'm not sure. Many operations are standardized on heap types that can
have arbitrary definitions on static types (I'm talking about the tp_
methods). You'd have to review them to double check.

For example, a heap type's tp_new increments the type's refcount, so
you have to adjust the instance refcount if you cast it from a non-heap
type to a heap type, and vice-versa (see slot_tp_new()).

(this raises the interesting question "what happens if you assign to
__class__ from a __del__ method?")

> -- same_slots_added unconditionally casts the ancestral types
> to (PyHeapTypeObject*). AFAICT that's why step (1) is there, to
> protect this code. But I don't think the check actually works -- step
> (1) checks that the types we're trying to assign are heap types, but
> this is no guarantee that the *ancestral* types will be heap types.
> [Also, the code for __bases__ assignment appears to also call into
> this code with no heap type checks at all.] E.g., I think if you do
> 
> class MyList(list):
> __slots__ = ()
> 
> class MyDict(dict):
> __slots__ = ()
> 
> MyList().__class__ = MyDict()
> 
> then you'll end up in same_slots_added casting PyDict_Type and
> PyList_Type to PyHeapTypeObjects and then following invalid pointers
> into la-la land. (The __slots__ = () is to maintain layout
> compatibility with the base types; if you find builtin types that
> already have __dict__ and weaklist and HAVE_GC then this example
> should still work even with perfectly empty subclasses.)
> 
> Okay, so suppose we move the heap type check (step 1) down into
> same_slots_added (step 4b), since AFAICT this is actually more correct
> anyway. This is almost enough to enable __class__ assignment on
> modules, because the cases we care about will go through the (4a)
> branch rather than (4b), so the heap type thing is irrelevant.
> 
> The remaining problem is the requirement that both types have the same
> tp_dealloc (step 2). ModuleType itself has tp_dealloc ==
> module_dealloc, while all(?) heap types have tp_dealloc ==
> subtype_dealloc. Here again, though, I'm not sure what purpose this
> check serves. subtype_dealloc basically cleans up extra slots, and
> then calls the base class tp_dealloc. So AFAICT it's totally fine if
> oldto->tp_dealloc == module_dealloc, and newto->tp_dealloc ==
> subtype_dealloc, so long as newto is a subtype of oldto -- b/c this
> means newto->tp_dealloc will end up calling oldto->tp_dealloc anyway.
> OTOH it's not actually a guarantee of anything useful to see that
> oldto->tp_dealloc == newto->tp_dealloc == subtype_dealloc, because
> subtype_dealloc does totally different things depending on the
> ancestry tree -- MyList and MyDict above pass the tp_dealloc check,
> even though list.tp_dealloc and dict.tp_dealloc are definitely *not*
> interchangeable.
> 
> So I suspect that a more correct way to do this check would be something like
> 
> PyTypeObject *old__real_deallocer = oldto, *new_real_deallocer = newto;
> while (old_real_deallocer->tp_dealloc == subtype_dealloc)
> old_real_deallocer = old_real_deallocer->tp_base;
> while (new_real_deallocer->tp_dealloc == subtype_dealloc)
> new_real_deallocer = new_real_deallocer->tp_base;
> if (old_real_deallocer->tp_dealloc != new_real_deallocer)
> error out;

Sounds good.

> Module subclasses would pass this check. Alternatively it might make
> more sense to add a check in equiv_structs that
> (child_type->tp_dealloc == subtype_dealloc || child_type->tp_dealloc
> == parent_type->tp_dealloc); I think that would accomplish the same
> thing in a somewhat cleaner way.

There's no "child" and "parent" types in equiv_structs().

Regards

Antoine.


___
Python-Dev mailing list
Python-Dev@py