Re: [Python-Dev] Updates to PEP 471, the os.scandir() proposal
[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. -Ben ___ 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
Brett Cannon wrote: > No, the PEPs were fine and were accepted properly. A huge portion of the open > issues are from Robin Schreiber who as part of GSoC 2012 -- https:// > www.google-melange.com/gsoc/project/details/google/gsoc2012/robin_hood/ > 5668600916475904 -- went through and updated the stdlib to follow the new > practices introduced in the two PEPs. Not sure if there was some policy > decision made that updating the code wasn't worth it or people simply didn't > get around to applying the patches. Due to the frequent state lookups there is a performance problem though, which is quite significant for _decimal. Otherwise I think I would have implemented the changes already. http://bugs.python.org/issue15722 I think for speed sensitive applications it may be an idea to create a new C function (METH_STATE flag) which gets the state passed in by ceval. Other than that, looking up the state inside the module but cache it (like it's done for the _decimal context) also has reasonable performance. Also I hit the same issues that Eli mentioned here a while ago: https://mail.python.org/pipermail/python-dev/2013-August/127862.html Stefan Krah ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2014-07-04 - 2014-07-11) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open4588 (-15) closed 29141 (+55) total 33729 (+40) Open issues with patches: 2151 Issues opened (24) == #21918: Convert test_tools to directory http://bugs.python.org/issue21918 opened by serhiy.storchaka #21919: Changing cls.__bases__ must ensure proper metaclass inheritanc http://bugs.python.org/issue21919 opened by abusalimov #21922: PyLong: use GMP http://bugs.python.org/issue21922 opened by h.venev #21925: ResouceWarning sometimes doesn't display http://bugs.python.org/issue21925 opened by msmhrt #21927: BOM appears in stdin when using Powershell http://bugs.python.org/issue21927 opened by jason.coombs #21928: Incorrect reference to partial() in functools.wraps documentat http://bugs.python.org/issue21928 opened by Dustin.Oprea #21929: Rounding properly http://bugs.python.org/issue21929 opened by jeroen1225 #21931: Nonsense errors reported by msilib.FCICreate for bad argument http://bugs.python.org/issue21931 opened by Jeffrey.Armstrong #21933: Allow the user to change font sizes with the text pane of turt http://bugs.python.org/issue21933 opened by Lita.Cho #21934: OpenBSD has no /dev/full device http://bugs.python.org/issue21934 opened by Daniel.Dickman #21935: Implement AUTH command in smtpd. http://bugs.python.org/issue21935 opened by zvyn #21937: IDLE interactive window doesn't display unsaved-indicator http://bugs.python.org/issue21937 opened by rhettinger #21939: IDLE - Test Percolator http://bugs.python.org/issue21939 opened by sahutd #21941: Clean up turtle TPen class http://bugs.python.org/issue21941 opened by ingrid #21944: Allow copying of CodecInfo objects http://bugs.python.org/issue21944 opened by lehmannro #21946: 'python -u' yields trailing carriage return '\r' (Python2 for http://bugs.python.org/issue21946 opened by msp #21947: `Dis` module doesn't know how to disassemble generators http://bugs.python.org/issue21947 opened by hakril #21949: Document the Py_SIZE() macro. http://bugs.python.org/issue21949 opened by gregory.p.smith #21951: tcl test change crashes AIX http://bugs.python.org/issue21951 opened by David.Edelsohn #21952: fnmatch.py can appear in tracemalloc diffs http://bugs.python.org/issue21952 opened by pitrou #21953: pythonrun.c does not check std streams the same as fileio.c http://bugs.python.org/issue21953 opened by steve.dower #21955: ceval.c: implement fast path for integers with a single digit http://bugs.python.org/issue21955 opened by haypo #21956: Doc files deleted from repo are not deleted from docs.python.o http://bugs.python.org/issue21956 opened by brandon-rhodes #21957: ASCII Formfeed (FF) & ASCII Vertical Tab (VT) Have Hexadecimal http://bugs.python.org/issue21957 opened by Zero Most recent 15 issues with no replies (15) == #21957: ASCII Formfeed (FF) & ASCII Vertical Tab (VT) Have Hexadecimal http://bugs.python.org/issue21957 #21955: ceval.c: implement fast path for integers with a single digit http://bugs.python.org/issue21955 #21951: tcl test change crashes AIX http://bugs.python.org/issue21951 #21949: Document the Py_SIZE() macro. http://bugs.python.org/issue21949 #21944: Allow copying of CodecInfo objects http://bugs.python.org/issue21944 #21941: Clean up turtle TPen class http://bugs.python.org/issue21941 #21937: IDLE interactive window doesn't display unsaved-indicator http://bugs.python.org/issue21937 #21935: Implement AUTH command in smtpd. http://bugs.python.org/issue21935 #21933: Allow the user to change font sizes with the text pane of turt http://bugs.python.org/issue21933 #21931: Nonsense errors reported by msilib.FCICreate for bad argument http://bugs.python.org/issue21931 #21928: Incorrect reference to partial() in functools.wraps documentat http://bugs.python.org/issue21928 #21919: Changing cls.__bases__ must ensure proper metaclass inheritanc http://bugs.python.org/issue21919 #21916: Create unit tests for turtle textonly http://bugs.python.org/issue21916 #21909: PyLong_FromString drops const http://bugs.python.org/issue21909 #21899: Futures are not marked as completed http://bugs.python.org/issue21899 Most recent 15 issues waiting for review (15) = #21953: pythonrun.c does not check std streams the same as fileio.c http://bugs.python.org/issue21953 #21947: `Dis` module doesn't know how to disassemble generators http://bugs.python.org/issue21947 #21944: Allow copying of CodecInfo objects http://bugs.python.org/issue21944 #21941: Clean up turtle TPen class http://bugs.python.org/issue21941 #21939: IDLE - Test Percolator http://bugs.python.org/issue21939 #21935: Implement AUTH command in smtpd. http://bugs.python.org/issue21935 #21934:
[Python-Dev] == on object tests identity in 3.x
Am 09.07.2014 03:48, schrieb Raymond Hettinger:
On Jul 7, 2014, at 4:37 PM, Andreas Maier wrote:
I do not really buy into the arguments that try to show how identity and value
are somehow the same. They are not, not even in Python.
The argument I can absolutely buy into is that the implementation cannot be
changed within a major release. So the real question is how we document it.
Once every few years, someone discovers IEEE-754, learns that NaNs
aren't supposed to be equal to themselves and becomes inspired
to open an old debate about whether the wreck Python in a effort
to make the world safe for NaNs. And somewhere along the way,
people forget that practicality beats purity.
Here are a few thoughts on the subject that may or may not add
a little clarity ;-)
* Python already has IEEE-754 compliant NaNs:
assert float('NaN') != float('NaN')
* Python already has the ability to filter-out NaNs:
[x for x in container if not math.nan(x)]
* In the numeric world, the most common use of NaNs is for
missing data (much like we usually use None). The property
of not being equality to itself is primarily useful in
low level code optimized to run a calculation to completion
without running frequent checks for invalid results
(much like @n/a is used in MS Excel).
* Python also lets containers establish their own invariants
to establish correctness, improve performance, and make it
possible to reason about our programs:
for x in c:
assert x in c
* Containers like dicts and sets have always used the rule
that identity-implies equality. That is central to their
implementation. In particular, the check of interned
string keys relies on identity to bypass a slow
character-by-character comparison to verify equality.
* Traditionally, a relation R is considered an equality
relation if it is reflexive, symmetric, and transitive:
R(x, x) -> True
R(x, y) -> R(y, x)
R(x, y) ^ R(y, z) -> R(x, z)
* Knowingly or not, programs tend to assume that all of those
hold. Test suites in particular assume that if you put
something in a container that assertIn() will pass.
* Here are some examples of cases where non-reflexive objects
would jeopardize the pragmatism of being able to reason
about the correctness of programs:
s = SomeSet()
s.add(x)
assert x in s
s.remove(x)# See collections.abc.Set.remove
assert not s
s.clear() # See collections.abc.Set.clear
asset not s
* What the above code does is up to the implementer of the
container. If you use the Set ABC, you can choose to
implement __contains__() and discard() to use straight
equality or identity-implies equality. Nothing prevents
you from making containers that are hard to reason about.
* The builtin containers make the choice for identity-implies
equality so that it is easier to build fast, correct code.
For the most part, this has worked out great (dictionaries
in particular have had identify checks built-in from almost
twenty years).
* Years ago, there was a debate about whether to add an __is__()
method to allow overriding the is-operator. The push for the
change was the "pure" notion that "all operators should be
customizable". However, the idea was rejected based on the
"practical" notions that it would wreck our ability to reason
about code, it slow down all code that used identity checks,
that library modules (ours and third-party) already made
deep assumptions about what "is" means, and that people would
shoot themselves in the foot with hard to find bugs.
Personally, I see no need to make the same mistake by removing
the identity-implies-equality rule from the built-in containers.
There's no need to upset the apple cart for nearly zero benefit.
Containers delegate the equal comparison on the container to their
elements; they do not apply identity-based comparison to their elements.
At least that is the externally visible behavior.
Only the default comparison behavior implemented on type object follows
the identity-implies-equality rule.
As part of my doc patch, I will upload an extension to the
test_compare.py test suite, which tests all built-in containers with
values whose order differs the identity order, and it shows that the
value order and equality wins over identity, if implemented.
IMO, the proposed quest for purity is misguided.
There are many practical reasons to let the builtin
containers continue work as the do now.
As I said, I can accept compatibility reasons. Plus, the argument
brought up by Benjamin about the desire for the the
identity-implies-equality rule as a default, with no corresponding rule
for order comparison (and I added both to the doc patch).
Andy
___
Python-Dev mailing list
[email protected]
https://mail.python.org/
[Python-Dev] == on object tests identity in 3.x - uploaded doc patch
Am 11.07.2014 10:54, schrieb Ethan Furman: On 07/11/2014 01:51 AM, Andreas Maier wrote: I like the motivation provided by Benjamin and will work it into the doc patch for issue #12067. The NaN special case will also stay in. Cool -- you should nosy myself, D'Aprano, and Benjamin (at least) on that issue. Done. Plus, I have uploaded a patch (v8) to issue #12067, that reflects hopefully everything that was said (to the extent it was related to comparisons). Andy ___ 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] == on object tests identity in 3.x
Am 08.07.2014 05:47, schrieb Ethan Furman: On 07/07/2014 08:34 PM, Stephen J. Turnbull wrote: Ethan Furman writes: And what would be this 'sensible definition' [of value equality]? I think that's the wrong question. I suppose Andreas's point is that when the programmer doesn't provide a definition, there is no such thing as a "sensible definition" to default to. I disagree, but given that as the point of discussion, asking what the definition is, is moot. He eventually made that point, but until he did I thought he meant that there was such a sensible default definition, he just wasn't sharing what he thought it might be with us. My main point is that a sensible definition is up to the class designer, so (all freedom at hand) would prefer an exception as default. But that cannot be changed at this point, and maybe never will. And I don't intend to stir up that discussion again. I dropped my other point about a better default comparison (i.e. one with a result, not an exceptioN). It is not easy to define one unless one comes to types such as sequences or integral types, and they in fact have defined their own customizations for comparison. Bottom line: I'm fine with just a doc patch, and a testcase improvement :-) Andy ___ 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] == on object tests identity in 3.x
On 07/11/2014 07:04 AM, Andreas Maier wrote:
Am 09.07.2014 03:48, schrieb Raymond Hettinger:
Personally, I see no need to make the same mistake by removing
the identity-implies-equality rule from the built-in containers.
There's no need to upset the apple cart for nearly zero benefit.
Containers delegate the equal comparison on the container to their elements;
they do not apply identity-based comparison
to their elements. At least that is the externally visible behavior.
If that were true, then [NaN] == [NaN] would be False, and it is not.
Here is the externally visible behavior:
Python 3.5.0a0 (default:34881ee3eec5, Jun 16 2014, 11:31:20)
[GCC 4.7.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
--> NaN = float('nan')
--> NaN == NaN
False
--> [NaN] == [NaN]
True
--
~Ethan~
___
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] buildbot.python.org down again?
In article <[email protected]>, Donald Stufft wrote: > On Jul 8, 2014, at 12:58 AM, Nick Coghlan wrote: > > On 7 Jul 2014 10:47, "Guido van Rossum" wrote: > > > It would still be nice to know who "the appropriate persons" are. Too > > > much of our infrastructure seems to be maintained by house elves or the > > > ITA. > > I volunteered to be the board's liaison to the infrastructure team, and > > getting more visibility around what the infrastructure *is* and how it's > > monitored and supported is going to be part of that. That will serve a > > couple of key purposes: > > - making the points of escalation clearer if anything breaks or needs > > improvement (although "[email protected]" is a good default choice) > > - making the current "todo" list of the infrastructure team more visible > > (both to calibrate resolution time expectations and to provide potential > > contributors an idea of what's involved) > > Noah has already set up http://status.python.org/ to track service status, > > I can see about getting buildbot.python.org added to the list. > We (the infrastructure team) were actually looking earlier about > buildbot.python.org and we're not entirely sure who "owns" > buildbot.python.org. > Unfortunately a lot of the *.python.org services are in a similar state where > there is no clear owner. Generally we've not wanted to just step in and take > over for fear of stepping on someones toes but it appears that perhaps > buildbot.p.o has no owner? In parallel to this discussion, I ran into Noah at a meeting the other day and we talked a bit about buildbot.python.org. As Donald noted, it sounds like he and the infrastructure team are willing to add it to the list of machines they monitor and reboot, as long as they wouldn't be expected to administer the buildbot master itself. I checked with Antoine and Martin and they are agreeable with that. So I think there is general agreement that the infrastructure team can take on uptime monitoring and rebooting of buildbot.python.org and that Antoine/Martin would be the primary/secondary contacts/owners for other administrative issues. Martin would also be happy if the infrastructure team could handle installing routine security fixes as well. I'll leave it to the interested parties to discuss it further among themselves. -- Ned Deily, [email protected] ___ 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
