3.3 ... http://egenix.com/go57
> 2014-07-02: Python Meeting Duesseldorf ... 11 days to go
>
>eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>Registered at Amt
stributions for Windows. Breaking all
of them on 2.7 would be very bad.
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
P
On Jun 23, 2014, at 3:27 PM, M.-A. Lemburg wrote:
> On 23.06.2014 18:09, Donald Stufft wrote:
>>
>> On Jun 23, 2014, at 2:09 AM, Martin v. Löwis wrote:
>>
>>>>
>>>> * Should we make use of the potential breakage with 2.7.10
>>>> t
On Jun 23, 2014, at 4:31 PM, Barry Warsaw wrote:
> On Jun 23, 2014, at 04:20 PM, Donald Stufft wrote:
>
>> At the risk of getting Guido to post his slide again, I still think the
>> solution to the old compiler is to just roll a 2.8 with minimal changes.
>
> No. It&#x
compatibility is kept as long as you’re using an “or later” but
I could be wrong about that. Using binary packages on OSX is a much
less frequent thing I think though since getting a working compiler toolchain
is easier there.
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C
On Jun 23, 2014, at 5:07 PM, M.-A. Lemburg wrote:
> On 23.06.2014 22:20, Donald Stufft wrote:
>>
>> On Jun 23, 2014, at 3:27 PM, M.-A. Lemburg wrote:
>>
>>> On 23.06.2014 18:09, Donald Stufft wrote:
>>>>
>>>> On Jun 23, 2014, at 2:09 AM,
On Jun 23, 2014, at 5:22 PM, Barry Warsaw wrote:
> On Jun 23, 2014, at 05:15 PM, Donald Stufft wrote:
>
>> Normally when I see someone suggest that switching compilers
>> in 2.7.x is likely to be less work than releasing a 2.8 It normally
>> appears to me they haven’t
ufft.io
I’m not sure about this FWIW. I’d have to look at the implementations of
stuff to see how they’d cope with a new thing like that.
-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with Open
infrastructure team) were actually looking earlier about
buildbot.python.org and we’re not entirely sure who "owns" buildbot.python.org.
Unfortunately a lot of the *.python.org services are in a similar state where
there is no clear owner. Generally we've not wanted to just step in and take
ove
lists and like
> strings both at the same time).
>
>
> Raymond
>
>
> P.S. The most important problem in the Python world now is getting
> Python 2 users to adopt Python 3. The core devs need to develop
> a strong distaste for anything that makes that problem ha
ng
bytes(N) is because they were attempting to iterate over a bytes or bytearray
object and they got an integer. I also think that it's bad that this changes
from 2.x to 3.x and I wish it hadn't. However I can't decide if it's worth
reverting this at this time or not.
[
On Sun, Aug 17, 2014, at 09:02 PM, Guido van Rossum wrote:
> On Sun, Aug 17, 2014 at 6:29 AM, Barry Warsaw wrote:
>> On Aug 16, 2014, at 07:43 PM, Guido van Rossum wrote:
>>
>>
>(Don't understand this to mean that we should never deprecate things.
>>
>Deprecations will happen, they are necessa
from __future__ import bytesdoneright? :D
--
Donald Stufft
don...@stufft.io
On Sun, Aug 17, 2014, at 09:40 PM, Antoine Pitrou wrote:
> Le 17/08/2014 20:08, Nick Coghlan a écrit :
> >
> > On 18 Aug 2014 09:57, "Barry Warsaw" > <mailto:ba...@python.org>>
> On Aug 29, 2014, at 4:00 PM, "M.-A. Lemburg" wrote:
>
> * choice of trusted certificate:
>
> Instead of hard wiring using the system CA roots into
> Python it would be good to just make this default and
> permit the user to point Python to a different set of
> CA roots.
>
> This w
r email said, the Python API has everything needed
to easily specify your own CA roots and/or disable the validations.
The OpenSSL library also allows you to specify either a directory
or a file to change the root certificates without code changes. The
only real problems with the APIs are that the de
> On Aug 29, 2014, at 5:42 PM, R. David Murray wrote:
>
> On Fri, 29 Aug 2014 17:11:35 -0400, Donald Stufft wrote:
>> Sorry I was on my phone and didn’t get to fully reply to this.
>>> On Aug 29, 2014, at 4:00 PM, M.-A. Lemburg wrote:
>>>
>>> * confi
> On Aug 29, 2014, at 5:58 PM, M.-A. Lemburg wrote:
>
> On 29.08.2014 23:11, Donald Stufft wrote:
>>
>> Sorry I was on my phone and didn’t get to fully reply to this.
>>
>>> On Aug 29, 2014, at 4:00 PM, M.-A. Lemburg wrote:
>>>
>>&g
nstead of just using HTTP. I'm not saying that
this doesn't happen, just being specific (I'm not actually sure why they would
install a TLS certificate at all if they are trusting perimeter security, but
I'm sure folks do).
-
tem global directory on their
> servers. Users could put them in their own user site directory and even
> each virtual env can have one sslcustomize of its own. It's fully
> backward compatible, doesn't add any flags and developers have the full
> power of Python for configuratio
additional work to *avoid* providing it. Some of
>> them *will* choose that path, but that becomes a matter for discussion
>> between them and their user base, rather than a problem we need to worry
>> about upstream.
>
> FTR, I'm willing to backport the pieces I did
python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/donald%40stufft.io
Or you can just install something with easy_install, or you can drop a .pth
file and monkey patch there. You can’t stop people from
s executed. I don't see
> how sslcustomize is going to make a difference here.
>
Right, this is the point I was trying to make. If you’ve installed a malicious
package it’s game over. There’s nothing Python can do to help you.
---
Donald Stufft
P
ndard library is so
> broken.
>
> I care about the health of the broader Python community, so I will
> passionately argue that this change should be made, but for me personally
> it's a lot easier to justify that everyone should use Twisted (at least since
> 14+) because
s managed by config
management as well as making sure all our services are behind TLS as well.
>
> --
> --Guido van Rossum (python.org/~guido <http://python.org/~guido>)
> ___
> Python-Dev mailing list
> Python-Dev@python.org
> https
his, can’t they write their own 6 line function?
import ssl
import urllib.request
_real_urlopen = urllib.request.urlopen
def _unverified(*args, **kwargs):
if not kwargs.keys() & {“context”, “cafile”, “capath”, “cadefault”}:
ctx = ssl.create_default_context()
ctx.verify_mode = CER
> On Sep 8, 2014, at 6:43 PM, Nick Coghlan wrote:
>
>
> On 9 Sep 2014 08:30, "Donald Stufft" <mailto:don...@stufft.io>> wrote:
> >
> > If someone wants to do this, can’t they write their own 6 line function?
>
> Unfortunately not, as the
;
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
> <https://mail.python.org/mailman/options/python-dev/guido%40python.org>
>
>
>
>
> --
> --Guido van Rossum (python.org/~guido <http://python.org/~guid
n live without
> python2 (and are not Arch :)).
>
> Thanks a lot!
I don’t know for a fact, but I assume that as long as Python 2.x is installed
by default than ``python`` should point to ``python2``. If Python 3.x is the
default version and Python 2.x is the “optional” version than
ld just be ``python``.
All of this assuming of course that 4.0 isn’t a major break like 3.0 and that we
do 4.0 instead of 3.10 as has been suggested.
---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
___
Python-Dev maili
>
> On Sep 19, 2014, at 8:02 PM, Greg Ewing wrote:
>
> Donald Stufft wrote:
>
>> My biggest problem with ``python3``, is what happens after 3.9.
>
> Python2 technically includes 1.x versions as well, so it
> wouldn't be unprecedented for python3 to imply v
dev/peps/pep-0478/
> <http://legacy.python.org/dev/peps/pep-0478/>
>
> Key facts:
> Beta 1 is May 24th 2015, about a month after the end of the PyCon US 2015
> sprints.
> Final release is September 13, 2015, just over a year from now.
>
> Comments?
It says 3.4.0 all thr
_
> Python-Dev mailing list
> Python-Dev@python.org <mailto:Python-Dev@python.org>
> https://mail.python.org/mailman/listinfo/python-dev
> <https://mail.python.org/mailman/listinfo/python-dev>
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/donal
ch
> will help avoid the situation where it's hard to get hold of the right
> compiler...
>
> Top-posted from my Windows Phone
Yea I think it makes incredible sense to aim for it then, even if it makes
things slip.
---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9
3.5 and make it the default in 3.6.
One thing about *nix is even though you can’t write to your normal Python
install location without root, invoking pip with permissions (assuming you have
them) is as easy as prefacing it with ``sudo`` in most cases. Does Windows have
an equivalent or do you need
user
> site-packages is just another site-packages directory.
>
Broken like the prefix problem :)
Basically people have Python in a ton of different configurations and it’s
hard to figure out if —user will work out of the box in all of them or not.
---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A
> On Sep 25, 2014, at 11:54 AM, Paul Moore wrote:
>
> On 25 September 2014 16:43, Donald Stufft wrote:
>> Basically people have Python in a ton of different configurations and it’s
>> hard to figure out if —user will work out of the box in all of them or not.
>
&
> On Sep 25, 2014, at 6:44 PM, Chris Barker wrote:
>
> On Thu, Sep 25, 2014 at 9:00 AM, Donald Stufft <mailto:don...@stufft.io>> wrote:
> 1) Just always default to —user and add a —system or similar flag, this
> is super easy to change but is a backwards incompatibl
> On Sep 26, 2014, at 3:09 AM, Paul Moore wrote:
>
> On 26 September 2014 01:38, Donald Stufft wrote:
>> Either way I'm fairly commited to making --user the default, the only
>> question
>> on my mind is what exactly does that look like (e.g. does root get --use
> On Sep 26, 2014, at 9:53 AM, Paul Moore wrote:
>
> On 26 September 2014 14:31, Donald Stufft wrote:
>> Yea, I think we throw an error when you use —user inside a virtual
>>environment.
>
> So if --user became the default, what would happen? I'd like pip
Awesome!
> On Sep 26, 2014, at 2:01 PM, Steve Dower wrote:
>
> Hi all,
>
> (This is advance notice since people on this list will be interested.
> Official announcements are coming when setuptools makes their next release.)
>
> Microsoft has released a compiler package targeting Python 2.7 (
o that it would install
pip3, and pip3.4, but *not* pip if it was an "install", and only pip3.4 if it
was an "alt install".
My question is, does this behavior make sense for ensurepip in 2.7? Or should
it also install the "pip" command if it is an "install"
e (alt)install targets of Python's own Makefile, and I
> think those are exactly right.
>
> On Oct 3, 2014 3:07 PM, "Donald Stufft" <mailto:don...@stufft.io>> wrote:
> I'm working on the backport of ensurepip to Python 2.7, and I realized that
> I'
Whoops, I misred.
So to be clear, you think:
install -> pip, pip2, pip2.7
altinstall -> pip2.7
> On Oct 3, 2014, at 8:46 PM, Guido van Rossum wrote:
>
> That's not what I meant. Python 2.7 does install "python" unless you use
> altinstall.
>
>
sed to be a single file and from before
we dropped support for Pythons that didn’t support python -m. It’s probably
nonsense cruft that’s just been left over and hadn’t been managed to be deleted
now.
---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
__
> On Oct 8, 2014, at 3:36 PM, Wes Turner wrote:
>
>
> On Oct 8, 2014 7:20 AM, "Donald Stufft" <mailto:don...@stufft.io>> wrote:
> >
> >
> > > On Oct 8, 2014, at 6:16 AM, Christian Tismer > > <mailto:tis...@stackless.com>> wro
d something on them, and then shut them down as long as there’s some way to
automate logging into a Windows box and running some commands… Normally I’d do
this with SSH but I don’t know if Windows has anything like that.
IOW we can totally spin up preconfigured VMs for a Windows build service.
---
].
[1]
http://googleonlinesecurity.blogspot.com/2014/10/this-poodle-bites-exploiting-ssl-30.html
[2] https://www.openssl.org/~bodo/ssl-poodle.pdf
---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
___
Python-Dev mailing list
Python
I'm on my phone but docs is served via fastly. Issues could be POP specific.
> On Oct 20, 2014, at 7:38 PM, Oleg Broytman wrote:
>
>> On Tue, Oct 21, 2014 at 12:29:45AM +0100, MRAB
>> wrote:
>>> On 2014-10-21 00:09, Eli Bendersky wrote:
>>>
>>> On Mon, Oct 20, 2014 at 1:01 PM, Terry Reedy >
Is this using HTTPS or SSH.
> On Oct 24, 2014, at 11:47 PM, David Bolen wrote:
>
> Starting yesterday, my XP buildbot began failing to execute clone
> operations against hg.python.org. There's not a lot of data being
> given aside from a transaction abort message (and my buildbot log
> showing
What version of OpenSSL is it using.
> On Oct 25, 2014, at 1:00 AM, David Bolen wrote:
>
> David Bolen writes:
>
>> which appears to die mid-stream while receiving the manifests.
>>
>> So I'm sort of hoping there might be some record server-side as to why
>> things are falling apart mid-way.
I have an idea, can you run https://bpaste.net/show/c5d7cd102f5b and
tell me what it outputs? Both on a machine that works and one that
doesn’t.
> On Oct 25, 2014, at 2:14 AM, David Bolen wrote:
>
> Donald Stufft writes:
>
>> What version of OpenSSL is it using.
>
>
ry releases, I think the
> release cycles are slow enough that most users would only notice that "pip
> install numpy" now works.
For the record, a long term “down the road” kind of thing I want to do is have
PyPI have a build farm which can build Wheels. So that people upload a
up.
>
It appears to be a package manager manager. Chocolatey is one of the third
party package managers available on Windows.
I also just learned that OneGet is apparently OSS and developed on github
(https://github.com/OneGet/oneget <https://github.com/OneGet/oneget>).
---
Don
This sounds like something good for packaging.python.org
> On Oct 29, 2014, at 4:05 PM, Paul Moore wrote:
>
> On 29 October 2014 15:31, Nathaniel Smith wrote:
>>> You can use Express editions of Visual Studio.
>>
>> IIUC, the express edition compilers are 32-bit only, and what you actually
>>
> On Oct 29, 2014, at 6:09 PM, Paul Moore wrote:
>
> On 29 October 2014 20:26, Donald Stufft wrote:
>> This sounds like something good for packaging.python.org
>
> Yeah, I wondered about that. I'll work up a patch for that. But the
> more I think about it, it real
body else's
> package. Is that last command sufficient to prepare one's own wheel for
> uploading to PyPI, or there something else to do?
>
Generally for uploading to PyPI you do ``python setup.py bdist_wheel``, though
I don’t
large changes, having multiple rcs is not
> unlikely. Hopefully, we can get a final out by 2015, though.
Yes on PEP 477, the actual back porting is done, I’m just slacking on doing
the tests because we used unittest.mock in 3.4.
---
Donald Stufft
PGP: 7C6B 7C5D 5
> On Nov 1, 2014, at 8:05 AM, Nick Coghlan wrote:
>
> On 1 November 2014 09:59, Donald Stufft wrote:
>>
>>> On Oct 31, 2014, at 7:54 PM, Benjamin Peterson wrote:
>>>
>>> I'm updating the 2.7 release PEP with the following release dates
>
list
> Python-Dev@python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/donald%40stufft.io
The internet suggests trying hg verify, does that do anything?
---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C
vorite host site of Github :/. Something like Github Enterprise
or Atlassian stash which are able to be migrated away from are better in this
regards.
Ironically we do use a propetiary/closed-source/hosted solution for
https://status.python.org/ but it’s not terribly difficult to migr
StopIteration does escape that shouldn't have?
>
I don’t have an opinion on whether it’s enough of a big deal to actually change
it, but I do find wrapping it with a try: except block and returning easier
to understand. If you showed me the current code unless I really thought about
it I wo
and it is pretty awesome.
There are self hosted options that offer similar things (often times not quite
as
good in the ease of use though they might be more featureful in other areas).
Mostly what I’m trying to say is that documenting a field that essentially
requires
the end user to not only fig
> On Nov 21, 2014, at 3:59 PM, Ned Deily wrote:
>
> In article <19336614-0e4f-42bf-a918-1807bb7f3...@stufft.io>,
> Donald Stufft wrote:
> [...]
>> Well you can’t document your way out of a bad UX. The thing you’re
>> competing with (on Github at least) is:
&
> On Nov 22, 2014, at 9:59 AM, Nick Coghlan wrote:
>
>
> On 22 Nov 2014 07:37, "Donald Stufft" <mailto:don...@stufft.io>> wrote:
> > > On Nov 21, 2014, at 3:59 PM, Ned Deily > > <mailto:n...@acm.org>> wrote:
> > > Sure, I
> On Nov 23, 2014, at 12:19 AM, Guido van Rossum wrote:
>
> This thread seems to beg for a decision. I think Donald Stufft has it exactly
> right: we should move to GitHub, because it is the easiest to use and most
> contributors already know it (or are eager to learn thee)
> On Nov 23, 2014, at 12:59 AM, Nick Coghlan wrote:
>
> On 23 November 2014 at 15:19, Guido van Rossum wrote:
>> This thread seems to beg for a decision. I think Donald Stufft has it
>> exactly right: we should move to GitHub, because it is the easiest to use
>> an
> On Nov 23, 2014, at 1:03 AM, Donald Stufft wrote:
>
>>
>> On Nov 23, 2014, at 12:59 AM, Nick Coghlan wrote:
>>
>> On 23 November 2014 at 15:19, Guido van Rossum wrote:
>>> This thread seems to beg for a decision. I think Donald Stufft has it
>
> On Nov 23, 2014, at 1:25 AM, Nick Coghlan wrote:
>
> On 23 November 2014 at 16:03, Donald Stufft wrote:
>>> On Nov 23, 2014, at 12:59 AM, Nick Coghlan wrote:
>>>
>>> Note that if folks prefer Git, BitBucket supports both. I would object
>>&
rs to external contribution, both without alienating existing
> contributors by forcing them to change their workflows.
>
> Proposing to *also* switch from Mercurial to git significantly
> increases the cost of the change, while providing minimal incremental
> benefit.
>
> Regards
> On Nov 23, 2014, at 2:01 AM, Nick Coghlan wrote:
>
> On 23 November 2014 at 16:27, Donald Stufft wrote:
>>> On Nov 23, 2014, at 1:25 AM, Nick Coghlan wrote:
>>> By contrast, proposals to switch from Mercurial to Git impose a
>>> *massive* burden on cont
> On Nov 23, 2014, at 2:35 AM, Nick Coghlan wrote:
>
> On 23 November 2014 at 17:14, Donald Stufft wrote:
>>> On Nov 23, 2014, at 2:01 AM, Nick Coghlan wrote:
>>> Travis isn't the only CI system on the internet, and for pure Sphinx
>>> documentation
k
> would be necessary to update our infrastructure for either Bitbucket or
> GitHub we can't really have a reasonable discussion that isn't going to be
> full of guessing.
>
> And I'm still in support no matter what of breaking out the HOW
t
degrades into the same terrible UX that *every* patch has to go through on
a hg.python.org repository right now.
---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.pyt
> On Nov 23, 2014, at 4:08 PM, Georg Brandl wrote:
>
> On 11/23/2014 09:38 PM, Donald Stufft wrote:
>>
>>> On Nov 23, 2014, at 3:03 PM, Georg Brandl wrote:
>>>
>>> The next point is that there is no easy way to change the target branch of
>>&g
but probably still better than what we have now) OSS software that gives
you a github like flow. The only *data* that is really in there is what’s
stored in the repository itself (since I don’t think for anything major
we’d ever put issues there or use the wiki) which is trivial to move around.
---
downsides
> too, and needs to promote its specific benefits separately from the
> benefits of Git.
>
In many cases Github is git’s killer feature which is why you see a lot
of people equate the two. It’s not unusual to see a project switch away
> On Nov 24, 2014, at 7:09 AM, Nick Coghlan wrote:
>
> On 24 November 2014 at 22:01, Donald Stufft wrote:
>>> On Nov 24, 2014, at 6:44 AM, Ben Finney wrote:
>>> No, I'm not offering to write such a PEP either. I'm requesting that we
>>> recogni
> On Nov 24, 2014, at 4:12 AM, Nick Coghlan wrote:
>
>
> On 24 Nov 2014 10:41, "Donald Stufft" <mailto:don...@stufft.io>> wrote:
> >
> >
> > > On Nov 23, 2014, at 6:57 PM, Steven D'Aprano > > <mailto:st...@pearwood.info>>
mmunity is primarily
there as well.
>
>> At least for me, until we get a clear understanding of what workflow changes
>> we are asking for both contributors and core developers and exactly what
>> work would be necessary to update our infrastructure for either Bitbucket
but being a PSF sponsor
> should not play into it in the slightest, else it's like buying influence.
Agreed here too (even then, Github has been a PyCon sponsor for awhile and has
even ran their own Python conference in the past). I think it’s kind of shitty
to reject and demean someo
> On Nov 24, 2014, at 2:25 AM, Nick Coghlan wrote:
>
> Are you volunteering to write a competing PEP for a migration to git and
> GitHub?
If nobody steps up to do this (and another PEP isn’t accepted before then) I can
likely write something up over the upcoming holiday.
---
D
ATM, so I'm
> > willing to entertain moving to GitHub or Bitbucket or whatever to improve
> > our situation.
>
> It may not have been Guido's intention, but his proposal to undercut the
> entire Python based version control tooling ecosystem by deeming it entirely
> On Nov 24, 2014, at 3:48 PM, Nick Coghlan wrote:
>
>
> On 25 Nov 2014 06:25, "Donald Stufft" <mailto:don...@stufft.io>> wrote:
> >
> >
> >> On Nov 24, 2014, at 2:55 PM, Nick Coghlan >> <mailto:ncogh...@gmail.com>> wrote:
&g
> On Nov 24, 2014, at 8:59 PM, Ethan Furman wrote:
>
> On 11/24/2014 08:36 AM, Donald Stufft wrote:
>> On Nov 24, 2014, at 11:28 AM, Brett Cannon wrote:
>>>
>>> This might be a little controversial, but the PSF's mission should not
>>> influenc
> On Nov 24, 2014, at 9:37 PM, Ethan Furman wrote:
>
> On 11/24/2014 06:27 PM, Donald Stufft wrote:
>> On Nov 24, 2014, at 8:59 PM, Ethan Furman wrote:
>>>
>>> It is sounding to me like GitHub is not, itself, an open solution, even
>>> though
>>
://www.openhub.net/repositories/compare>`
.. [#hg-git] `hg-git <https://hg-git.github.io/>`
.. [#travisci] `Travis CI <https://travis-ci.org/>`
---
Donald Stufft
PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
___
Python-Dev mai
> On Nov 29, 2014, at 6:27 PM, Donald Stufft wrote:
>
> [lots of words]
Just FYI, I’ve pushed an update to the PEP. Nothing major just some grammatical
fixes and such. The revision is here:
https://hg.python.org/peps/rev/6c6947dbd13f
For whatever it's worth, the person who
> On Nov 29, 2014, at 7:15 PM, Alex Gaynor wrote:
>
> Donald Stufft stufft.io> writes:
>
>>
>> [words words words]
>>
>
> I strongly support this PEP. I'd like to share two pieces of information. Both
> of these are personal anecdote
makes it much more attractive to learn the tooling since the hypothetical
person would be able to take that knowledge and apply it elsewhere.
It is my experience, and this entirely ancedotal, that it's far easier to get
reviews from non-committers and committers alike on projects which are ho
> On Nov 29, 2014, at 8:12 PM, Nick Coghlan wrote:
>
>
> On 30 Nov 2014 09:28, "Donald Stufft" <mailto:don...@stufft.io>> wrote:
> >
> > As promised in the "Move selected documentation repos to PSF BitBucket
> > account?" thread
> On Nov 29, 2014, at 9:01 PM, Donald Stufft wrote:
>
>>
>> The PEP should also cover providing clear instructions for setting up
>> git-remote-hg with the remaining Mercurial repos (most notably CPython), as
>> well as documenting a supported workflow for g
> On Nov 30, 2014, at 12:06 AM, Ben Finney wrote:
>
> Nick Coghlan writes:
>
>> 1. I strongly believe that the long term sustainability of the overall
>> open source community requires the availability and use of open source
>> infrastructure.
>
> I concur. This article http://mako.cc/writing
> On Nov 30, 2014, at 7:31 AM, Paul Moore wrote:
>
> On 29 November 2014 at 23:27, Donald Stufft wrote:
>> In previous years there was concern about how well supported git was on
>> Windows
>> in comparison to Mercurial. However git has grown to support Windows as a
> On Nov 30, 2014, at 2:08 AM, Larry Hastings wrote:
>
>
> On 11/29/2014 04:37 PM, Donald Stufft wrote:
>> On Nov 29, 2014, at 7:15 PM, Alex Gaynor
>> <mailto:alex.gay...@gmail.com> wrote:
>>> Despite being a regular hg
>>> user for years, I ha
> On Nov 30, 2014, at 6:18 AM, Ben Finney wrote:
>
> Donald Stufft writes:
>
>> I think there is a big difference here between using a closed source
>> VCS or compiler and using a closed source code host. Namely in that
>> the protocol is defined by git so swit
> On Nov 30, 2014, at 11:28 AM, Brett Cannon wrote:
>
>
>
> On Sat Nov 29 2014 at 7:16:34 PM Alex Gaynor <mailto:alex.gay...@gmail.com>> wrote:
> Donald Stufft stufft.io <http://stufft.io/>> writes:
>
> >
> > [words words words]
> >
ut there, or that if they are already contributing to
those other Python projects they are probably aware of this particular
toolchain and workflow and can apply that knowledge directly to the Python
project.
Moving to some of these tools happens to come with it features like really nice
CI integr
ject.
> ___
> 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/donald%40stufft.io
---
Donald Stufft
PGP: 7C6B 7C5D 5
> On Nov 30, 2014, at 12:09 PM, Donald Stufft wrote:
>
>>
>> On Nov 30, 2014, at 11:55 AM, Barry Warsaw wrote:
>>
>> On Nov 30, 2014, at 09:54 AM, Ian Cordasco wrote:
>>
>>> - Migrating "data" from GitHub is easy. There are free-as-in-f
> On Nov 30, 2014, at 11:30 AM, Donald Stufft wrote:
>
> Comments like this make me feel like I didn’t explain myself very well in the
> PEP.
It’s been pointed out to me that Mercurial bookmarks have been core since 1.8
and since I felt like the technical arguments were really
1 - 100 of 497 matches
Mail list logo
