Re: [Python-Dev] Semi-official read-only Github mirror of the CPython Mercurial repository
Just a quick update on this. I've finally found time to set up a VPS at DigitalOcean of myself, and I'm moving the cronjob for updating the Github mirrors to it. This lets me ramp up the update frequency. For now I'll set it to every 4 hours, but in the future I may make it even more frequent. Hopefully this will not overrun my bandwidth allocation :) The CPython mirror (https://github.com/python/cpython) has been pretty popular so far, with over 70 forks. Eli On Mon, Sep 30, 2013 at 6:09 AM, Eli Bendersky wrote: > Hi all, > > https://github.com/python/cpython is now live as a semi-official, *read > only* Github mirror of the CPython Mercurial repository. Let me know if you > have any problems/concerns. > > I still haven't decided how often to update it (considering either just N > times a day, or maybe use a Hg hook for batching). Suggestions are welcome. > > The methodology I used to create it is via hg-fast-export. I also tried to > pack and gc the git repo as much as possible before the initial Github push > - it went down from almost ~2GB to ~200MB (so this is the size of a fresh > clone right now). > > Eli > > P.S. thanks Jesse for the keys to https://github.com/python > > > > ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Updates to PEP 471, the os.scandir() proposal
On 11 Jul 2014 12:46, "Ben Hoyt" wrote: > > [replying to python-dev this time] > > >> The "onerror" approach can also deal with readdir failing, which the > >> PEP currently glosses over. > > > > > > Do we want this, though? I can see an error handler for individual entries, > > but if one of the *dir commands fails that would seem to be fairly > > catastrophic. > > Very much agreed that this isn't necessary for just readdir/FindNext > errors. We've never had this level of detail before -- if listdir() > fails half way through (very unlikely) it just bombs with OSError and > you get no entries at all. > > If you really really want this (again very unlikely), you can always > use call next() directly and catch OSError around that call. Agreed - I think the PEP should point this out explicitly, and show that the approach it takes offers a lot of flexibility in error handling from "just let it fail", to a single try/catch around the whole loop, to try/catch just around the operations that might call lstat(), to try/catch around the individual iteration steps. os.walk remains the higher level API that most code should be using, and that has to retain the current listdir based behaviour (any error = ignore all entries in that directory) for backwards compatibility reasons. Cheers, Nick. > > -Ben > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Memory BIO for _ssl
On Mon, Jul 7, 2014 at 1:49 AM, Antoine Pitrou wrote: > Le 05/07/2014 14:04, Geert Jansen a écrit : > >> Since I need this for my Gruvi async framework, I want to volunteer to >> write a patch. It should be useful as well to Py3K's asyncio and other >> async frameworks. It would be good to get some feedback before I start >> on this. > > Thanks for volunteering! This would be a very welcome addition. I have a first patch and submitted it as issue #21965 http://bugs.python.org/issue21965 I've incorporated your feedback. Regards, Geert ___ Python-Dev mailing list [email protected] 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 3121, 384 Refactoring Issues
On 10 Jul 2014 19:59, "Alexander Belopolsky" wrote: > > > On Thu, Jul 10, 2014 at 2:59 PM, Mark Lawrence wrote: >> >> I'm just curious as to why there are 54 open issues after both of these PEPs have been accepted and 384 is listed as finished. Did we hit some unforeseen technical problem which stalled development? > > > I tried to bring some sanity to that effort by opening a "meta issue": > > http://bugs.python.org/issue15787 > > My enthusiasm, however, vanished after I reviewed the refactoring for the datetime module: > > http://bugs.python.org/issue15390 > > My main objections are to following PEP 384 (Stable ABI) within stdlib modules. I see little benefit for the stdlib (which is shipped fresh with every new version of Python) from following those guidelines. The main downside of "do as we say, not as we do" in this case is that we miss out on the feedback loop of what the stable ABI is like to *use*. For example, the docs problem, where it's hard to tell whether an API is part of the stable ABI or not, or the performance problem Stefan mentions. Using the stable ABI for standard library extensions also serves to decouple them further from the internal details of the CPython runtime, making it more likely they will be able to run correctly on alternative interpreters (since emulating or otherwise supporting the limited API is easier than supporting the whole thing). Cheers, Nick. > > ___ > Python-Dev mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com > ___ Python-Dev mailing list [email protected] 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 3121, 384 Refactoring Issues
On Sat, Jul 12, 2014 at 11:19 AM, Nick Coghlan wrote: > The main downside of "do as we say, not as we do" in this case is that we > miss out on the feedback loop of what the stable ABI is like to *use*. I good start for improving the situation would be to convert the extension module templates that we ship with the Python source: http://bugs.python.org/issue15848 (xxsubtype module) http://bugs.python.org/issue15849 (xx module) ___ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
