Re: [Python-Dev] Implementing (parts of) copy module in C
On 02/11/2016 06:23, Stephen J. Turnbull wrote: Rasmus Villemoes writes: > First, apologies if this isn't the appropriate list; I trust I'll be > nudged in the right direction. Given the relatively advanced state of patch, I doubt that this is the *wrong* list. However, you would probably benefit from posting to [email protected] to collect use cases. (We don't "vote" on such additions. Rather the senior devs consider whether the use cases seem general enough to justify on-going maintenance costs for new code.) > I would of course also be very interested in getting it into 2.7.x, > but I assume that's impossible(?). That is correct. This is clearly a feature, and 2.7 currently is accepting only security-related patches (broadly construed -- a sufficiently severe bug, such as a crash or infloop, is security- related because it could be used to implement a DoS attack). Surely patches related to any bugs, not just security related ones, will be accepted until EOL in 2020? -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Implementing (parts of) copy module in C
Hi, 2016-11-01 22:56 GMT+01:00 Rasmus Villemoes : > I'm using (and contributing to) an application which spends a > significant part of its startup time calling copy.deepcopy, so I thought > I'd try to write a C extension to speed this up. Maybe you should consider another option: using copy.dpeecopy() is *bad* practice and should be avoided in almost all cases. By design, copy.deepcopy() cannot be efficient. For efficient code, you should redesign the application to use immutable structures for example. Victor ___ 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] Implementing (parts of) copy module in C
On 11/2/2016 3:54 AM, Mark Lawrence via Python-Dev wrote: On 02/11/2016 06:23, Stephen J. Turnbull wrote: That is correct. This is clearly a feature, and 2.7 currently is accepting only security-related patches (broadly construed -- a sufficiently severe bug, such as a crash or infloop, is security- related because it could be used to implement a DoS attack). Surely patches related to any bugs, not just security related ones, will be accepted until EOL in 2020? That depends on the maintainers of a particular module. Some core developers have stopped patching 2.7. One should ask before writing and submitting non-security 2.7 code that does not clearly have a chance to be applied. -- Terry Jan Reedy ___ 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] Implementing (parts of) copy module in C
On 02/11/2016 12:09, Terry Reedy wrote: On 11/2/2016 3:54 AM, Mark Lawrence via Python-Dev wrote: On 02/11/2016 06:23, Stephen J. Turnbull wrote: That is correct. This is clearly a feature, and 2.7 currently is accepting only security-related patches (broadly construed -- a sufficiently severe bug, such as a crash or infloop, is security- related because it could be used to implement a DoS attack). Surely patches related to any bugs, not just security related ones, will be accepted until EOL in 2020? That depends on the maintainers of a particular module. Some core developers have stopped patching 2.7. One should ask before writing and submitting non-security 2.7 code that does not clearly have a chance to be applied. Okay, thanks for that :) -- My fellow Pythonistas, ask not what our language can do for you, ask what you can do for our language. Mark Lawrence ___ 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] Implementing (parts of) copy module in C
Mark Lawrence via Python-Dev writes: > Surely patches related to any bugs, not just security related ones, will > be accepted until EOL in 2020? Maybe, since it is the last in the 2.x line -- ask the RM, not me. I shouldn't have said anything, my apologies. But that doesn't matter for this contribution, since it's obviously a feature. ___ 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
[Python-Dev] itertools predicates
Some functions that take a predicate from itertools accept None as its predicate: >>> list(itertools.filterfalse(None, range(10))) [0] >>> list(itertools.groupby([0,0,1,1], None)) [(0, ), (1, )] While others don't: >>> list(itertools.dropwhile(None, range(10))) Traceback (most recent call last): File "", line 1, in TypeError: 'NoneType' object is not callable I'd be interested in writing a patch to make itertools more consistent if there's a consensus. I see two possible solutions: - Either remove None as a predicate parameter, which would not be backwards compatible. - Or make the functions that don't accept None start accepting it. ___ 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] itertools predicates
On 11/2/2016 6:03 PM, Francisco Couzo wrote: Some functions that take a predicate from itertools accept None as its predicate: list(itertools.filterfalse(None, range(10))) [0] list(itertools.groupby([0,0,1,1], None)) [(0, ), (1, )] While others don't: list(itertools.dropwhile(None, range(10))) Traceback (most recent call last): File "", line 1, in TypeError: 'NoneType' object is not callable I'd be interested in writing a patch to make itertools more consistent if there's a consensus. I see two possible solutions: * Either remove None as a predicate parameter, which would not be backwards compatible. * Or make the functions that don't accept None start accepting it. I think you should post this as an enhancement proposal on the tracker. Put Raymond Hettinger, the itertools originator and maintainer, as nosy. -- Terry Jan Reedy ___ 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
