Re: [Python-Dev] cpython: Issue 19944: Fix importlib.find_spec() so it imports parents as needed.
On 26 January 2014 11:57, Eric Snow wrote: > On Sat, Jan 25, 2014 at 6:28 PM, Antoine Pitrou wrote: >> Is there a reason to have separate "importlib" (toplevel) and >> "importlib.util" namespaces? > > As to why they are separate, you'll need to ask Brett. I believe it's > meant to keep the top namespace as small as possible. Correct - the top level namespace is meant for people to use normally for dynamic imports, reloading modules and clearing the internal caches when dynamically creating modules. By contrast, importlib.util is for when people are poking around at import system internals more directly, writing custom importers and loaders, replicating parts of the import system, etc. It's a "if you don't know why you might want these operations, you probably don't need them" kind of module, so we can keep the top level namespace simple and relatively easy to learn. find_loader()/find_spec() are both borderline as to which category they fall into, but as Eric noted, there was a dependency issue in this case which meant there were practical benefits to putting find_spec() in the "import specialist" category. 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] Deprecation policy
On Sat, 25 Jan 2014 18:30:24 -0800 Raymond Hettinger wrote: > > On Jan 25, 2014, at 5:29 AM, Ezio Melotti wrote: > > > Nick also suggested to document > > our deprecation policy in PEP 5 (Guidelines for Language Evolution: > > http://www.python.org/dev/peps/pep-0005/ ). > > Here's a few thoughts on deprecations: > > * If we care at all about people moving to Python 3, then we'll stop > doing anything that makes the process more difficult. For someone > moving from Python 2.7, it really doesn't matter if something that > existed in 2.7 got deprecated in 3.1 and removed in 3.3; from their > point-of-view, it just one more thing that won't work. +1. > * The notion of PendingDeprecationWarnings didn't work out very well. > Conceptually, it was a nice idea, but in practice no one was benefitting > from it. The warnings slowed down working, but not yet deprecated code. > And no one was actually seeing the pending deprecations. +1 too, especially since DeprecationWarnings are now silent by default, there's no reason to start with a PendingDeprecationWarning IMO. Regards 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] lambda (x, y):
On 01/26/2014 03:42 AM, Raymond Hettinger wrote: I think that is an over-simplification. The argument unpacking was handy in a number of situations where *args wouldn't suffice: lambda (px, py), (qx, qy): ((px - qx) ** 2 + (py - qy) ** 2) ** 0.5 IIRC, the original reason for the change was that it simplified the compiler a bit, not that it was broken or not useful. I'm not sure if that's applicable or other issues arise with: def fn(*p): px,py,qx,qy = p; return ((px - qx) ** 2 + (py - qy) ** 2) ** 0.5 Thanks in advance! Francis ___ 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] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)
Dear comrades,
I would like to bring to your attention my disagreement with Larry
Hastings in this ticket: http://bugs.python.org/issue19145
(Inconsistent behaviour in itertools.repeat when using negative
times).
Let me give you the context:
>>> from itertools import repeat
>>> repeat('a')
repeat('a')
>>> repeat('a', times=-1)
repeat('a')
>>> repeat('a', -1)
repeat('a', 0)
>>> repeat('a', times=-4)
repeat('a', -4)
>>> repeat('a', -4)
repeat('a', 0)
Right now, the only way you can tell repeat to do endless repetitions
is to omit the `times` argument or by setting `times` argument to -1
via keyword.
Larry intends to fix this in Python 3.5 by making None value to
`times` argument as a representative of unlimited repetitions and
negative `times` argument (either via keyword or positional) ALWAYS
means 0 repetitions. This will ensure repeat has the appropriate
signature. I have no qualms about it. All is well.
My disagreement is related to Larry's decision not to fix this bug in
Python 2.7, 3.3, and 3.4. Both of us agree that we should not let
Python 2.7, 3.3, and 3.4 happily accepts None value because that is
more than bug fix. What we don't agree is whether we should make
negative `times` argument via keyword behaviour needs to be changed or
not. He prefer let it be. I prefer we change the behaviour so that
negative `times` argument in Python 2.7, 3.3, and 3.4 ALWAYS means 0
repetitions.
My argument is that, on all circumstances, argument sent to function
via positional or keyword must mean the same thing.
Let's consider this hypothetical code:
# 0 means draw, positive int means win, negative int means lose
result = goals_result_of_the_match()
# For every goal of the winning match, we donate money to charity.
# Every donation consists of 10 $.
import itertools
itertools.repeat(donate_money_to_charity(), result)
Later programmer B refactor this code:
# 0 means draw, positive int means win, negative int means lose
result = goals_result_of_the_match()
# For every goal of the winning match, we donate money to charity.
# Every donation consists of 10 $
from itertools import repeat
repeat(object=donate_money_to_charity(), times=result)
They use Python 2.7 (remember Python 2.7 is here to stay for a long
long time). And imagine the match is lost 0-1 or 1-2 or 2-3 (so the
goal difference is negative one / -1). It means they donate money to
charity endlessly!!! They can go bankrupt.
So I hope my argument is convincing enough. We need to fix this bug in
Python 2.7, 3.3, and 3.4, by making `times` argument sent via
positional or keyword in itertools.repeat ALWAYS means the same thing,
which is 0 repetitions.
If this is not possible, at the very least, we need to warn this
behaviour in the doc.
Whatever decision that comes up from this discussion, I will make peace with it.
Vajrasky
___
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] lambda (x, y):
On 01/26/2014 09:59 AM, francis wrote: > On 01/26/2014 03:42 AM, Raymond Hettinger wrote: >> >> I think that is an over-simplification. The argument unpacking was handy >> in a number of situations where *args wouldn't suffice: >> >>lambda (px, py), (qx, qy): ((px - qx) ** 2 + (py - qy) ** 2) ** 0.5 >> >> IIRC, the original reason for the change was that it simplified the >> compiler a bit, >> not that it was broken or not useful. > I'm not sure if that's applicable or other issues arise with: > > def fn(*p): px,py,qx,qy = p; return ((px - qx) ** 2 + (py - qy) ** 2) ** > 0.5 [Dropping some whitespace to get things to all fit on one line] The goal is to call fn as: fn((1, 1), (2, 2)) So, in 2.7: >>> def fn((px, py), (qx, qy)): ... return ((px-qx)**2+(py-qy)**2)**0.5 ... >>> fn((1, 1), (2, 2)) 1.4142135623730951 >>> The nearest equivalent in 3.3 (also works in 2.7): >>> def fn(p, q): ... (px, py), (qx, qy) = p, q ... return ((px-qx)**2+(py-qy)**2)**0.5 ... >>> fn((1, 1), (2, 2)) 1.4142135623730951 For a lambda in 3.3, you're out of luck because you can't do the assignment. There, the best you can do is: >>> fn = lambda p, q: ((p[0]-q[0])**2+(p[1]-q[1])**2)**0.5 >>> fn((1, 1), (2, 2)) 1.4142135623730951 Which isn't quite so readable as the equivalent lambda in 2.7: >>> fn = lambda (px, py),(qx, qy):((px-qx)**2+(py-qy)**2)**0.5 >>> fn((1, 1), (2, 2)) 1.4142135623730951 As someone pointed out, it's not quite the same when you do your own tuple unpacking, but it's probably close enough for most cases. 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] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)
26.01.14 19:00, Vajrasky Kok написав(ла): So I hope my argument is convincing enough. We need to fix this bug in Python 2.7, 3.3, and 3.4, by making `times` argument sent via positional or keyword in itertools.repeat ALWAYS means the same thing, which is 0 repetitions. If this is not possible, at the very least, we need to warn this behaviour in the doc. I agree with Vajrasky. This is obvious bug and it should be fixed in any way. ___ 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] The Argument Clinic Derby is drawing to a close
The first release candidate of Python 3.4 will be tagged in about two weeks. We need to be completely done with the Derby by then. And it's going to take a while to review and iterate on the patches we've got. Therefore: I'm going to stop accepting submissions for new patches in two days. Patches posted to the issue tracker on or after Wednesday Jan 29 at 12:00:01am will not be accepted. If you have a patch you're still working on, you have until then to get it in. Please make sure that all patches, whether they've been posted yet or not, conform to the new conversion policy for the Derby: https://mail.python.org/pipermail/python-dev/2014-January/132066.html Thanks for participating! //arry/ ___ 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] The Argument Clinic Derby is drawing to a close
On 01/26/2014 04:24 PM, Larry Hastings wrote: Patches posted to the issue tracker on or after Wednesday Jan 29 at 12:00:01am will not be accepted. Sorry, forgot to specify the time zone: PST, which is GMT -08:00. Put another way, the submission window closes about 55.5 hours from when I posted this message. Cheers, //arry/ ___ 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] The Argument Clinic Derby is drawing to a close
On 01/26/2014 04:24 PM, Larry Hastings wrote: The first release candidate of Python 3.4 will be tagged in about two weeks. We need to be completely done with the Derby by then. And it's going to take a while to review and iterate on the patches we've got. Since I was asked to clarify: we aren't going to convert every possible candidate function before the close of the Derby. We'll just ship what we have, and Python 3.4 will only have partial coverage for builtins. Once trunk reopens for Python 3.5 development work we'll pick up where we left off. Thanks again, //arry/ ___ 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] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)
On 27 Jan 2014 04:44, "Serhiy Storchaka" wrote: > > 26.01.14 19:00, Vajrasky Kok написав(ла): > >> So I hope my argument is convincing enough. We need to fix this bug in >> Python 2.7, 3.3, and 3.4, by making `times` argument sent via >> positional or keyword in itertools.repeat ALWAYS means the same thing, >> which is 0 repetitions. >> >> If this is not possible, at the very least, we need to warn this >> behaviour in the doc. > > > I agree with Vajrasky. This is obvious bug and it should be fixed in any way. Larry and I were discussing this problem on IRC and the problem is that we can't remove this behaviour without providing equivalent functionality under a different spelling. In 3.5, that will be passing None, rather than -1. For those proposing to change the maintenance releases, how should a user relying on this misbehaviour update their code to handle it? There's also the fact that breaking working code in a maintenance release is always dubious, especially when there's no current supported way to get the equivalent behaviour prior to the maintenance release. This is the kind of change that will require a note in the "porting to Python 3.5" section of the What's New, again suggesting strongly that we can't change it in the maintenance releases. Cheers, Nick. > > > ___ > 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/ncoghlan%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] The Argument Clinic Derby is drawing to a close
On 2014-01-27 00:26, Larry Hastings wrote: On 01/26/2014 04:24 PM, Larry Hastings wrote: Patches posted to the issue tracker on or after Wednesday Jan 29 at 12:00:01am will not be accepted. Sorry, forgot to specify the time zone: PST, which is GMT -08:00. Put another way, the submission window closes about 55.5 hours from when I posted this message. Put yet another way, 2014-01-29T08:00Z. ___ 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] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)
On Sun, Jan 26, 2014 at 8:52 PM, Nick Coghlan wrote:
> There's also the fact that breaking working code in a maintenance release
> is always dubious, especially when there's no current supported way to get
> the equivalent behaviour prior to the maintenance release. This is the kind
> of change that will require a note in the "porting to Python 3.5" section
> of the What's New, again suggesting strongly that we can't change it in the
> maintenance releases.
It looks like there is more than one bug related to passing negative times
as a keyword argument:
>>> from itertools import *
>>> ''.join(repeat('a', times=-4))
Traceback (most recent call last):
File "", line 1, in
OverflowError: long int too large to convert to int
itertools.repeat() is documented [1] as being equivalent to:
def repeat(object, times=None):
# repeat(10, 3) --> 10 10 10
if times is None:
while True:
yield object
else:
for i in range(times):
yield object
The behavior of the CPython implementation is clearly wrong. If there are
people relying on it - they already have code that would break in other
implementations. (I would say not accepting None for times is a bug as
well if you read the docs literally.)
When implementation behavior differs from documentation it is a bug by
definition and a fix should go in bug-fix releases. Reproducing old
behavior is fairly trivial using an old_repeat(object, *args, **kwds)
wrapper to distinguish between arguments passed positionally and by
keyword. However, I seriously doubt that anyone would need that.
[1] http://docs.python.org/3/library/itertools.html#itertools.repeat
___
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] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)
On Sun, Jan 26, 2014 at 12:00 PM, Vajrasky Kok
wrote:
> >>> repeat('a', times=-1)
> repeat('a')
>
As I think about it, this may be more than a bug but a door for a denial of
service attack. Imagine an application where times comes from an
untrusted source. Someone relying on documented behavior may decide to
sanitize the value by only checking against an upper bound assuming that
negative values would just lead to no repetitions. If an attacker could
somehow case times to get the value of -1 this may cause an infinite loop,
blow up memory etc.
If you think this is far-fetched - consider a web app that uses repeat() as
a part of logic to pretty-print user input. The times value may come from
a calculation of a difference between the screen width and the length of
some string - both under user control.
So maybe the fix should go into security bugs only branches as well.
___
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] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)
On 27 January 2014 13:51, Alexander Belopolsky
wrote:
>
> On Sun, Jan 26, 2014 at 12:00 PM, Vajrasky Kok
> wrote:
>>
>> >>> repeat('a', times=-1)
>> repeat('a')
>
>
> As I think about it, this may be more than a bug but a door for a denial of
> service attack. Imagine an application where times comes from an untrusted
> source. Someone relying on documented behavior may decide to sanitize the
> value by only checking against an upper bound assuming that negative values
> would just lead to no repetitions. If an attacker could somehow case times
> to get the value of -1 this may cause an infinite loop, blow up memory etc.
>
> If you think this is far-fetched - consider a web app that uses repeat() as
> a part of logic to pretty-print user input. The times value may come from a
> calculation of a difference between the screen width and the length of some
> string - both under user control.
>
> So maybe the fix should go into security bugs only branches as well.
If we do go this path, then we should backport the full fix (i.e.
accepting None to indicate repeating forever), rather than just a
partial fix.
That is, I'm OK with either not backporting anything at all, or
backporting the full change. The only idea I object to is the one of
removing the infinite iteration capability without providing a
replacement spelling for it.
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] The Argument Clinic Derby is drawing to a close
On Mon, Jan 27, 2014 at 2:24 AM, Larry Hastings wrote: > > > The first release candidate of Python 3.4 will be tagged in about two weeks. > We need to be completely done with the Derby by then. And it's going to > take a while to review and iterate on the patches we've got. > > Therefore: I'm going to stop accepting submissions for new patches in two > days. Patches posted to the issue tracker on or after Wednesday Jan 29 at > 12:00:01am will not be accepted. If you have a patch you're still working > on, you have until then to get it in. Why not delay rc1 by a week or two and get this work done? ___ 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] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)
On Sun, Jan 26, 2014 at 11:02 PM, Nick Coghlan wrote: > That is, I'm OK with either not backporting anything at all, or > backporting the full change. > +1 A partial backport will do a disservice to both users and maintainers. ___ 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] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)
On Mon, Jan 27, 2014 at 12:20 PM, Alexander Belopolsky wrote: > > +1 > > A partial backport will do a disservice to both users and maintainers. In case we are taking "not backporting anything at all" road, what is the best fix for the document? Old >>> itertools.repeat.__doc__ 'repeat(object [,times]) -> create an iterator which returns the object\nfor the specified number of times. If not specified, returns the object\nendlessly.' New >>> itertools.repeat.__doc__ 'repeat(object [,times]) -> create an iterator which returns the object\nfor the specified number of times. If not specified, returns the object\nendlessly. If times is specified through positional and negative numbers, it always means 0 repetitions. If times is specified through keyword and -1, it means endless repetition. Other negative numbers for times through keyword should be avoided.' ___ 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] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)
On Mon, Jan 27, 2014 at 12:02 PM, Nick Coghlan wrote:
>>>
>
> That is, I'm OK with either not backporting anything at all, or
> backporting the full change. The only idea I object to is the one of
> removing the infinite iteration capability without providing a
> replacement spelling for it.
>
Is repeat('a') (omitting times argument) not a replacement spelling for it?
What about this alternative? Makes -1 consistently mean unlimited
repetition and other negative numbers consistently mean zero
repetitions then document this behaviour. Just throwing suggestion. I
am not so keen to it, though.
___
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] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)
On Sun, Jan 26, 2014 at 11:21 PM, Vajrasky Kok wrote: > What about this alternative? Makes -1 consistently mean unlimited > repetition and other negative numbers consistently mean zero > repetitions > -1 I think this idea was already rejected on the bug tracker. It will be very surprising if list(repeat(x, n)) would be different from [x] * n for integer n. ___ 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] The Argument Clinic Derby is drawing to a close
On 01/26/2014 08:07 PM, Tshepang Lekhonkhobe wrote: On Mon, Jan 27, 2014 at 2:24 AM, Larry Hastings wrote: The first release candidate of Python 3.4 will be tagged in about two weeks. We need to be completely done with the Derby by then. And it's going to take a while to review and iterate on the patches we've got. Therefore: I'm going to stop accepting submissions for new patches in two days. Patches posted to the issue tracker on or after Wednesday Jan 29 at 12:00:01am will not be accepted. If you have a patch you're still working on, you have until then to get it in. Why not delay rc1 by a week or two and get this work done? We discussed that. The core developers, and Guido in particular, were against it. One good reason: if we slip Python 3.4 again we will miss shipping Python 3.4 final with Ubuntu 14.04. You can read the discussion in python-committers; it's under the subject "Status of the Derby, and request for another slip". https://mail.python.org/pipermail/python-committers/2014-January/002977.html //arry/ ___ 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] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)
On Sun, Jan 26, 2014 at 11:26 PM, Vajrasky Kok
wrote:
> In case we are taking "not backporting anything at all" road, what is
> the best fix for the document?
>
> Old
> >>> itertools.repeat.__doc__
> 'repeat(object [,times]) -> create an iterator which returns the
> object\nfor the specified number of times. If not specified, returns
> the object\nendlessly.'
>
I would say no fix is needed for this doc because the signature suggests
(correctly) that passing times by keyword is not supported.
The following behavior further supports this interpretation.
>>> from itertools import *
>>> ''.join(repeat('a', times=-4))
Traceback (most recent call last):
File "", line 1, in
OverflowError: long int too large to convert to int
The ReST documentation may benefit from an addition of a warning that
behavior of repeat() is "undefined" when times is passed by keyword.
___
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] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)
On 01/26/2014 08:40 PM, Alexander Belopolsky wrote: On Sun, Jan 26, 2014 at 11:26 PM, Vajrasky Kok mailto:sky@speaklikeaking.com>> wrote: In case we are taking "not backporting anything at all" road, what is the best fix for the document? I would say no fix is needed for this doc because the signature suggests (correctly) that passing times by keyword is not supported. Where does it do that? And why would the function support keyword arguments, if it was the author's intent to not support them? It's easier to not support them, you call PyArg_ParseTuple. Calling PyArg_ParseTupleAndKeywords is slightly more involved. //arry/ ___ 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] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)
On 1/26/2014 11:02 PM, Nick Coghlan wrote:
On 27 January 2014 13:51, Alexander Belopolsky
wrote:
On Sun, Jan 26, 2014 at 12:00 PM, Vajrasky Kok
wrote:
repeat('a', times=-1)
repeat('a')
As I think about it, this may be more than a bug but a door for a denial of
service attack. Imagine an application where times comes from an untrusted
source. Someone relying on documented behavior may decide to sanitize the
value by only checking against an upper bound assuming that negative values
would just lead to no repetitions. If an attacker could somehow case times
to get the value of -1 this may cause an infinite loop, blow up memory etc.
If you think this is far-fetched - consider a web app that uses repeat() as
a part of logic to pretty-print user input. The times value may come from a
calculation of a difference between the screen width and the length of some
string - both under user control.
So maybe the fix should go into security bugs only branches as well.
If we do go this path, then we should backport the full fix (i.e.
accepting None to indicate repeating forever), rather than just a
partial fix.
That is, I'm OK with either not backporting anything at all, or
backporting the full change. The only idea I object to is the one of
removing the infinite iteration capability without providing a
replacement spelling for it.
I believe that the replacement spelling would be the existing 'spelling'
of no spelling at all -- omitting the argument. However, having to
(temporarily) write
def myfunc(...what, num, ...):
...
if times is None:
itertools.repeat(what, num)
else:
itertools.repeat(what)
is obnoxious at best.
While I am a strong supported of no new features in bug releases, one of
my early commits added a new parameter to difflib.SequenceMatcher. This
was after pydev discussion that included Tim Peters and which concluded
that there was no other sane way to fix the bug. If merely making both
ways of passing times have the same effect is rejected, then I vote for
the complete fix. Fixing the default for an existing parameter is less
of a new feature than a new parameter.
--
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
[Python-Dev] [RELEASED] Python 3.4.0b3
On behalf of the Python development team, I'm quite pleased to announce the third beta release of Python 3.4. This is a preview release, and its use is not recommended for production settings. Python 3.4 includes a range of improvements of the 3.x series, including hundreds of small improvements and bug fixes. Major new features and changes in the 3.4 release series include: * PEP 428, a "pathlib" module providing object-oriented filesystem paths * PEP 435, a standardized "enum" module * PEP 436, a build enhancement that will help generate introspection information for builtins * PEP 442, improved semantics for object finalization * PEP 443, adding single-dispatch generic functions to the standard library * PEP 445, a new C API for implementing custom memory allocators * PEP 446, changing file descriptors to not be inherited by default in subprocesses * PEP 450, a new "statistics" module * PEP 451, standardizing module metadata for Python's module import system * PEP 453, a bundled installer for the *pip* package manager * PEP 454, a new "tracemalloc" module for tracing Python memory allocations * PEP 456, a new hash algorithm for Python strings and binary data * PEP 3154, a new and improved protocol for pickled objects * PEP 3156, a new "asyncio" module, a new framework for asynchronous I/O Python 3.4 is now in "feature freeze", meaning that no new features will be added. The final release is projected for mid-March 2014. To download Python 3.4.0b3 visit: http://www.python.org/download/releases/3.4.0/ Please consider trying Python 3.4.0b3 with your code and reporting any new issues you notice to: http://bugs.python.org/ Enjoy! -- Larry Hastings, Release Manager larry at hastings.org (on behalf of the entire python-dev team and 3.4's contributors) ___ 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] Negative times behaviour in itertools.repeat for Python maintenance releases (2.7, 3.3 and maybe 3.4)
On Sun, Jan 26, 2014 at 11:40:33PM -0500, Alexander Belopolsky wrote:
> I would say no fix is needed for this doc because the signature suggests
> (correctly) that passing times by keyword is not supported.
How do you determine that? Passing times by keyword works in Python 3.3:
py> from itertools import repeat
py> it = repeat("a", times=5)
py> list(it)
['a', 'a', 'a', 'a', 'a']
The docstring signature names both parameters:
py> print(repeat.__doc__)
repeat(object [,times]) -> create an iterator which returns the object
for the specified number of times. If not specified, returns the object
endlessly.
And both names work fine:
py> repeat(object=2, times=5)
repeat(2, 5)
Judging from the docstring and current behaviour, I think we can
conclude that:
- keyword arguments are fine;
- there shouldn't be any difference between providing a value
by position or by keyword;
- repeat(x) should yield x forever;
- repeat(x, 0) should immediately raise StopIteration;
- repeat(x, -n) is not specified by the docstring, but the
documentation on the website makes it clear that it should
be equivalent to repeat(x, 0) no matter the magnitude of -n;
- which matches the behaviour of [x]*-n nicely.
As far as I'm concerned, this is a clear case of a bug. Providing
times=None (by keyword or by position) ought to be equivalent to not
providing times at all, and any negative times ought to be equivalent to
zero.
> The following behavior further supports this interpretation.
>
> >>> from itertools import *
> >>> ''.join(repeat('a', times=-4))
> Traceback (most recent call last):
> File "", line 1, in
> OverflowError: long int too large to convert to int
I don't think it does. I think it suggests that something is trying to
convert an unsigned value into an int, and failing. I note that repeat
is happy to work with negatives times one at a time:
py> it = repeat('a', times=-4)
py> next(it)
'a'
--
Steven
___
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] peps: Incorporate PEP 462 feedback
On 27 January 2014 15:28, Terry Reedy wrote: > On 1/26/2014 10:22 PM, nick.coghlan wrote: >> >> +Terry Reedy has suggested doing an initial filter which specifically >> looks >> +for approved documentation-only patches (~700 of the 4000+ open CPython >> +issues are pure documentation updates). This approach would avoid several >> +of the issues related to flaky tests and cross-platform testing, while >> +still allowing the rest of the automation flows to be worked out (such as >> +how to push a patch into the merge queue). >> + >> +The one downside to this approach is that Zuul wouldn't have complete >> +control of the merge process as it usually expects, so there would >> +potentially be additional coordination needed around that. > > > An essential part of my idea is that Zuul *would* have complete control > while pushing doc patches to avoid the otherwise inevitable push races. > Initially, this would be for a part of every day. While it has control, I > would expect it to push doc patches at intervals of perhaps a minute, or > even more rapidly with parallel testing. (Since doc patch rarely interfere > and would be expected to apply after pre-testing, little speculative testing > would need to be tossed.) "Exclusive control some of the time" is not the same thing as "exclusive control". It's not an impossible idea, but certainly not the way Zuul is currently designed to work :) >> +It may be worth keeping this approach as a fallback option if the initial >> +deployment proves to have more trouble with test reliability than is >> +anticipated. > > > I think a doc queue should be a permanent part of the system. There would > always be doc-only patches -- and I suspect even more than now. One of the > types of jobs on the main queue could be a periodic 'push all pending doc > patches' job. I would then think we should try splitting code + doc patches > into a code patch, pushed first, and a doc patch, added to the doc queue if > the code patch succeeded. That seems like added complexity for little gain - note that we can make the *test runner* smart about how it handles doc-only patches, by just checking the docs build and skipping the test run. 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
[Python-Dev] [RELEASED] Python 3.3.4 release candidate 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On behalf of the Python development team, I'm reasonably happy to announce the Python 3.3.4 release candidate 1. Python 3.3.4 includes several security fixes and over 120 bug fixes compared to the Python 3.3.3 release. This release fully supports OS X 10.9 Mavericks. In particular, this release fixes an issue that could cause previous versions of Python to crash when typing in interactive mode on OS X 10.9. Python 3.3 includes a range of improvements of the 3.x series, as well as easier porting between 2.x and 3.x. In total, almost 500 API items are new or improved in Python 3.3. For a more extensive list of changes in the 3.3 series, see http://docs.python.org/3.3/whatsnew/3.3.html and for the detailed changelog of 3.3.4, see http://docs.python.org/3.3/whatsnew/changelog.html To download Python 3.3.4 rc1 visit: http://www.python.org/download/releases/3.3.4/ This is a preview release, please report any bugs to http://bugs.python.org/ The final version is scheduled to be released in two weeks' time, on or about the 10th of February. Enjoy! - -- Georg Brandl, Release Manager georg at python.org (on behalf of the entire python-dev team and 3.3's contributors) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) iEYEARECAAYFAlLmDI4ACgkQN9GcIYhpnLAr6wCePRbHF80k5goV4RUDBA5FfkwF rLUAnRg0RpL/b6apv+Dt2/sgnUd3hTPA =Z4Ss -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
