Éric Araujo added the comment:
Note that the docs were changed, but versionchanged directives are missing.
--
nosy: +eric.araujo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18111
___
R. David Murray added the comment:
Julian, could you please submit a contributor agreement?
(http://www.python.org/psf/contrib)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18111
___
Roundup Robot added the comment:
New changeset 34ff27b431d0 by R David Murray in branch 'default':
#18111: Add What's New entry for max/min default.
http://hg.python.org/cpython/rev/34ff27b431d0
--
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset 76196691b5d0 by Raymond Hettinger in branch 'default':
Issue 18111: Add a default argument to min() and max()
http://hg.python.org/cpython/rev/76196691b5d0
--
nosy: +python-dev
___
Python tracker
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
resolution: - fixed
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18111
___
R. David Murray added the comment:
I find it interesting that I just came across a case where I want this
functionality, involving a generator derived from a possibly-empty sql table.
I'm using Stefan's functional expression for now :)
--
___
Changes by Phil Connell pconn...@gmail.com:
--
nosy: +pconnell
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18111
___
___
Python-bugs-list
Changes by Serhiy Storchaka storch...@gmail.com:
--
stage: - patch review
versions: -Python 3.5
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18111
___
Julian Berman added the comment:
New patchset addressing review. Not sure why upload.py isn't working for me (I
assume it should?)
--
Added file: http://bugs.python.org/file30510/minmax.patch
___
Python tracker rep...@bugs.python.org
Julian Berman added the comment:
Thanks for the offer Raymond.
Here's a patch with some tests and doc updates, incorporating Nick's suggestion
(but without a note in the docs, I didn't feel it's notable).
Please let me know if anything needs tidying.
--
Added file:
David Beazley added the comment:
To me, the fact that m = max(s) if s else default doesn't work with iterators
alone makes this worthy of consideration.
I would also note that min/max are the only reduction functions that don't have
the ability to work with a possibly empty sequence. For
Thomas Wouters added the comment:
For the record, Raymond, I think you're wrong about this. Itertools isn't
always a solution to every problem, and it makes for a very awkward way around
a silly limitation in min() and max(). Their API is already awkward -- because
they already take a keyword
Nick Coghlan added the comment:
+1 for adding this. It's simple to implement, simple to explain and the
alternatives for dealing with the empty iterable case (or even the fact it may
need to be handled at all) are definitely not obvious.
The relationship to next() is straightforward: the
Ned Batchelder added the comment:
I find the workarounds mentioned here to be baroque and confusing. The concept
of a default value to return in the case of an empty iterator is
straightforward. I'm +1 on adding this as well.
--
nosy: +nedbat
___
Doug Hellmann added the comment:
+1 on adding this
I found today via @dabeaz's cookbook that iter() has a sentinel-detection use
case. Having one in min/max seems *far* more obviously useful. It's also
consistent with quite a few methods on builtin types where we provide a way to
deal with
Nick Coghlan added the comment:
As stated, I don't agree with the closure of this one. min/max deserve a more
elegant mechanism for dealing with the empty iterable edge case.
--
resolution: rejected -
status: closed - open
___
Python tracker
David Beazley added the comment:
I could have used this feature myself somewhat recently. It was in some code
involving document matching where zero or more possible candidates were
assigned a score and I was trying to find the max score. The fact that an
empty list was a possibility
Raymond Hettinger added the comment:
I still think complicating the API isn't worth it. Of late, we've gotten in
the habit of a complexity to even the simplest of things.
In the case of sequences, we already have a reasonable solution:
low = min(seq) if seq else default
In the rarer
Julian Berman added the comment:
Raymond, I respect that in your opinion this seems to be overcomplexity, but
you haven't addressed any of the arguments made, nor responded to any of the
arguments against this being added complexity.
I really don't understand the parallels you're making to
Nick Coghlan added the comment:
To me, the Python-specific difference that makes this useful for us but not for
others is *precisely* the fact that the simple idiom:
x = min(seq) if seq else default
is broken for iterators that don't provide __len__ or __bool__, while the even
simpler:
Julian Berman added the comment:
Personally I don't care either way, I basically never use the multiple
positional arg form, but what are we trying to prevent exactly? It's bad code,
but it (would) do what the person was expecting. Am I not getting the point
that's being made about that case?
Raymond Hettinger added the comment:
Guido, this is your language. What would you like to do?
The OP wants a default argument on min() and max() so he won't have to use an
except ValueError for non-sequence iterables that are potentially empty.
At first, I thought the functions were already
Guido van Rossum added the comment:
+1
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18111
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Guido van Rossum gu...@python.org:
--
assignee: gvanrossum -
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18111
___
___
Nick Coghlan added the comment:
Just one final design philosophy comment from me (I know it isn't needed since
Guido already ack'ed the suggestion):
As far as the lessons learned from the historical startswith() case go,
avoiding taking up the positional slots with optional flags and
Raymond Hettinger added the comment:
Julian, when your tests are ready, I'll be happy to review and apply the patch.
--
assignee: - rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18111
Raymond Hettinger added the comment:
I'm -1 on expanding this API further. It already is pushing the limits with
the dual signature and with the key-function.
Many languages have min/max functions. AFAICT, none of them have an API with a
default argument. This suggests that this isn't an
R. David Murray added the comment:
That's a good point about the __lt__. It occurred to me as well just before I
read your post :).
Raymond, do any other languages have an iterator protocol as a core language
feature? It's the fact that it is in Python, and that it is not simple to LBYL
R. David Murray added the comment:
Oh, and I don't think Haskell counts, since you'd expect them to stick strictly
to the mathematical definition, with no consideration of practicality :)
Note that I'm not saying I'm +1 on adding this (I haven't decided), I'm just
trying to clarify the
Stefan Krah added the comment:
I'd use foldl() in functional languages, where the default is part
of foldl() and not of max().
Translated to Python, I'm thinking of:
it = iter([328, 28, 2989, 22])
functools.reduce(max, it, next(it, None))
2989
I agree with Raymond that a default arg in
Raymond Hettinger added the comment:
Thanks Stephan. I'm going to close this one. The case for adding it is too
weak and isn't worth making the API more complex.
If someone wants a default with an iterable of arbitrary size including zero,
there are already a number of ways to do it (using
Julian Berman added the comment:
I don't really care to push this much harder, but I'll just repeat that I've
already made an argument against catching the exception. Calling this making
the API too complex also seems quite silly to me. It's a thing that someone
looking for would find and
Julian Berman added the comment:
Thanks for finding that, I thought there was an issue that came out of that p-i
thread but couldn't find it.
I'd like to be more concrete, but calling max on an iterable seems concrete
enough to me. If you'd like to know more though, personally I've wanted
R. David Murray added the comment:
So you aren't really asking for a default, you are asking for a version of
max/min that returns a sentinel instead of raising an error on an empty list.
You could just write utility function that has a try/except in it. I'm not
sure it is worth complicating
Julian Berman added the comment:
Yes that's a good description. I'm not sure the type of exception is the thing
to look at as much as the behavior, I.e. I think next() is a good precedent.
And it's not really pleasant to do this with a try/except. Of course
everything's possible, but to catch
R. David Murray added the comment:
I don't think there's any other way to get a ValueError out of min/max, but I
haven't actually looked at the code to check. Of course, if we want people to
rely on that, we'd need to document it.
'next's default is used to return a sentinel when the list is
Julian Berman added the comment:
It's not exactly the same of course, but calling next on a thing that might be
empty would be somewhat close, and also is replacing an exception with a
sentinel (an exception that is much easier to differentiate).
You can always get a ValueError out of
New submission from Julian Berman:
This has come up a number of times I'm aware, but no one has ever written a
patch for it as far as a quick look uncovered.
So here's one (written by Thomas Wouters but with permission to submit).
Submitting without tests and docs, but those are incoming when
Changes by Julian Berman julian+python@grayvines.com:
--
keywords: +patch
Added file: http://bugs.python.org/file30437/minmaxdefault.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18111
R. David Murray added the comment:
Issue 7153 and the discussions linked therefrom is presumably relevant here.
Do you have a concrete use case?
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18111
40 matches
Mail list logo
