Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered
On 13 September 2016 at 12:37, Tim Delaney wrote: > Personally I expect all Python 3.6 implementations will have > order-preserving dict as that's the easiest way to achieve the existing > guarantees. Not all Python 3 implementation will be able to afford the memory hit that comes from doing that relative to their current approaches (e.g. MicroPython), and others may be relying on a 3rd party VM for their core data structures which may not offer a hash map with these characteristics (VOC and the JVM, Batavia and JavaScript runtimes) Using collections.OrderedDict selectively may not impose too large a memory or performance hit, but using it pervasively likely would. > And that enough code will come to depend on an order-preserving > dict that eventually the decision will be made to retrospectively guarantee > the semantics. We explicitly want to discourage that though, as one of the "alternate deployment targets" we'd like folks to retain compatibility with at the library and framework level is single-source 2/3 deployments. Most incompatibilities are splashy ones that can be detected easily just by testing on older versions, but this one can be a bit hard to pick up if you don't already know to check for it. The benefit of making the official stance be that dict-ordering-as-the-default-behaviour is an implementation detail, is that it puts the burden of maintaining compatibility on library and framework developers, and application developers that support "bring your own Python runtime" deployments, *not* on interpreter implementers. Cheers, Nick. -- 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 3.6 dict becomes compact and gets a private version; and keywords become ordered
On 13 September 2016 at 08:25, Gregory P. Smith wrote: > At this point I think coding up an example patch against beta1 offering a > choice of disordered iteration capability that does not increase memory or > iteration overhead in any significant way is needed. > > The problem is... I don't know how to express this as an API. Which sinks my > whole though process and tables the idea. > > A parameter to .items(), .keys() and .values() is undesirable as it isn't > backwards compatible [meaning it'll never be used] and .keys() needs to > match __iter__ which can't have one anyways. A parameter on dict > construction is similarly infeasible. > > Requiring the use of an orderdict like type in order to get the behavior is > undesirable. Effectively I'm asking for some boolean state in each dict as > to if it should iterate in order or not and a way to expose that to pure > Python code in a way that namespace dicts iterate in order by default and > others do not unless explicitly configured to do so. > > oh well. end thought process on my end. it was good while it lasted. I think this is looking at the compatibility testing problem from the wrong direction anyway, as rather than making it difficult for people to implicitly depend on the default key ordering, the scenario we would want to help with is this one: 1. Library developer inadvertently depends on the dicts-are-ordered-by-default implementation detail 2. Library user reports "your library isn't working for me on " 3. Library developer figures out the problem, and would like to update their test suite to deliberately provoke the misbehaviour 4. ??? That is, it falls into the same category as folks depending on CPython's reference counting for prompt resource cleanup, where we offer ResourceWarning to detect such cases, and context managers to clean them up more explicitly. For dict ordering dependence, anyone regularly testing against CPython 2.7 and CPython 3.5 will already have a good chance of detecting key order reliance just through hash randomisation (e.g. I hit an "inconsistent key order in generated JSON makes line-based diffing unreadable" one myself last week with a 3-entry dict for md5, sha1 and sha256 hashes - it was relatively rare to get the same key order two runs in a row) That means the only problematic case is the one where the only CPython version a project supports is 3.6+ *and* they want to support alternate implementations that don't preserve order in their default dict implementation. Given that current alternate implementations are still in the process of catching up to *3.5* (or Python 3 at all in the case of Jython and IronPython), I think we still have a good few years to ponder the question before this particular concern starts cropping up in practise :) Cheers, Nick. -- 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-committers] [RELEASE] Python 3.6.0b1 is now available
Ok, it's start listing regressions/major issues :-) * Bug in _PyDict_Pop() on a splitted table: http://bugs.python.org/issue28120 -- bug in the new compact dict implementation Victor 2016-09-13 1:35 GMT+02:00 Ned Deily : > On behalf of the Python development community and the Python 3.6 release > team, I'm happy to announce the availability of Python 3.6.0b1. 3.6.0b1 > is the first of four planned beta releases of Python 3.6, the next major > release of Python, and marks the end of the feature development phase > for 3.6. > > Among the new major new features in Python 3.6 are: > > * PEP 468 - Preserving the order of **kwargs in a function > * PEP 487 - Simpler customization of class creation > * PEP 495 - Local Time Disambiguation > * PEP 498 - Literal String Formatting > * PEP 506 - Adding A Secrets Module To The Standard Library > * PEP 509 - Add a private version to dict > * PEP 515 - Underscores in Numeric Literals > * PEP 519 - Adding a file system path protocol > * PEP 520 - Preserving Class Attribute Definition Order > * PEP 523 - Adding a frame evaluation API to CPython > * PEP 524 - Make os.urandom() blocking on Linux (during system startup) > * PEP 525 - Asynchronous Generators (provisional) > * PEP 526 - Syntax for Variable Annotations (provisional) > * PEP 528 - Change Windows console encoding to UTF-8 (provisional) > * PEP 529 - Change Windows filesystem encoding to UTF-8 (provisional) > * PEP 530 - Asynchronous Comprehensions > > Please see "What’s New In Python 3.6" for more information: > > https://docs.python.org/3.6/whatsnew/3.6.html > > You can find Python 3.6.0b1 here: > > https://www.python.org/downloads/release/python-360b1/ > > Beta releases are intended to give the wider community the opportunity > to test new features and bug fixes and to prepare their projects to > support the new feature release. We strongly encourage maintainers of > third-party Python projects to test with 3.6 during the beta phase and > report issues found to bugs.python.org as soon as possible. While the > release is feature complete entering the beta phase, it is possible that > features may be modified or, in rare cases, deleted up until the start > of the release candidate phase (2016-12-05). Our goal is have no changes > after rc1. To achieve that, it will be extremely important to get as > much exposure for 3.6 as possible during the beta phase. Please keep in > mind that this is a preview release and its use is not recommended for > production environments > > The next planned release of Python 3.6 will be 3.6.0b2, currently > scheduled for 2016-10-03. More information about the release schedule > can be found here: > > https://www.python.org/dev/peps/pep-0494/ > > -- > Ned Deily > n...@python.org -- [] > > ___ > python-committers mailing list > python-committ...@python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ ___ 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 528: Change Windows console encoding to UTF-8
On 5 September 2016 at 21:19, Paul Moore wrote: > > The code I'm looking at doesn't use the raw stream (I think). The > problem I had (and the reason I was concerned) is that the code does > some rather messy things, and without tracing back through the full > code path, I'm not 100% sure *what* level of stream it's using. > However, now that I know that the buffered layer won't ever error > because 1 byte isn't enough to return a full character, if I need to > change the code I can do so by switching to the buffered layer and > fixing the issue that way (although with Steve's new proposal even > that won't be necessary). Just as a follow-up, I did a quick test of pyinvoke with the new 3.6b1, and it works fine. So it looks like the final version of the code doesn't cause any problems for this use case, which is a good sign. Also, behaviour with other console utilities like prompt_toolkit and ipython console seems uniformly better (my standard check using euro signs works perfectly, I can't say I've gone any further to Asian scripts or anything like that). Overall, this looks really cool - thanks Steve for getting this in! Paul ___ 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] Drastically improving list.sort() for lists of strings/ints
On Sep 11 2016, Terry Reedy wrote: > Tim Peters investigated and empirically determined that an > O(n*n) binary insort, as he optimized it on real machines, is faster > than O(n*logn) sorting for up to around 64 items. Out of curiosity: is this test repeated periodically on different architectures? Or could it be that it only ever was true 10 years ago on Tim's Power Mac G5 (or whatever he used)? Best, -Nikolaus -- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F »Time flies like an arrow, fruit flies like a Banana.« ___ 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] Drastically improving list.sort() for lists of strings/ints
On Tue, Sep 13, 2016, at 13:24, Nikolaus Rath wrote: > On Sep 11 2016, Terry Reedy wrote: > > Tim Peters investigated and empirically determined that an > > O(n*n) binary insort, as he optimized it on real machines, is faster > > than O(n*logn) sorting for up to around 64 items. > > Out of curiosity: is this test repeated periodically on different > architectures? Or could it be that it only ever was true 10 years ago on > Tim's Power Mac G5 (or whatever he used)? Binary insertion sort is still O(n*logn) in comparisons, so it's likely that this is due to short memmoves being sufficiently fast due to cache effects as not to matter. The number might have gotten larger or smaller, though. I wonder if it's something that could be tuned dynamically, at compile time or install time. ___ 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 3.6 dict becomes compact and gets a private version; and keywords become ordered
On 2016-09-13 07:57, Mark Lawrence via Python-Dev wrote: On 12/09/2016 23:25, Gregory P. Smith wrote: [snip] The problem is... I don't know how to express this as an API. Which sinks my whole though process and tables the idea. "tables the idea" has the US meaning of close it down, not the UK meaning of open it up? :) Indeed. The US usage differs from the rest of the English-speaking world. A better phrase would've been "shelves the idea". There's even a module in Python called "shelve", which makes it Pythonic. :-) ___ 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 3.6 dict becomes compact and gets a private version; and keywords become ordered
On 2016-09-13 11:44, Nick Coghlan wrote: On 13 September 2016 at 08:25, Gregory P. Smith wrote: At this point I think coding up an example patch against beta1 offering a choice of disordered iteration capability that does not increase memory or iteration overhead in any significant way is needed. The problem is... I don't know how to express this as an API. Which sinks my whole though process and tables the idea. A parameter to .items(), .keys() and .values() is undesirable as it isn't backwards compatible [meaning it'll never be used] and .keys() needs to match __iter__ which can't have one anyways. A parameter on dict construction is similarly infeasible. Requiring the use of an orderdict like type in order to get the behavior is undesirable. Effectively I'm asking for some boolean state in each dict as to if it should iterate in order or not and a way to expose that to pure Python code in a way that namespace dicts iterate in order by default and others do not unless explicitly configured to do so. oh well. end thought process on my end. it was good while it lasted. I think this is looking at the compatibility testing problem from the wrong direction anyway, as rather than making it difficult for people to implicitly depend on the default key ordering, the scenario we would want to help with is this one: 1. Library developer inadvertently depends on the dicts-are-ordered-by-default implementation detail 2. Library user reports "your library isn't working for me on " 3. Library developer figures out the problem, and would like to update their test suite to deliberately provoke the misbehaviour 4. ??? That is, it falls into the same category as folks depending on CPython's reference counting for prompt resource cleanup, where we offer ResourceWarning to detect such cases, and context managers to clean them up more explicitly. For dict ordering dependence, anyone regularly testing against CPython 2.7 and CPython 3.5 will already have a good chance of detecting key order reliance just through hash randomisation (e.g. I hit an "inconsistent key order in generated JSON makes line-based diffing unreadable" one myself last week with a 3-entry dict for md5, sha1 and sha256 hashes - it was relatively rare to get the same key order two runs in a row) That means the only problematic case is the one where the only CPython version a project supports is 3.6+ *and* they want to support alternate implementations that don't preserve order in their default dict implementation. Given that current alternate implementations are still in the process of catching up to *3.5* (or Python 3 at all in the case of Jython and IronPython), I think we still have a good few years to ponder the question before this particular concern starts cropping up in practise :) The recommended way of dealing with features across different versions of Python is to check for them and see if they raise NameError or whatever, but I wonder if there would be any benefit to recording such things somewhere, e.g. sys.features['ordered_args'] returns True if arguments are passed in an ordered dict. ___ 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] Drastically improving list.sort() for lists of strings/ints
[Terry Reedy ] >> Tim Peters investigated and empirically determined that an >> O(n*n) binary insort, as he optimized it on real machines, is faster >> than O(n*logn) sorting for up to around 64 items. [Nikolaus Rath ] > Out of curiosity: is this test repeated periodically on different > architectures? Or could it be that it only ever was true 10 years ago on > Tim's Power Mac G5 (or whatever he used)? It has little to do with architecture, but much to do with the relative cost of comparisons versus pointer-copying. Near the end of https://github.com/python/cpython/blob/master/Objects/listsort.txt """ BINSORT A "binary insertion sort" is just like a textbook insertion sort, but instead of locating the correct position of the next item via linear (one at a time) search, an equivalent to Python's bisect.bisect_right is used to find the correct position in logarithmic time. Most texts don't mention this variation, and those that do usually say it's not worth the bother: insertion sort remains quadratic (expected and worst cases) either way. Speeding the search doesn't reduce the quadratic data movement costs. But in CPython's case, comparisons are extraordinarily expensive compared to moving data, and the details matter. Moving objects is just copying pointers. Comparisons can be arbitrarily expensive (can invoke arbitrary user-supplied Python code), but even in simple cases (like 3 < 4) _all_ decisions are made at runtime: what's the type of the left comparand? the type of the right? do they need to be coerced to a common type? where's the code to compare these types? And so on. Even the simplest Python comparison triggers a large pile of C-level pointer dereferences, conditionals, and function calls. So cutting the number of compares is almost always measurably helpful in CPython, and the savings swamp the quadratic-time data movement costs for reasonable minrun values. """ Binsort does a close to optimal number of comparisons on randomly ordered data, and that's the point. Also, in the context of the overall sorting algorithm, binsort is used to _extend_ the length of a naturally occurring "too short" run. There's no need to sort the whole thing from scratch, because we already know the prefix is sorted. That makes binsort a more-than-less obvious choice.(it takes full advantage of knowing that the prefix is already ordered). As that doc also says: """ When N is a power of 2, testing on random data showed that minrun values of 16, 32, 64 and 128 worked about equally well. At 256 the data-movement cost in binary insertion sort clearly hurt, and at 8 the increase in the number of function calls clearly hurt. """ So it settled on forcing minrun into the range 32 <= minrun <= 64 (the precise value depends on the number of elements in the entire array, for reasons also explained in that doc). That's far from either end where the value clearly mattered. If the full path through Python's expensive PyObject_RichCompareBool(X, Y, Py_LT) has gotten significantly faster, a smaller minrun range may make more sense now; or if it's gotten significantly slower, a larger minrun range. But, no, I don't believe anyone retests it. IIRC, when the algorithm was adopted in Java, they found a minrun range of 16 through 32 worked marginally better for them, because _their_ spelling of PyObject_RichCompareBool (for Java object comparison methods) is faster than CPython's. ___ 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 3.6 dict becomes compact and gets a private version; and keywords become ordered
On 13.09.2016 19:59, MRAB wrote: The recommended way of dealing with features across different versions of Python is to check for them and see if they raise NameError or whatever, but I wonder if there would be any benefit to recording such things somewhere, e.g. sys.features['ordered_args'] returns True if arguments are passed in an ordered dict. Just to check: do people really that often change between Python implementations? My personal experience with this kind of compatibility is that it is rarely needed for large and complex programs. That is due to deployment and testing issues (at least in our environment as we run multiple Python services on a multitude of servers). Best, Sven ___ 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 3.6 dict becomes compact and gets a private version; and keywords become ordered
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/13/2016 02:11 PM, Sven R. Kunze wrote: > On 13.09.2016 19:59, MRAB wrote: >> The recommended way of dealing with features across different >> versions of Python is to check for them and see if they raise >> NameError or whatever, but I wonder if there would be any benefit to >> recording such things somewhere, e.g. sys.features['ordered_args'] >> returns True if arguments are passed in an ordered dict. > > Just to check: do people really that often change between Python > implementations? > > My personal experience with this kind of compatibility is that it is > rarely needed for large and complex programs. That is due to > deployment and testing issues (at least in our environment as we run > multiple Python services on a multitude of servers). *Lots* of library authors have to straddle Python versions: consumers of those libraries only get to pick and choose when their code is at the "leaf" of the dependency tree (the application). Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQIcBAEBAgAGBQJX2EOfAAoJEPKpaDSJE9HYkokP/j74MGBGt+JjcalETp54yJ5n zgun42oE8c+8rTl2gsnn+E7lipTZ9XW4e+/+XDAOBsb3VK3X344l4Wn1i1pfi9/n 1DXEJkO4rbvIOOI2pcsuVCHTLxcpafvKo0+sjVuXdbuBwWFS1OcSTXGoJ7UKi9yI NtmY16qIYLgNhbxRj5dysnFHtnBD9dnQTxs77QFGnu59nT8i+EI0BRqASMXTNhF3 3IZ13BqIIc0megaaSjfNt3BXaMSHEOpAjhes5ni6OEPPVuDk6XRQf705WcjY2S4H EKaArqJIwWHoLOO4gLiaFAa8x0+Vsl8nfGxgWFZFIPiZ0ALqcZ2YHg0GclUs8J4p eOPuLodc9GqtuyhbPctZLU2EbiGDexGS6GkIa3ESh0/WFaOKB5rt/26szHq/WWXE CGSq7QJssoiKfmdniSY1oa4n/1Q3N1PxZfv54YwnAPGy5SOYspFaWnCwORPRlH9s U2p8X61T5SGFouK3XNv8ZgswpH9bF51JBCJuXl9F1reL+4TpfD/0gHIUQLu34Ot/ 54zxtBB0h+FgnMZ62g+vp04d//0sw/BfsVElkjHi5ptcb+A9IAgjIfOWRDRtSzEx yOQ80dY3BPmknbYecdkYgJhlWke0FT6TOMYA/SVFd6IMol4hxPuDvgfvljRrZeJp Y3ilNxoz72TG5kHfEDbS =Xa3X -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] Drastically improving list.sort() for lists of strings/ints
Nikolaus Rath writes: > Out of curiosity: is this test repeated periodically on different > architectures? Or could it be that it only ever was true 10 years > ago on Tim's Power Mac G5 (or whatever he used)? This is the same Tim Peters of the eponymous test for readability of syntax: "Syntax shall not look like grit on Tim's screen." I don't know if that will help you decide whether to trust his analysis, but it comforts me.<0.5 wink/> ___ 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 3.6 dict becomes compact and gets a private version; and keywords become ordered
On 13.09.2016 20:21, Tres Seaver wrote: *Lots* of library authors have to straddle Python versions: consumers of those libraries only get to pick and choose when their code is at the "leaf" of the dependency tree (the application). Maybe, I didn't express myself well but this was not my intended question. Using this argument for not driving the evolution of the language spec, doesn't seem reasonable. Changes are necessary from time to time and this one in particular is not breaking compatibility with older versions. So, existing libs are okay. But why shouldn't the ordering of dicts not be an advertisable feature for application developers or developers of future libs? My reasoning so far is that in those circumstances people **won't switch** from CPython 3.6 to Cython to PyPy back to CPython 2.7 once a week (drawn from my experience at least). But maybe I'm wrong here. Cheers, Sven ___ 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] Fwd: Cssdbpy is a simple SSDB client written on Cython. Faster standart SSDB client.
Hello! Post my open source client for take feedback. Cssdbpy is a simple SSDB client written on Cython. Faster standart SSDB client. https://github.com/deslum/cssdbpy Thanks. ___ 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] Fwd: Cssdbpy is a simple SSDB client written on Cython. Faster standart SSDB client.
On Tue, Sep 13, 2016 at 12:01 PM, Yurij Alexandrovich wrote: > > Cssdbpy is a simple SSDB client written on Cython. Faster standart SSDB > client. > > https://github.com/deslum/cssdbpy > Congrats. You should post this in python-annouce@ list. This list python-dev is about CPython development. Thank you, Senthil ___ 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] Can CPython on GitHub use the "Merge" button on pull requests (now that they support "squash and merge")?
I noticed in [PEP 512 - Document steps to commit a pull request]( https://www.python.org/dev/peps/pep-0512/#document-steps-to-commit-a-pull-request) it says that CPython on GitHub won't be able to use GitHub's "Merge" button on pull requests, because we want a linear history with one commit per change/issue. However, GitHub recently (actually on April 1, 2016 -- but it's not a joke :-) added support for "commit squashing". See https://github.com/blog/2141-squash-your-commits and https://help.github.com/articles/about-pull-request-merges/ ... basically you can do "old-GitHub-style merge" commits or "squash and merge" commits, and you can even set a repo to only allow "squash and merge" commits on that repo. Will CPython be able to use this? I think that using GitHub's integrated pull request and merge features will make it much easier for contributors (and core developers for that matter). And from personal experience, pressing that big green button is very satisfying. :-) P.S. While I'm here: is there a timeline for the various stages of PEP 512? -Ben ___ 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] Can CPython on GitHub use the "Merge" button on pull requests (now that they support "squash and merge")?
On Tue, 13 Sep 2016 at 13:56 Ben Hoyt wrote: > I noticed in [PEP 512 - Document steps to commit a pull request]( > https://www.python.org/dev/peps/pep-0512/#document-steps-to-commit-a-pull-request) > it says that CPython on GitHub won't be able to use GitHub's "Merge" button > on pull requests, because we want a linear history with one commit per > change/issue. > > However, GitHub recently (actually on April 1, 2016 -- but it's not a joke > :-) added support for "commit squashing". See > https://github.com/blog/2141-squash-your-commits and > https://help.github.com/articles/about-pull-request-merges/ ... basically > you can do "old-GitHub-style merge" commits or "squash and merge" commits, > and you can even set a repo to only allow "squash and merge" commits on > that repo. > > Will CPython be able to use this? > Yes. That part of the PEP is outdated because I've been focusing on moving the other repos first (which are now done). > I think that using GitHub's integrated pull request and merge features > will make it much easier for contributors (and core developers for that > matter). And from personal experience, pressing that big green button is > very satisfying. :-) > > P.S. While I'm here: is there a timeline for the various stages of PEP 512? > The hope is by the end of the year, but no sooner than the release of Python 3.6.0. And FYI the core-workflow mailing list is the best place to ask about the GitHub migration. ___ 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 3.6 dict becomes compact and gets a private version; and keywords become ordered
MRAB wrote: On 2016-09-13 07:57, Mark Lawrence via Python-Dev wrote: "tables the idea" has the US meaning of close it down, not the UK meaning of open it up? :) A better phrase would've been "shelves the idea". There's even a module in Python called "shelve", which makes it Pythonic. :-) So does that mean we should have a "table" module for managing objects we want to currently work on? -- Greg ___ 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 3.6 dict becomes compact and gets a private version; and keywords become ordered
On 2016-09-14 00:42, Greg Ewing wrote: MRAB wrote: On 2016-09-13 07:57, Mark Lawrence via Python-Dev wrote: "tables the idea" has the US meaning of close it down, not the UK meaning of open it up? :) A better phrase would've been "shelves the idea". There's even a module in Python called "shelve", which makes it Pythonic. :-) So does that mean we should have a "table" module for managing objects we want to currently work on? Yes, although in the US locale it would be an alias for the 'shelve' module. :-) ___ 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] Can CPython on GitHub use the "Merge" button on pull requests (now that they support "squash and merge")?
Great, and thanks for the info! -Ben On Sep 13, 2016 5:31 PM, "Brett Cannon" wrote: > > > On Tue, 13 Sep 2016 at 13:56 Ben Hoyt wrote: > >> I noticed in [PEP 512 - Document steps to commit a pull request]( >> https://www.python.org/dev/peps/pep-0512/#document-steps-to-commit-a- >> pull-request) it says that CPython on GitHub won't be able to use >> GitHub's "Merge" button on pull requests, because we want a linear history >> with one commit per change/issue. >> >> However, GitHub recently (actually on April 1, 2016 -- but it's not a >> joke :-) added support for "commit squashing". See >> https://github.com/blog/2141-squash-your-commits and >> https://help.github.com/articles/about-pull-request-merges/ ... >> basically you can do "old-GitHub-style merge" commits or "squash and merge" >> commits, and you can even set a repo to only allow "squash and merge" >> commits on that repo. >> >> Will CPython be able to use this? >> > > Yes. That part of the PEP is outdated because I've been focusing on moving > the other repos first (which are now done). > > >> I think that using GitHub's integrated pull request and merge features >> will make it much easier for contributors (and core developers for that >> matter). And from personal experience, pressing that big green button is >> very satisfying. :-) >> >> P.S. While I'm here: is there a timeline for the various stages of PEP >> 512? >> > > The hope is by the end of the year, but no sooner than the release of > Python 3.6.0. > > And FYI the core-workflow mailing list is the best place to ask about the > GitHub migration. > ___ 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
